Re: [Qemu-devel] [PATCH v4 6/7] qom: replace object property list with GHashTable

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 11/16/2015 08:13 AM, Pavel Fedin wrote:
>  Hello!
> 
>>>> (process:4102): GLib-CRITICAL **: g_hash_table_iter_next: assertion
>>>> 'ri->version == ri->hash_table->version' failed
>>>>
>>>> (process:4102): GLib-CRITICAL **: g_hash_table_iter_next: assertion
>>>> 'ri->version == ri->hash_table->version' failed
>>>>
>>>> (process:4102): GLib-CRITICAL **: iter_remove_or_steal: assertion
>>>> 'ri->version == ri->hash_table->version' failed
> 
>  Wow... Actually this may come from attempts to modify the tree inside iteration.
> 
>> Thanks! sclp_init() seems to violate several QOM design principles in
>> that it uses object_new() during TypeInfo::instance_init() and uses a
>> TYPE_... constant as property name. But nothing else stands out immediately.
> 
>  I think we should refactor this and retry. If not all problems go away, then we are indeed modifying the tree during iteration, and
> we have to find some solution.

David, Conny,

the current tree of afaerber

https://github.com/afaerber/qemu-cpu/commits/qom-next

has this patch:

> From: Pavel Fedin <p.fedin@samsung.com>
>
> ARM GICv3 systems with large number of CPUs create lots of IRQ pins. Since
> every pin is represented as a property, number of these properties becomes
> very large. Every property add first makes sure there's no duplicates.
> Traversing the list becomes very slow, therefore qemu initialization takes
> significant time (several seconds for e. g. 16 CPUs).
>
> This patch replaces list with GHashTable, making lookup very fast. The only
> drawback is that object_child_foreach() and object_child_foreach_recursive()
> cannot modify their objects during traversal, since GHashTableIter does not
> have modify-safe version. However, the code seems not to modify objects via
> these functions.
>
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>

which causes failures in make check. A simple reproducer is

qemu-system-s390x -device sclp,help


any idea what would be the most simple fix?
Can we refactor this to create the event facility and the bus in the
machine or whatever?



>  I wonder... Could we have both list and hashtable? hashtable for searching by name and list for iteration. In this case we would
> not have to use glib's iterators, and would be free of problems with them. Just keep the list and hashtable in sync.
>  Or, is there any hashtable implementation out there which would keep iterators valid during modification?
>  OTOH, glib has a function "remove the element at iterator's position", and we could postpone addition. So, perhaps, using both
> containers would be an overkill, just refactor the code to adapt to the new behavior.