Request for CSR review: 8214349: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector (original) (raw)

Roman Kennke rkennke at redhat.com
Thu Nov 29 14:41:44 UTC 2018

Do ShenandoahOptimizeInstanceFinals and related options enable optimizations which violate the spec?

At the very least, it taps undefined behavior: when modifying a final field via reflection or JNI or other means, the optimization might lead to see stale values. There is one case where we think it would violate the JMM though: if initializer initializes final field, and the object somehow escapes it, and the field is accessed before initializer is finished, it might see a stale (uninitialized) value, which it must not do. How should we deal with it? Document the potential danger? Remove the flags altogether? This is not the violation of spec. Final fields are very special, and observing stale values even within the single thread is permitted [1]. When object escapes in uninitialized state, all bets are off. Therefore, these options do not violate the spec, but they can break applications that assume that finals are stronger than they are. This is similar to TrustFinalNonStaticFields, for example, which can break applications the same way, while being formally correct. Premature publication already breaks final field guarantees in subtle manner.

Thanks for clarifying, Aleksey.

Due to lack of permission to comment on the CSR directly, let's discuss some of it here.

I would not like to change acronyms in flags like SATB to Satb. This would look very odd to me, and inconsistent too. Every other flag that has SATB in it uses just SATB.

Other such acronyms used in our flags are: GC, TLAB and CAS. I don't think any of them are better as Gc, Tlab or Cas. I'd very much prefer to keep them as they are.

Thanks, Roman

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20181129/34c2a0d7/signature.asc>

More information about the hotspot-gc-dev mailing list