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

[Yuting Chen]

The bug has been fixed.  They suggested me to change a new version.
After all, it's interesting.

On Mon, Apr 17, 2017 at 12:57 PM, Tim Ellison <t.p.ellison at gmail.com> wrote:
> 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