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

Reply via email to