RFR (S) 8228630: Remove always true parameter to NoSafepointVerifier

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Jul 31 11:39:12 UTC 2019

On 7/31/19 1:01 AM, David Holmes wrote:
> Hi Coleen,
> On 31/07/2019 6:45 am, coleen.phillimore at oracle.com wrote:
>> Summary: Also remove NoGCVerifier since NoSafepointVerifier covers GC 
>> checking when not already at a safepoint and is a stronger check.
> It wasn't at all clear to me that we may not want a NoGCVerifier that 
> is independent of safepoints e.g. for use in a non-JavaThread. But 
> AFAICS we don't use NoGCVerifier directly, but only via 
> NoSafepointVerifier - in which case the "no safepoint" check subsumes 
> the "no gc" check and the whole thing collapses to what you have 
> (which results in a nice amount of code deletion!).

Yes, it took me a lot longer to come to this conclusion and 
justification despite my bias.  Erik and Kim couldn't think of any 
reason for a gc thread, for instance, to have a NoGCVerifier outside of 
a NoSafepointVerifier either.
> It took me a while to follow through all the changes but it seems good.
> I spotted this reference to NoGCVerifier:
> ./share/opto/runtime.cpp:// Thus, it cannot be a leaf since it 
> contains the NoGCVerifier.
> I'm not at all sure that the rest of the comment related to this is 
> accurate any more - the reference to the NoGCVerifier didn't make 
> sense to me.
Thanks, I didn't find that usage after I removed NoGCVerifier.  What a 
terrifying comment.  I'm not going to change it other than:

// Thus, it cannot be a leaf since it contains the NoSafepointVerifier.

JRT_LEAF contains a NoSafepointVerifier.  I think the code doesn't want 
to change state to _thread_in_vm but it may safepoint.  I don't see 
where though.  I'll leave it to someone who knows the compiler better if 
they want to clean this up.

> Thanks,
> David
> -----
>> See bug for more details also.  Tested with all jtreg 
>> runtime,compiler,serviceability and gc tests. Also hs-tier1-3 on 
>> linux-x64-debug.
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8228630.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8228630
>> Thanks,
>> Coleen

More information about the hotspot-runtime-dev mailing list