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