RFR(XS): 8153275: Zero JVM fails to initialize after JDK-8152440

[Severin Gehwolf]

Hi,

On Wed, 2016-04-06 at 14:59 -0400, Andrew Hughes wrote:
> ----- Original Message -----
> > 
> > On 04/04/16 18:44, Severin Gehwolf wrote:
> > > 
> > > Hi,
> > > 
> > > Could somebody please sponsor and review the following Zero-only
> > > fix?
> > > The fix for JDK-8152440 was incorrect in that it set the value
> > > for InitArrayShortSize to an illegal value (-1) failing
> > > constraint
> > > validation. Albeit not being used it must still pass constraint
> > > validation. Otherwise, the JVM fails to initialize and all bets
> > > are
> > > off. Thoughts?
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153275
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153275/
> > > webrev.01/
> > OK, but please make the comment clearer.  I didn't understand it.
> > 
> >  "the allowed range [ 0 ... 9223372036854775807 ]"
> > 
> > is much clearer.
> > 
> > Andrew.
> > 
> > 
> Maybe using 2^63-1 for the max range would be even clearer? Or
> 0x7FFFFFFFFFFFFFFF, which is what is used in globalDefinitions.hpp.
> 
> It's also wrong for 32-bit architectures; the range there is 0 ...
> 0x7FFFFFFF
> or 0 ... 2^31-1.
> 
> From globalDefinitions.hpp:
> 
> typedef intptr_t  intx;
> const intx  min_intx  = (intx)1 << (sizeof(intx)*BitsPerByte-1);
> const intx  max_intx  = (uintx)min_intx - 1;

Thanks for the review!

I've avoided adding the actual range values in the comment altogether
and hopefully this is better:

http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8153275/webrev.03/

Cheers,
Severin