Use of long in Nashorn

[Attila Szegedi]

Well, we could just box them in that case. If we only used int and double as primitive number types internally, then a natural representation for a long becomes Long. Java methods returning long could have an optimistic filter that first checks if the value fits in an int (32-bit signed), then in a double (53-bit signed) without loss of precision, and finally deoptimizes to Object and uses Long. int->long->double->Object becomes int->double->Object, with longs of too large magnitude becoming boxed.

Attila.

> On Nov 13, 2015, at 2:46 PM, Jim Laskey (Oracle) <james.laskey at oracle.com> wrote:
> 
> 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.
>> 
>