Better representation of Int64 on platforms that support unboxed int64 integers

[mkustermann]

The current implementation of Int64 stores the underlying integer as 3 integer fields:

class Int64 implements IntX {
  // A 64-bit integer is represented internally as three non-negative
  // integers, storing the 22 low, 22 middle, and 20 high bits of the
  // 64-bit value.

  final int _l, _m, _h;
  ...
}

Operations to/from a Dart int as well as arithmetic/bitwise operations will be slow due to need to operate on the combination of three fields.

On platforms such as the Dart VM or Dart2WasmGC we have support for unboxed int64 values where this overhead can be entirely avoided.

There's two improvements

• Use e.g. conditional imports to select better representation for Int64 on VM / Dart2WasmGC than for Dart2Js
• Possibly avoid the creation of Int64 boxes entirely by having mechanism to pass unboxed values around

/cc @askeksa-google (since we just talked about it), @osa1 , @mraleph

[mraleph]

I think it is related (duplicate of #88).

I think with inline class we could even consider going all in and making Int64 an unboxed value. It's going to be a breaking change but much smaller one then before.

[mkustermann]

I think with inline class we could even consider going all in and making Int64 an unboxed value. It's going to be a breaking change but much smaller one then before.

I was thinking the same. But inline classes afaik are restricted to one member, so for dart2js one still needs multiple integers to represent an int64. Maybe it could be one inline class that is either based on unboxed int64 on VM or on a boxed value for dart2js.