Hi there,

I’m currently working on upstreaming compact object headers (aka Lilliput):
https://github.com/openjdk/jdk/pull/20677

One part of that change is to use bit #3 of the mark-word to indicate 
self-forwarded object in case of promotion-failures. This change is 
unconditional, e.g. it is always-on regardless of the setting of the flag 
UseCompactObjectHeaders, for performance reasons. This is ok on 64-bit 
platforms, because that bit is unused anyway. However, it conflicts with legacy 
stack-locks on 32-bit platforms, because stack-pointers on 32-bit platforms are 
only 4-byte-aligned and may occupy the bit, and make impossible to distinguish 
between a regular stack-locked mark-word and a self-forwarded mark-word.

My question is, do you think it is ok if the proposed changes forces the new 
lightweight locking on 32-bit platforms? Lightweight locking is already the 
default, and the legacy locking is already deprecated and will eventually be 
removed, but for now, legacy locking is still there. Is there any reason to 
continue to support legacy locking on 32-bit platforms, or can we enforce LW 
locking on startup?

Thanks,
Roman




Amazon Web Services Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597

Reply via email to