Could you give a bit more information? What triggers a property change during gc? Is there a better way to avoid it?

Of course, my explanation above is a bit vague. The problem lies in the property search of the object. During the property search process, if the conditions are met, a hash table will be created, which involves the allocation of memory. When the existing memory is insufficient, it will enter the gc to reclaim the idle memory. During this process, the logic of querying attributes is involved again. Under certain conditions, it seems that the previously created hash table was not discovered during the gc process, so it once more enters the logic of hashmap_create, which leads to the execution of hashmap_create once more within the logic of hashmap_create. As for whether there is a better method, I think the current modification has little impact on the existing code, and the act of modifying the properties on the object during the gc process itself should not occur. The following is the result of my local debugging. I hope it can help you understand this scenario.

It seems the problem is entering the hashmap creation. GC normally just check all properties, and does not search anything. It looks like it is a weak map specific thing. The problem should be stopped there.

Your reply reminds me that during the gc process, ecma_op_object_unref_weak was called to remove the weak reference relationship, and from here, ecma_find_named_property was called

I suspect unref weak is only used by gc, since deleting from weakset is not possible. We need to avoid the allocation there in some way.