RFR(s): 8055239: assert(_thread == Thread::current()->osthread()) failed: The PromotionFailedInfo should be thread local.
jesper.wilhelmsson at oracle.com
Mon Nov 24 22:44:38 UTC 2014
The major pain point throughout the JFR project was to figure out what
information to include in the events and if anyone actually needed some info.
Some events was gives from the start, we knew from JRockit experience that the
information was useful, but in many cases information has been included because
it was at hand. The promotion failure events was very much a case of the second
We knew it was useful to get information about promotion failures, but exactly
how to deliver that information and what details to pass along was not clear.
The thread info was initially added because it was there. Nobody asked for it.
Later it turned out to be hard to provide the same information in the evacuation
failed events in G1, and at that point, since we thought it would be nice it the
promotion failed events and the evacuation failed events looked the same, one of
the options discussed was to remove the thread info from the event. The
discussions lead to the RFE I linked to earlier that asks for thread info in the
evacuation failed events. But I repeat, nobody asked for this information, it's
there because it was easy to pass it along with the event.
I seriously doubt that anyone has stared to use this information out there, but
to know for sure we need to ask sustaining and PM.
Kim Barrett skrev 24/11/14 21:02:
> On Nov 24, 2014, at 1:06 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> I'm having a very hard time coming up with a way to make use of the
>> association of such summary promotion (or evacuation) failure
>> information with OS-level threads. The relevant context is long gone,
>> and the actual information being captured is pretty limited. I'd like
>> to see a real use-case.
> Here’s another idea. Do we actually need the OS-level thread id, or would the
> worker gang thread id be sufficient? The latter is captured in the ParScanThreadState
> object which the PromotionFailedInfo is associated with. We could pass it along
> to the info object at construction time, replacing the OS-level _thread with the worker
> gang thread id.
> This is still technically a message API change, but I think not a visible one; it looks to me
> as if the relevant primitive type in tracetypes.xml (“OSTHREAD”) is effectively a synonym
> for “U4”. The worker gang id is an int, but only small positive values are used.
> I think this change would be sufficient to address the proximate failure, though not
> addressing the larger issue of inappropriate / improper reuse of the thread state [set].
More information about the hotspot-gc-dev