RFR(s): 8055239: assert(_thread == Thread::current()->osthread()) failed: The PromotionFailedInfo should be thread local.

[Kim Barrett]

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].