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.las...@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.szeg...@oracle.com> >> wrote: >> >>> On Nov 13, 2015, at 10:31 AM, Hannes Wallnoefer >>> <hannes.wallnoe...@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. >> >
