RFR: 8264149 BreakpointInfo::set allocates metaspace object in VM thread [v3]

David Holmes david.holmes at oracle.com
Tue Mar 30 23:41:11 UTC 2021


On 31/03/2021 8:37 am, Coleen Phillimore wrote:
> On Tue, 30 Mar 2021 03:53:54 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Make which version of MethodCounters::allocate() is called clearer.
>>
>> src/hotspot/share/oops/method.cpp line 570:
>>
>>> 568:   if (current->is_Java_thread()) {
>>> 569:     Thread* THREAD = current;
>>> 570:     counters = MethodCounters::allocate(mh, THREAD);
>>
>> Can you add a comment before this line:
>>
>> // Use the TRAPS version for a JavaThread so it will adjust the GC  threshold if needed.
>>
>> Thanks.
> 
> ok, yes that says why.
> 
>> src/hotspot/share/oops/method.cpp line 572:
>>
>>> 570:     counters = MethodCounters::allocate(mh, THREAD);
>>> 571:     if (HAS_PENDING_EXCEPTION) {
>>> 572:       CLEAR_PENDING_EXCEPTION;  // MethodData above doesn't clear exception
>>
>> I don't understand the comment.
> 
> It's sort of a question, because the above code that does the same thing for MethodData doesn't clear the exception.  In this case we should clear the exception I believe.  I'll remove the comment.

Ah I see. All the callers of build_interpreter_method_data clear the 
exception themselves, rather than it being cleared internally. That 
seems odd.

>> src/hotspot/share/oops/method.cpp line 575:
>>
>>> 573:       CompileBroker::log_metaspace_failure();
>>> 574:       ClassLoaderDataGraph::set_metaspace_oom(true);
>>> 575:       return NULL;
>>
>> You could factor this out for both cases by testing "counters == NULL".
> 
> Yes, this is better.

Refactoring looks good!

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3207
> 


More information about the hotspot-dev mailing list