Use of long in Nashorn

[Jim Laskey (Oracle)]

The main thing to watch for here is that longs/Longs need to survive unobstructed between Java calls.  Remember we ran into trouble in this area (loss of precision when using longs for encoding.)




> On Nov 13, 2015, at 8:26 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
>> 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.
>