[14] RFR (S): 8234401: ConstantCallSite may stuck in non-frozen state
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Tue Nov 19 17:49:35 UTC 2019
> Subtle, so I could be misunderstanding something, did you intend to remove the assignment of isFrozen in the ConstantCallSite constructor?
Oh, good catch. It is my fault: the update should be there. (The
barriers are added just to preserve final field semantics for isFrozen.)
Published the wrong version (with some leftovers from last-minute failed
experiment). Updated in place.
Best regards,
Vladimir Ivanov
>> On Nov 19, 2019, at 8:53 AM, Vladimir Ivanov <vladimir.x.ivanov at 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
>
More information about the core-libs-dev
mailing list