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

[Kim Barrett]

On Nov 26, 2014, at 9:50 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> 
> 
> On 2014-11-25 19:19, Jon Masamitsu wrote:
>> 
>> On 11/24/2014 11:37 AM, Kim Barrett wrote:
>>> On Nov 24, 2014, at 1:52 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>>>> 
>>>> On 11/24/2014 10:06 AM, Kim Barrett wrote:
>>>>> [...]
>>>>> All that said, a more complete and cleaned up fix for the ParScanThreadState[Set] reuse problem should also suffice, e.g. either don't reuse or capture / report data and reinitialize before reuse.
>>>> I'd suggest that this to be a separate (from fixing this failure) effort.
>>>> OK if this more extensive clean up is deferred.  I can create a new CR for it.
>>>> Priority?
>>> Is there an urgency to fixing the failure that makes it worth putting in code that
>>> we think we’ll be taking back out later?  (Perhaps even sooner than later?)  I’m
>>> not suggesting there isn’t, just wondering if there is.  I also think it might not
>>> be all that difficult, but of course I haven’t actually done the work to prove that!
>> 
>> I think the fix is simple so not much of a burden to fix the bug. The only
>> urgency currently is getting the bug back log down and avoiding this failure
>> is future testing.  It was ranked P3 so higher that many bugs.
>> 
>> This fix identifies the cause and is the fix that could be backported if needed.
>> I don't think a larger change that deals with the ParScanThreadState reuse
>> issue should be backported.  There will be unknown risks in that.
> 
> Agreed. I think the proposed patch looks good.
> 
> Reviewed from my side.
> 
>> 
>> I would suggest starting the ParScanThreadState reuse improvement now
>> while we still remember what it is so I'm not suggesting a delay.
> 
> Sounds like a good plan.

Agreed.