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

Sangheon Kim sangheon.kim at oracle.com
Thu Nov 27 06:13:06 UTC 2014


Thank you all for reviewing this.
And I filed a new JDK-8066075 
<https://bugs.openjdk.java.net/browse/JDK-8066075> for enhancement of 


On 11/26/2014 12:36 PM, Kim Barrett wrote:
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20141126/83b4ea42/attachment.html>

More information about the hotspot-gc-dev mailing list