[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFR(s): 8055239: assert(_thread == Thread::current()->osthread()) failed: The PromotionFailedInf
From:       Sangheon Kim <sangheon.kim () oracle ! com>
Date:       2014-11-27 6:13:06
Message-ID: 5476C0F2.2010507 () oracle ! com
[Download RAW message or body]

Hi,

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

Sangheon


On 11/26/2014 12:36 PM, Kim Barrett wrote:
> On Nov 26, 2014, at 9:50 AM, Bengt Rutisson <bengt.rutisson@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@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.
> 


[Attachment #3 (text/html)]

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi, <br>
    <br>
    Thank you all for reviewing this.<br>
    And I filed a new <a id="key-val" rel="4757620"
      href="https://bugs.openjdk.java.net/browse/JDK-8066075">JDK-8066075</a>
    for enhancement of ParScanThreadStateSet.<br>
    <br>
    Sangheon<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/26/2014 12:36 PM, Kim Barrett
      wrote:<br>
    </div>
    <blockquote
      cite="mid:EF71B1EF-DDD7-4319-A3DC-5768550A7D0D@oracle.com"
      type="cite">
      <pre wrap="">On Nov 26, 2014, at 9:50 AM, Bengt Rutisson <a \
class="moz-txt-link-rfc2396E" \
href="mailto:bengt.rutisson@oracle.com">&lt;bengt.rutisson@oracle.com&gt;</a> wrote: \
</pre>  <blockquote type="cite">
        <pre wrap="">

On 2014-11-25 19:19, Jon Masamitsu wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">
On 11/24/2014 11:37 AM, Kim Barrett wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">On Nov 24, 2014, at 1:52 PM, Jon Masamitsu <a \
class="moz-txt-link-rfc2396E" \
href="mailto:jon.masamitsu@oracle.com">&lt;jon.masamitsu@oracle.com&gt;</a> wrote: \
</pre>  <blockquote type="cite">
              <pre wrap="">
On 11/24/2014 10:06 AM, Kim Barrett wrote:
</pre>
              <blockquote type="cite">
                <pre wrap="">[...]
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. </pre>
              </blockquote>
              <pre wrap="">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?
</pre>
            </blockquote>
            <pre wrap="">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! </pre>
          </blockquote>
          <pre wrap="">
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.
</pre>
        </blockquote>
        <pre wrap="">
Agreed. I think the proposed patch looks good.

Reviewed from my side.

</pre>
        <blockquote type="cite">
          <pre wrap="">
I would suggest starting the ParScanThreadState reuse improvement now
while we still remember what it is so I'm not suggesting a delay.
</pre>
        </blockquote>
        <pre wrap="">
Sounds like a good plan.
</pre>
      </blockquote>
      <pre wrap="">
Agreed.

</pre>
    </blockquote>
    <br>
  </body>
</html>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic