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

Bengt Rutisson bengt.rutisson at oracle.com
Wed Nov 26 14:50:21 UTC 2014


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.

Bengt

>
> Jon
>
>>
>>
>>
>



More information about the hotspot-gc-dev mailing list