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

Erik Helin erik.helin at oracle.com
Thu Mar 13 16:03:29 UTC 2014


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/

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