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

Thomas Stuefe stuefe at openjdk.java.net
Wed Mar 31 04:54:26 UTC 2021


On Tue, 30 Mar 2021 22:46:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> I deleted this branch by mistake, now restored.
>>> 
>>> > I'm not sure this is correct. Your new non-TRAPS Metaspace::allocate() would fail every time the GC threshold is touched. Where the old TRAPS version would break through the threshold and allocate successfully.
>>> 
>>> I realize this. It's just an attempt to allocate and it's designed to be used during a safepoint for only this allocation. I could change this to only call the non-TRAPS version of MethodCounters if we're at a safepoint? Would that help? Then the only time we'll miss out on metaspace counters periodically is if they were created to set breakpoints in a safepoint.
>> 
>> I think that would be better. I am unclear on what happened in this case before; did we also miss out on allocating the Counters?
>> 
>>> 
>>> I'd hate for this special case to know more about metaspace, ala calling ClassLoaderMetaspace::expand_and_allocate.
>> 
>> Even within Metaspace::allocate(no TRAPS)? Its in metaspace land, surely it would be fine to call expand there like this:
>> 
>> MetaWord* Metaspace::allocate(ClassLoaderData* loader_data, size_t word_size, MetaspaceObj::Type type) {
>>   MetaWord* result = loader_data->metaspace_non_null()->allocate(...);
>>   if (!result) {
>>     MetaWord* result = loader_data->metaspace_non_null()->expand_and_allocate(...);
>>   }
>> 
>> (Note that I will be gone into vacation shortly and I'm a bit short on time; I'm not sure I can finish this review. If you go with your approach, my only request would be to comment the prototypes for the two allocate functions a bit clearer and/or maybe rename one as allocate_no_exception or the other as allocate_with_exception)
>
>> I think that would be better. I am unclear on what happened in this case before; did we also miss out on allocating the Counters?
> 
> Before this change, it was very unlikely that allocating metaspace counters in a breakpoint safepoint ran out of memory, so never threw the exception.  Or else they did and returned NULL and all of the code around their allocation has handling for a null return.  We're working on enforcing what should be a rule that only JavaThreads can throw exceptions and this was an exception to that. :)
> 
>> Re: expand_and_allocate()
> 
> I didn't want to expose internal metaspace functions or more handling for this special case, and that would prevent the nice sharing of most of the Metaspace::allocate code. It's allowed for method counters to return NULL here.  If it's not long term, we should move the breakpoint counters to Method (but it would increase Method by a pointer size, which isn't good).
> 
> I will rename the functions as requested.  Have a nice vacation and thank you for your comments.

Thanks for explaining! I am fine with the change in this case.

-------------

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


More information about the hotspot-dev mailing list