RFR: 8036699: Add trace event when a metaspace allocation fails

Stefan Karlsson stefan.karlsson at oracle.com
Mon Mar 17 09:03:07 UTC 2014


On 2014-03-13 17:03, Erik Helin wrote:
> Hi all,
>
> due to lack of reviewers for the native stack trace code, I've decided 
> to split this patch into two patches:
> - adding the event
> - adding the native stack trace information the event
>   (will be sent out later)
>
> This review request is now only for adding the event. Please see a new 
> webrev at:
> http://cr.openjdk.java.net/~ehelin/8036699/webrev.01/
>
> For an incremental webrev (that only removes the native stack walking 
> code) please see:
> http://cr.openjdk.java.net/~ehelin/8036699/webrev.00-01/

This diff looks good.

StefanK

>
> Thanks,
> Erik
>
> On 2014-03-06 10:00, Erik Helin wrote:
>> Hi all,
>>
>> this patch adds the new trace event vm/gc/metaspace/allocation_failure.
>> The event will be sent when we get an allocation failure in metaspace.
>> The event will contain the following information:
>> - classLoader - the class loader doing the allocation
>> - anonymousClassLoader - if the classLoader is anonymous
>> - nativeStackTrace - a VM stack trace (see more below)
>> - metadataType - the kind of metadata (class or non-class)
>> - metaspaceObjectType - the kind of metaspace object
>>
>> The field nativeStackTrace will contain a string representation of the
>> Threads C frames (up until the first Java frame). This is very useful
>> for debugging metaspace allocation failures coming from VM internals
>> such as the interpreter or GC code.
>>
>> I would especially appreciate if someone could look over the code in
>> metaspaceTracer.cpp performing the stack walking.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8036699/webrev.00/
>>
>> Enhancement:
>> https://bugs.openjdk.java.net/browse/JDK-8036699
>>
>> Testing:
>> - JFR JTREG tests
>> - JPRT
>> - Manual stress testing of the stack walking code by writing small test
>>    programs that causes metaspace allocation failures from both Java
>>    threads and non-Java threads.
>>
>> Thanks,
>> Erik



More information about the hotspot-dev mailing list