Use of long in Nashorn

[Attila Szegedi]

> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Hi all,
> 
> I'm currently questioning our use of longs to represent numbers in combination with optimistic typing.

I often feel that the presence of longs is more hassle than they’re worth. I’d be all for eliminating them.

> After all, there's a pretty large range where long arithmetic will be more precise than the doubles required by ECMA.

There’s currently several different places in Nashorn where we try to confine the precision of longs to 53 bits (so they aren’t more precise than doubles). It’s a bit of a whack-a-mole where you can’t always be sure whether you found all instances.

> 
> For context see this bug, especially the last two comments (the original bug was about number to string conversion which has been solved in the meantime):
> 
> https://bugs.openjdk.java.net/browse/JDK-8065910
> 
> So the question is: can we use longs at all and be confident that results won't be too precise (and thus, strictly speaking, incorrect)?

Internally, the longs are also used for representing UInt32 even in non-optimistic setting, which is only really significant for the >>> operator and array indices and lengths; maybe we should limit longs to that usage only, or even just use doubles internally for UInt32 values that can’t be represented as Int32. FWIW, even for the >>> operator we only need it when shifting by zero, as in every other case the result will have the topmost bit set to 0 and thus fit in Int32 too.

I guess once Valhalla rolls around, we could easily have an unsigned 32 bit int type.

> Hannes

Attila.