Request for CSR review: 8214349: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector
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 . 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev