[External] : Re: Need help with ZGC failure in Lilliput

[Erik Osterlund]

Hi Roman,

The idea last time I checked was to have a Java hash table to map objects to their inflated monitors, and just a few bits for locking to manage the simplest non-reentrant locking and the inflation process. And throw away stack locks and the C++ monitors we have today.

I think at the moment it’s just a big fat lock though in the prototype, just to get the semantics right of essentially changing monitorenter/exit to static calls to Java code.

/Erik

> On 21 Jul 2021, at 11:12, Roman Kennke <rkennke at redhat.com> wrote:
> 
> 
>> 
>>> The problem always happens during weak storage scan. Inflation of a lock
>>> creates new weak handle that points back to the object. I suspect that, at the
>>> very least, this must not point to the old copy of that object. I need to think this
>>> through.
>> Is the lock inflation provoked by the GC thread itself, as a side effect of reading the klass?
> 
> Yes. The more I think about it, the more I come to the conclusion that this might be a no-go, except maybe for a dirty prototype (which is my current goal, tbh).
> 
> Can you share more about Robbin's work? Because this sounds like it would help avoid such problems.
> 
> Thanks,
> Roman
>