Ah the perils of partial construction :-) Subtle, so I could be misunderstanding something, did you intend to remove the assignment of isFrozen in the ConstantCallSite constructor?
ConstantCallSite: protected ConstantCallSite(MethodType targetType, MethodHandle createTargetHook) throws Throwable { - super(targetType, createTargetHook); - isFrozen = true; + super(targetType, createTargetHook); // "this" instance leaks into createTargetHook + UNSAFE.storeStoreFence(); // properly publish isFrozen } Paul. > On Nov 19, 2019, at 8:53 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> > wrote: > > http://cr.openjdk.java.net/~vlivanov/8234401/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8234401 > > ConstantCallSite has a ctor which deliberately leaks partially initialized > instance into user code. isFrozen is declared final and if user code is > obstinate enough, it can end up with non-frozen state embedded into the > generated code. It manifests as a ConstantCallSite instance which is stuck in > non-frozen state. > > I switched isFrozen from final to @Stable, so non-frozen state is never > constant folded. Put some store-store barriers along the way to restore final > field handling. > > I deliberately stopped there (just restoring isFrozen final field behavior). > Without proper synchronization, there's still a theoretical possibility of > transiently observing a call site in non-frozen state right after ctor is > over. But at least there's no way anymore to accidentally break an instance > in such a way it becomes permanently unusable. > > PS: converted CallSite.target to final along the way and made some other > minor refactorings. > > Testing: regression test, tier1-2 > > Best regards, > Vladimir Ivanov