Force lightweight locking on 32 bit platforms?

[Kennke, Roman]

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