Details
-
Enhancement
-
Resolution: Fixed
-
P4
-
14
-
b08
Description
NoSafepointVerifier has two parameters. The first is used to "activate" the NoSafepointVerifier and is currently passed as true (or default to true).
The second parameter is verifygc which controls whether the GCVerifier base class will verify that GC is not active, and the GC counter has not changed.
The two conditions are related but different. NoSafepointVerifier doesn't imply that no GC can occur, or be occurring. Places in the code that found that NSV are called during a safepoint (generally during GC) pass !is_at_safepoint() to the verifygc parameter.
Currently all code passes true for the first parameter (except for in void Threads::non_java_threads_do).
If the NSV is called at a safepoint, it's effectively a nop.
The relationship of NSV and GCV is:
NSV GCV
------ -------
true true - default case for code running in VM code outside safepoints
true false - special case for JRT_LEAF code - can run GC if coming from native
nop false - needed case for calls when the code is at a safepoint (CLDG code that can run inside and outside a safepoint has a NSV that should be disabled inside a safepoint as well)
nop true - There are some places in the code where the default parameters to NSV are used, and are at a safepont with the VMThread, which are effectively a NoGCVerifier. These places seem accidental.
This RFE is to fix NoSafepointVerifier so that the is_at_safepoint() condition doesn't need to be passed as a parameter since all cases should disable NSV checking and GCV checking when the VM is at a safepoint.
Since checking that the VM does not reach a safepoint with NSV implies that the GC count cannot increase, it seems that but all for the special case of JRT_LEAF, that NSV => NGCV. Since we can't think of a case where NoGCVerifier would be useful on it's own, we should remove NoGCV.
The second parameter is verifygc which controls whether the GCVerifier base class will verify that GC is not active, and the GC counter has not changed.
The two conditions are related but different. NoSafepointVerifier doesn't imply that no GC can occur, or be occurring. Places in the code that found that NSV are called during a safepoint (generally during GC) pass !is_at_safepoint() to the verifygc parameter.
Currently all code passes true for the first parameter (except for in void Threads::non_java_threads_do).
If the NSV is called at a safepoint, it's effectively a nop.
The relationship of NSV and GCV is:
NSV GCV
------ -------
true true - default case for code running in VM code outside safepoints
true false - special case for JRT_LEAF code - can run GC if coming from native
nop false - needed case for calls when the code is at a safepoint (CLDG code that can run inside and outside a safepoint has a NSV that should be disabled inside a safepoint as well)
nop true - There are some places in the code where the default parameters to NSV are used, and are at a safepont with the VMThread, which are effectively a NoGCVerifier. These places seem accidental.
This RFE is to fix NoSafepointVerifier so that the is_at_safepoint() condition doesn't need to be passed as a parameter since all cases should disable NSV checking and GCV checking when the VM is at a safepoint.
Since checking that the VM does not reach a safepoint with NSV implies that the GC count cannot increase, it seems that but all for the special case of JRT_LEAF, that NSV => NGCV. Since we can't think of a case where NoGCVerifier would be useful on it's own, we should remove NoGCV.
Attachments
Issue Links
- relates to
-
JDK-8228673 Remove develop flag StrictSafepointChecks
-
- Resolved
-
-
JDK-5103339 Strengthen NoSafepointVerifier
-
- Resolved
-