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

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: [8u] 8087342: crash in klassItable_initialize_itable_for_interface
From:       David Buck <david.buck () oracle ! com>
Date:       2017-01-31 12:19:11
Message-ID: 589080BF.3020204 () oracle ! com
[Download RAW message or body]

Hi David and Karen,

Thank you both for looking at my backport!

 > 1) copyright in  TestStaticAndInstance.java would now be 2015,2017

Fixed. Thank you for the catch!

 > 2) You said you back ported most of 8087342 - what part did you not 
back port?

I assume you meant to ask about 8067480, I backported *all* of 8087342. 
For 8067480, the change in behavior (the actual fix) was already 
backported to 8u as part of 8064524 (a security fix), so the 
"functional" part of 8067480 was already done in 8u. So in a sense, in 
this backport, from 8067480 I only brought back the refactoring (in 
addition to 8087342 of course). Perhaps I could have chosen my wording 
better. The point is that once this change is pushed to 8u-dev, both 
8067480 *and* 8087342 should be fixed; I was very careful not to unfix 
the work done in 8064524.

 > 3) testing - In addition to the specific test here, did you run the 
defmeth tests and the SelectionResolution tests?

Thank you for helping me (off line) to run these tests!

All of the SelectionResolution tests run and pass.

As for the defmeth tests, I checked out the last revision of vmtestbase 
before JDK 9 build tags started being added (caf1bcbf8df9) and used that 
for testing. With this revision, a number of test cases fail OOTB 
without my change (162 out of 696). I tried several OracleJDK update 
releases (8u25 and 8u121) and they too also failed the exact same test 
cases. So I assume that the these are issues with the test cases 
themselves and not an indication of problems with the JDK/JVM being 
tested. Of course, with my backport only the same set of failures is 
seen; there is no sign of any regression as a result of the backport.

Cheers,
-Buck


On 2017/01/28 0:56, Karen Kinnear wrote:
> David Holmes,
> 
> Java 8 allowed private interface methods in generated code. Specifically the lambda \
> metafactory used them, so from a JVM perspective, they need to be supported.
> 
> David Buck,
> 
> Many thanks for back porting. It was a good idea to back port the 8067480 changes \
> to keep the arguments consistent - the complexity was getting too messy.
> 
> The code changes look great!
> 
> Questions/Comments:
> 
> 
> 1) copyright in  TestStaticAndInstance.java would now be 2015,2017
> 2) You said you back ported most of 8087342 - what part did you not back port?
> 3) testing - In addition to the specific test here, did you run the defmeth tests \
> and the SelectionResolution tests? 
> thanks,
> Karen
> 
> 
> 
> > On Jan 26, 2017, at 7:22 PM, David Holmes <david.holmes@oracle.com> wrote:
> > 
> > Hi David,
> > 
> > We don't allow private interface methods in Java 8 at the language level. So I'm \
> > not clear what should be expected here. ?? 
> > Thanks,
> > David H.
> > 
> > On 27/01/2017 12:04 AM, David Buck wrote:
> > > Hi!
> > > 
> > > Please review this backport of 8087342 to 8u-dev.
> > > 
> > > bug report: https://bugs.openjdk.java.net/browse/JDK-8087342
> > > 
> > > JDK 9 push: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5e09f372116b
> > > 
> > > JDK 9 review thread (2 parts):
> > > 
> > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-July/015436.html
> > >  
> > > 
> > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-August/015602.html
> > >  
> > > 
> > > JDK 8u webrev: http://cr.openjdk.java.net/~dbuck/8087342_01/
> > > 
> > > The backport was relatively straightforward. The only minor complication
> > > was the refactoring done as part of 8067480 [0]. 8067480 itself did not
> > > need to be backported from 9 to 8u because that issue did not apply to
> > > 8u by the time it was fixed in 9. But the refactoring done for 8067480
> > > seemed to be the only reasonable way to backport 8087342 and keep the
> > > code readable. (If I had just added yet another bool flag to each of
> > > these methods, it would have been *way* to easy to get parameters
> > > confused.)
> > > 
> > > So the best way to look at this changeset is as a backport of both
> > > 8087342 and (most of) 8067480.
> > > 
> > > [0]
> > > https://bugs.openjdk.java.net/browse/JDK-8067480
> > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d656b4c91d51
> > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-January/013717.html
> > >  
> > > 
> > > Cheers,
> > > -Buck
> 


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