Re: [Qemu-devel] [PATCH v12 28/36] qapi: Simplify QObject

[Markus Armbruster <armbru@redhat.com>]

Eric Blake <eblake@redhat.com> writes:

> The QObject hierarchy is small enough, and unlikely to grow further
> (since we only use it to map to JSON and already cover all JSON
> types), that we can simplify things by not tracking a separate
> vtable, but just inline all two elements of the vtable QType
> directly into QObject.  We can drop qnull_destroy_obj() in the
> process.
>
> This also has the nice benefit of moving the typename 'QType'
> out of the way, so that the next patch can repurpose it for a
> nicer name for 'qtype_code'.
>
> The various objects are now 8 bytes larger on 64-bit platforms, but
> hopefully this is in the noise.  If size is absolutely critical due
> to cache line speed effects, we could do some bit packing to
> restore the previous size (qtype_code currently only requires three
> distinct bits, so we could assert an assumption that architecture
> ABIs will give function pointers at least an 8-byte alignment, and
> that the three low-order bits of destroy are always zero; or we
> could use a bitfield for refcnt, with a maximum of SIZE_MAX/8, and
> given that a QObject already occupies at least 8 bytes, that won't
> artificially limit us). Or we could expose the currently static
> destroy methods and instead create a table in qobject.h that maps
> QType to destructor.

That's what I'd do.

A type registration function would keep the destructors static.  But why
bother.

>                       But let's save any size compression for a
> followup patch, if at all.

Okay.

> On the other hand, by avoiding a separate vtable, there is less
> indirection, so use of QObjects may be slightly more efficient.
>
> However, as we don't have evidence pointing at either QObject size
> or access speed as being a hot spot, I didn't think it was worth
> benchmarking.
>
> Suggested-by: Markus Armbruster <armbru@redhat.com>
> Signed-off-by: Eric Blake <eblake@redhat.com>

Works for me.