RFC: Revisiting ShenandoahOptimize*Finals flags

Roman Kennke rkennke at redhat.com
Fri Jan 11 13:07:39 UTC 2019


>> Also, we enable ShenandoahOptimizeStaticFinals by default, but not
>> ShOptInstanceFinals and ShOptStableFinals. How is StaticFinals any
>> better than InstanceFinals? Exchange <init> with <cinit> and the
>> instance with the Class object, it's pretty much the same problem, and
>> not under our control at all.
> 
> Or is it guaranteed that a Class used by getstatic in C2 is fully
> constructed? In which case +ShenandoahOptimizeStaticFinals would be ok.

There is another twist to the story, which probably makes all 3
optimization valid: an object getting constructed (i.e. in <clinit> or
<init>) must have just been allocated, i.e. it is guaranteed in
to-space. If, between allocation and <init>/<clinit> a safepoint
happened (e.g. when returning from _new), the object would still remain
on stack/in-register and get kept in to-space by our invariants. By
which, I think, all 3 optimizations are valid. Prove me
wrong/counter-example?

Roman




More information about the shenandoah-dev mailing list