JDK-8234401 : ConstantCallSite may stuck in non-frozen state
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 11,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-11-19
  • Updated: 2020-06-09
  • Resolved: 2019-11-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14 b25Fixed
Related Reports
Relates :  
JDK-8234923 - Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance
Relates :  
JDK-8233873 - final field values should be trusted as constant
Description
Depending on how ConstantCallSite is instantiated, it may stuck in non-frozen state.
Comments
[~dlong] it was a deliberate decision to keep final field guarantees for isFrozen, but don't improve the situation beyond that for the case of unsafe publication: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-November/036019.html "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."
09-06-2020
In this code: @Override public final MethodHandle getTarget() { if (!isFrozen) throw new IllegalStateException(); return target; } what prevents the compiler or hardware from reading "target" before "isFrozen"? After discussing with [~eosterlund] and [~dholmes], it seems like there needs to be a LoadLoad or acquire barrier between the read of isFrozen and the read of target.
28-05-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a6e25566cb56 User: vlivanov Date: 2019-11-26 16:20:15 +0000
26-11-2019
Solving this in general appears to require a "larval" bit to recognize when the object has escaped before the constructor exits.
19-11-2019