RFR: 8036699: Add trace event when a metaspace allocation fails
erik.helin at oracle.com
Mon Mar 17 12:40:19 UTC 2014
(this reply went to the wrong RFR, reposting to get it back on to the
right thread, sorry for the noise)
Based on a discussion with Jon Masamitsu and StefanK, I've decided to
change metadata_type_name to return a slightly more user-friendly value.
Please see new webrev at:
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:
> For an incremental webrev (that only removes the native stack walking
> code) please see:
> 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.
>> - 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.
More information about the hotspot-dev