Re: [Qemu-devel] [PATCH RFC 1/7] qom: allow properties to be registered against classes

[Markus Armbruster]

Adding Paolo for additional QOM smarts.

"Daniel P. Berrange" <address@hidden> writes:

> On Wed, Sep 02, 2015 at 06:18:28PM +0200, Andreas Färber wrote:
>> Am 26.08.2015 um 14:03 schrieb Daniel P. Berrange:
>> > When there are many instances of a given class, registering
>> > properties against the instance is wasteful of resources. The
>> > majority of objects have a statically defined list of possible
>> > properties, so most of the properties are easily registerable
>> > against the class. Only those properties which are conditionally
>> > registered at runtime need be recorded against the klass.
>> > 
>> > Registering properties against classes also makes it possible
>> > to provide static introspection of QOM - currently introspection
>> > is only possible after creating an instance of a class, which
>> > severely limits its usefulness.
>> > 
>> > This impl only supports simple scalar properties. It does not
>> > attempt to allow child object / link object properties against
>> > the class. There are ways to support those too, but it would
>> > make this patch more complicated, so it is left as an exercise
>> > for the future.
>> > 
>> > Signed-off-by: Daniel P. Berrange <address@hidden>
>> > ---
>> >  include/qom/object.h |  44 ++++++++++
>> >  qom/object.c         | 233 
>> > +++++++++++++++++++++++++++++++++++++++++++++++++--
>> >  2 files changed, 270 insertions(+), 7 deletions(-)
>> > 
>> > diff --git a/include/qom/object.h b/include/qom/object.h
>> > index 807978e..068162e 100644
>> > --- a/include/qom/object.h
>> > +++ b/include/qom/object.h
>> > @@ -383,6 +383,8 @@ struct ObjectClass
>> >      const char *class_cast_cache[OBJECT_CLASS_CAST_CACHE];
>> >  
>> >      ObjectUnparent *unparent;
>> > +
>> > +    QTAILQ_HEAD(, ObjectProperty) properties;
>> >  };
>> >  
>> >  /**
>> [snip]
>> 
>> I had suggested exactly this looong time ago, but Anthony opposed it. I
>> don't quite remember why...
>
> It is a while back now so I don't remember all aspects of the discussion
> either. The main thing I remember is that we could not simply use the
> existing GObject model from glib, since that exclusively records properties
> against the object class. In some cases, particularly the relationships
> between objects, QEMU needed to be able to define properties on the fly
> against object instances.

I remember Anthony's assertion that this is the case, but I don't
remember the actual problems where this is actually the case.

What properties do we currently define that could not be defined against
the class?

> So that was a definite reason Anthony wanted to have the ability to have
> properties against object instances. I don't remember reading anything
> about *not* also having the option to define properties against the
> object classes. So hopefully this proposal gets us the best of both
> worlds - the flexibility of allowing per-instance properties when
> needed, along with the reduced memory usage & static introspection
> benefits of per-class properties where possible.

If I can't have "properties are always declared in data, not created by
code", then I'd still prefer "almost all properties are declared in
data" over "properties are always created by code", because reasoning
over static data is way easier than reasoning over code.

>> Did you do any benchmarks on performance impact?
>
> I've not done any measurements of impact on CPU time or memory usage.
> As mentioned in the intro, I'd expect memory usage to decline significantly
> in the case where there are many instances of the same class. Attribute
> getter/setters probably have a small CPU hit, due to the need to consult
> the linked lists in both the class and object structs. I think that will
> be small overall though, and if it is a problem we would probably better
> off switching in a hashtable in place of the linked list, so we have
> O(1) lookup instead of O(n) lookups.
>
> That all said, I'll try to create a test program to measure these
> effects to get some clear numbers to consider.

Yes, please.