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

[Aleksey Shipilev]

On 11/29/18 12:06 PM, Roman Kennke wrote:
>> 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.

-Aleksey

[1]  https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5.3

-------------- 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/d7f7db7c/signature.asc>