Provide long specializations of basicimpl?

[PhilippWendler]

For the solvers where long is used as representation of formulas, we currently use the basicimpl package and instantiate the generic parameters with Long. This means that auto-boxing occurs, for example when creating a formula: first, all parameter Formulas are unwrapped, then their longs are auto-boxed to Long, then unboxed, then the solver is called and returns a long for the new formula, which is immediately boxed to Long and unboxed again before the long is stored in the resulting Formula. Similarly for visitors etc. Long instances are not cached by the JVM. The Formula instances refer to long to avoid needing two object instances for every single Formula.

A copy of the basicimpl package that hardcodes long would avoid this.

I am not sure whether this would be a performance improvement. Conventional wisdom is that temporary objects like these are basically "free" (do not cost GC time). On the other hand, Java 8 added specializations of all their functional interfaces for int, long, and double, so they must have thought this to be faster. Not sure whether this applies to our use case.

An alternative would be to go in the other direction: remove the long specializations of Formula and store Longs in them. We create these Long instances anyway, so if we keep them in the Formula, we will use more memory, but avoid re-boxing the values when using the formulas, e.g., as parameters to new formulas.

[cheshire]

I think it's very hard to say anything about this. My guess would be that JIT should be able to detect boxing and subsequent unboxing and optimize it away.

[PhilippWendler]

Doesn't "wontfix" mean this should be closed? But why was it labeled with this?