S RFR: Lambda: verification error in generated lambda classes

David Holmes david.holmes at oracle.com
Thu Aug 29 19:09:13 PDT 2013


On 30/08/2013 4:02 AM, Keith McGuigan wrote:
> I think there's an extra set of parenthesis that isn't needed, but other
> than that, thanks, looks good!

Agreed on all three counts (extra, not needed, good) :)

I still had to write out the truth table to be certain :)

Thanks,
David

>
> On Thu, Aug 29, 2013 at 1:29 PM, Karen Kinnear <Karen.Kinnear at oracle.com
> <mailto:Karen.Kinnear at oracle.com>> wrote:
>
>     Keith, David,
>
>     Many thanks for the suggestions. I think Keith's proposal is much
>     simpler to read. I did
>     a name change as well to hopefully make this more obvious.
>
>     webrev.02:
>>
>>         >> webrev: http://cr.openjdk.java.net/~acorn/8023872.02/webrev/
>>         >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>
>     I redid the manual testing, and the longer tests are in progress again.
>
>     thanks,
>     Karen
>
>     On Aug 28, 2013, at 10:31 PM, Keith McGuigan wrote:
>
>>     I think it's ok as it is, if you need to check it in quick, but I
>>     agree that this probably should be rewritten better to make the
>>     logic more obvious.  Maybe separate clauses for reflection/lambda
>>     code?
>>
>>         ((!is_MAI && !is_MLI) ||
>>         (is_MAI && VerifyReflectionBytecodes) ||
>>         (is_MLI && VerifyLambdaBytecodes))
>>
>>     Isn't this equivalent to:
>>       (!is_MAI || VerifyReflectionBytecodes) &&
>>       (!is_MLI || VerifyLambdaBytecodes)
>>
>>
>>
>>     On Wed, Aug 28, 2013 at 8:50 PM, Karen Kinnear
>>     <Karen.Kinnear at oracle.com <mailto:Karen.Kinnear at oracle.com>> wrote:
>>
>>         Thank you David. I agree, I was tempted to rewrite the entire
>>         method - in particular, in a debugger
>>         (so I didn't check the optimized code) we walk the entire &&
>>         before we make the initial call - in this
>>         case the initial call would weed out more things faster
>>         potentially, so ... But I chose not to rewrite since
>>         they need this quickly and the shaking out would take quite a
>>         bit longer.
>>
>>         thanks for the review,
>>         Karen
>>
>>         On Aug 28, 2013, at 8:48 PM, David Holmes wrote:
>>
>>         > Hi Karen,
>>         >
>>         > I found the boolean logic very hard to follow there - not
>>         sure if the refactoring helped or hindered :)
>>         >
>>         > But it looks okay.
>>         >
>>         > David
>>         >
>>         > On 29/08/2013 5:42 AM, Karen Kinnear wrote:
>>         >> Please review - lambda team needs this change to get in by
>>         tomorrow so
>>         >> they can push
>>         >> the (8010433) metafactory change which is waiting on the
>>         vm. Thanks.
>>         >>
>>         >>
>>         >> webrev: http://cr.openjdk.java.net/~acorn/8023872/webrev/
>>         >> http://bugs.sun.com/view_bug.do?bug_id=8023872
>>         >>
>>         >> Testing:
>>         >> The failure comes if you apply an early patch of 8010433 to
>>         the jdk and
>>         >> do not
>>         >> make the vm change. So testing included 4 binaries: master,
>>         newjdk,
>>         >> newvm, newjdkvm
>>         >>
>>         >> jtreg for SpinedBufferTest with various flags - these are
>>         the expected
>>         >> results below
>>         >> The key point is newjdk -Xverify: all fails
>>         >> newjdkvm -Xverify:all passes, but if you also turn on
>>         >> -XX:+VerifyLambdaBytecodes you see
>>         >>    the verification error
>>         >>
>>         >> 1. master
>>         >>  no flags: timed out
>>         >>  -Xverify:all: timed out
>>         >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>         >>
>>         >> 2. newjdk
>>         >>  no flags: timed out
>>         >>  -Xverify:all
>>         >>    java.lang.BootstrapMethodError: call site initialization
>>         exception
>>         >> ... cause:
>>         >>      VerifyError: Bad invokespecial instruction: current
>>         class isn't
>>         >> assignable to reference class
>>         >>  -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>         >>
>>         >> 3. newvm
>>         >>   no flags: timed out
>>         >>   rerun.sh: -Xverify:all: passed
>>         >>   -XX:+VerifyReflectionBytecodes: VerifyError in reflection
>>         >>   -XX:+VerifyLambdaBytecodes: passed, didn't try verification
>>         >>   rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes: passed
>>         >>
>>         >> 4. newjdkvm
>>         >>  rerun.sh: no flags: passed
>>         >> rerun.verify.sh <http://rerun.verify.sh/>: -Xverify:all: passed
>>         >>  rerun.sh: -Xverify:all -XX:+VerifyLambdaBytecodes:
>>         >>    Verification for
>>         java.util.streamIntPipeline$7$1$$Lambda$9 failed
>>         >>
>>         >> regression testing:
>>         >> newvm:
>>         >>   vm.quick.testlist - in progress
>>         >>   jtreg java/util/stream - in progress
>>         >>   jprt -stree . - in progress
>>         >>
>>         >> newvmjdk (Brian testing in lambda repo) - in progress
>>         >>
>>         >> thanks,
>>         >> Karen
>>         >>
>>
>>
>>
>>
>>     --
>>     - Keith McGuigan <keith.mcguigan at alumni.unh.edu
>>     <mailto:keith.mcguigan at alumni.unh.edu>>
>
>
>
>
> --
> - Keith McGuigan <keith.mcguigan at alumni.unh.edu
> <mailto:keith.mcguigan at alumni.unh.edu>>


More information about the hotspot-runtime-dev mailing list