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. >
