JDK-8261192 : ciReplay: better replay of CHA queries
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2021-02-04
  • Updated: 2021-11-09
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.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8273919 - Improve compiler replay
Relates :  
JDK-8267979 - C2: Fix verification code in SubTypeCheckNode::Ideal()
Relates :  
JDK-8267947 - CI: Preserve consistency between has_subklass() and is_subclass_of()
Relates :  
JDK-8268676 - assert(!ik->is_interface() && !ik->has_subklass()) failed: inconsistent klass hierarchy
Description
ciReplay doesn't record CHA queries, so the queries could get different answers at replay time.  And the query answers that the compiler uses are not stable (for example the result of unique_concrete_subklass() can change).  Making them stable should reduce the amount of query information needed in the replay file.
Comments
After some investigation, I don't see an easy way to implement this without hurting performance. If, for example, we capture the fact that a class has no subclasses (has_subklass(), is_leaf_type(), unique_concrete_subklass()), but later on subclasses are loaded, it will cause problems. If there is a crash in the compiler, it won't be "replayable" without a rewrite of the replay implementation to output something looking like a query log. To simplify things, it seems best in my opinion that class hierarchy changes due to concurrent class loading and unloading should be invisible to the compiler. The compiler should operate on a snapshot of the class hierarchy, and abort the compile if concurrent changes have caused any dependencies to be broken. I don't know how to implementation a snapshot without perhaps unacceptable overhead. For class unloading, perhaps we can prevent it from being concurrent with the compiler by having the GC coordinate with the compiler threads through some kind of "compiler safepoint". For class loading, maybe a per-class counter or timestamp would be enough to prevent the compiler thread from seeing classes that we loaded after the compilation started.
26-10-2021