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

Erik Osterlund erik.osterlund at oracle.com
Wed Jul 28 19:10:27 UTC 2021

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.


> 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

More information about the zgc-dev mailing list