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