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