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

[Roman Kennke]

>>> 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>