HotSpot and IBM's J9 behave a little different when verifying this class

[Tim Ellison]

I will bring this to the attention of the J9 verifier team and ask them to
comment on the behavior.

Regards,
Tim

On 14 Apr 2017 00:39, "Yuting Chen" <chenyt.cs.sjtu at gmail.com> wrote:

> It seems that J9 forgot to check the flags when athrow follows.
>
> On Thu, Apr 13, 2017 at 4:21 PM, Michael Rasmussen
> <michael.rasmussen at zeroturnaround.com> wrote:
> > On 14 April 2017 at 02:15, Yuting Chen <chenyt.cs.sjtu at gmail.com> wrote:
> >> Thanks, Remi and Michael.
> >>
> >> The difference appears only when all of the paths end in athrow. Then
> >> what does the comment ("Return TRUE if all code paths starting with
> >> start_bc_offset end in bytecode athrow or loop") in verifier.cpp mean?
> >> It seems that J9 follows this comment.
> >>
> >> Both verifiers can decline the class if "athrow" is changed to "return".
> >
> > Yes, for constructors, if exit is via return, then there cannot be any
> > uninitializedThis, but allowed if exit is via athrow.
> >
> > But, your problem is, that your two frame aren't assignable to each
> other.
> >>>> Current Frame:
> >>>>    bci: @1
> >>>>    flags: { flagThisUninit }
> >>>>    locals: { uninitializedThis, integer, integer }
> >>>>    stack: { integer }
> >>>>  Stackmap Frame:
> >>>>    bci: @11
> >>>>    flags: { }
> >>>>    locals: { top, integer, integer }
> >>>>    stack: { }
> >
> > While the locals are compatible, the flags are not, you cannot go from
> > { flagThisUninit } to {}
> > http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/file/tip/
> src/share/vm/classfile/stackMapFrame.cpp#l190
> >
> > /Michael
>