Commit graph

6 commits

Author SHA1 Message Date
Thomas Haller
22edeb5b69 core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex
Reasons:

 - it adds an O(1) lookup index for accessing NMIPxConfig's addresses.
   Hence, operations like merge/intersect have now runtime O(n) instead
   of O(n^2).
   Arguably, we expect low numbers of addresses in general. For low
   numbers, the O(n^2) doesn't matter and quite likely in those cases
   the previous implementation was just fine -- maybe even faster.
   But the simple case works fine either way. It's important to scale
   well in the exceptional case.
 - the tracked objects can be shared between the various NMPI4Config,
   NMIP6Config instances with NMPlatform and everybody else.
 - the NMPObject can be treated generically, meaning it enables code to
   handle both IPv4 and IPv6, or addresses and routes. See for example
   _nm_ip_config_add_obj().
 - I want core to evolve to somewhere where we don't keep copies of
   NMPlatformIP4Address, et al. instances. Instead they shall all be
   shared. I hope this will reduce memory consumption (although tracking a
   reference consumes some memory too). Also, it shortcuts nmp_object_equal()
   when comparing the same object. Calling nmp_object_equal() on the
   identical objects would be a common case after the hash function
   pre-evaluates equality.
2017-07-25 06:44:12 +02:00
Thomas Haller
ad5f5c81ef core: shortcut equal operator for identical object reference in NMDedupMultiIndex
And get rid of the unused obj_full_equality_allows_different_class.
It's hard to grasp how to implement different object types that can compare
despite having different klasses. The idea was, that stack allocated
objects (used as lookup needles), are some small lightweight objects,
that still compare equal to the full instance. But it's unused. Drop it.
2017-07-10 21:55:00 +02:00
Thomas Haller
930da031b2 core: fix NMDedupMultiIndex's _dict_idx_entries_hash()
Don't overwrite @h.

Fixes: f9202c2ac1
2017-07-10 21:55:00 +02:00
Thomas Haller
aeaa1b3b98 platform: refactor nm_dedup_multi_objs_to_ptr_array_head()
by moving the core functionality to "nm-dedup-multi.c".

As the ref-counting mechanism now is part of "nm-dedup-multi.c",
this works better and is reusable outside of platform.
2017-07-05 18:37:39 +02:00
Thomas Haller
28340588d9 core: remove NMDedupMultiBox object and track NMDedupMultiObj instances directly
Implement the reference counting of NMPObject as part of
NMDedupMultiObj and get rid of NMDedupMultiBox.

With this change, the NMPObject is aware in which NMDedupMultiIndex
instance it is tracked.

- this saves an additional GSlice allocation for the NMDedupMultiBox.

- it is immediately known, whether an NMPObject is tracked by a
  certain NMDedupMultiIndex or not. This saves an additional hash
  lookup.

- previously, when all idx-types cease to reference an NMDedupMultiObj
  instance, it was removed. Now, a tracked objects stays in the
  NMDedupMultiIndex until it's last reference is deleted. This possibly
  extends the lifetime of the object and we may reuse it better.

- it is no longer possible to add one object to more then one
  NMDedupMultiIndex instance. As we anyway want to have only one
  instance to deduplicate the objects, this is fine.

- the ref-counting implementation is now part of NMDedupMultiObj.
  Previously, NMDedupMultiIndex could also track objects that were
  not ref-counted. Hoever, the object anyway *must* implement the
  NMDedupMultiObj API, so this flexibility is unneeded and was not
  used.

- a downside is, that NMPObject grows by one pointer size, even if
  it isn't tracked in the NMDedupMultiIndex. But we really want to
  put all objects into the index for sharing and deduplication. So
  this downside should be acceptable. Still, code like
  nmp_object_stackinit*() needs to handle a larger object.
2017-07-05 18:37:39 +02:00
Thomas Haller
f9202c2ac1 shared: add NMDedupMultiIndex "nm-dedup-multi.h"
Add the NMDedupMultiIndex cache. It basically tracks
objects as doubly linked list. With the addition that
each object and the list head is indexed by a hash table.
Also, it supports tracking multiple distinct lists,
all indexed by the idx-type instance.
It also deduplicates the tracked objects and shares them.

 - the objects that can be put into the cache must be immutable
   and ref-counted. That is, the cache will deduplicate them
   and share the reference. Also, as these objects are immutable
   and ref-counted, it is safe that users outside the cache
   own them too (as long as they keep them immutable and manage
   their reference properly).

   The deduplication uses obj_id_hash_func() and obj_id_equal_func().
   These functions must cover *every* aspect of the objects when
   comparing equality. For example nm_platform_ip4_route_cmp()
   would be a function that qualifies as obj_id_equal_func().

   The cache creates references to the objects as needed and
   gives them back. This happens via obj_get_ref() and
   obj_put_ref(). Note that obj_get_ref() is free to create
   a new object, for example to convert a stack-allocated object
   to a (ref-counted) heap allocated one.

   The deduplication process creates NMDedupIndexBox instances
   which are the ref-counted entity. In principle, the objects
   themself don't need to be ref-counted as that is handled by
   the boxing instance.

 - The cache doesn't only do deduplication. It is a multi-index,
   meaning, callers add objects using a index handle NMDedupMultiIdxType.
   The NMDedupMultiIdxType instance is the access handle to lookup
   the list and objects inside the cache. Note that the idx-type
   instance may partition the objects in distinct lists.

For all operations there are cross-references and  hash table lookups.
Hence, every operation of this data structure is O(1) and the memory
overhead for an index tracking an object is constant.

The cache preserves ordering (due to linked list) and exposes the list
as public API. This allows users to iterate the list without any
additional copying of elements.
2017-07-05 14:22:10 +02:00