RFR(s): 8228758: assert(_no_handle_mark_nesting == 0) failed: allocating handle inside NoHandleMark

[Robbin Ehn]

Hi Coleen,

>>
>> So if you don't a very strong opinion about it, I really like to get rid of it.
> 
> I'd really like for you to get rid of it too because it doesn't make sense, and 
> I've already wasted too much of my time to try to figure out that it doesn't 
> make sense.   More below.
> 
> Your change looks good to me.  There's a VM_QUICK_ENTRY_MARK that's 
> broken/similar in share/ci/ciUtilities that should be cleaned up too but you can 
> file another RFE for it.

Thanks. Yes.

> 
>>
>> Thanks, Robbin
>>
>> Some extra words about NoHandleMark:
>> I believe NoHandleMark should be removed.
>> In the LEAF case, there is no point in creating a Handle within a
>> NoSafepointVerifier, since we don't safepoint.
>> The other usecase seems to be, I'm in java don't do VM things, and someone tried
>> to protected that with a NoHandleMark. There many ways to create a much more
>> robust check for that.
>> But a discussion for another time.
>>
> 
> Looking through the code, I've come to the same conclusion.  I'm pretty sure 
> most of it can be removed, in favor of adding an assert that the JavaThread 
> state is _thread_in_vm in the Handle constructor.   Also a lot of these 
> NoHandleMark and ResetNoHandleMarks are leftover from permgen when metadata 
> needed to be handled.  They don't seem to apply to oops in the places where they 
> are.  I think we should file some RFEs to clean them up.

Great!

/Robbin

> 
> Thanks,
> Coleen
> 
>>
>>>
>>> Thanks,
>>> David
>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8228758
>>>>
>>>> Changeset:
>>>> http://cr.openjdk.java.net/~rehn/8228758/webrev/
>>>>
>>>> Passes t1-3 (and performance benchmarks)
>>>>
>>>> Thanks, Robbin
>