POC: test non-boxed, primitive collection storage with reflection

[l0rinc]

I created a POC (not to be merged), demonstrating non-boxed primitive storage for Vector.

That is, if a Vector is created with a primitive wrapper type (e.g. Vector<Integer>), the internal array will be of the corresponding primitive type (e.g. int[]) instead of the boxed type (e.g. Integer[]).
All operations on the Vector's internal array are implemented using reflection or via specialized checks.

The memory usage for unboxed primitive storage is very promising, i.e. uses up to ~4x less memory than ArrayList or boxed Vector:

for 1024 elements
`java.util.ArrayList` uses `18.6 KB` (`0 bytes` overhead, `0.0` bytes overhead per element)
`javaslang.collection.BoxedVector` uses `19.3 KB` (`664 bytes` overhead, `0.6` bytes overhead per element)
`javaslang.collection.Vector` uses `4.7 KB` (`-14240 bytes` overhead, `-13.9` bytes overhead per element)

Boxed, no reflection (original implementation):

Operation   Impl                Params            Score  ±  Error  Unit
Create      slang_persistent      1024      550,181.653  ±  6.17% ops/s
Head        slang_persistent      1024  273,522,239.620  ± 15.05% ops/s
Get         slang_persistent      1024      253,750.035  ±  1.97% ops/s

Boxed, with reflection - without primitive conversion:

Operation   Impl                Params            Score  ± Error   Unit
Create      slang_persistent      1024      235,575.521  ± 2.90%  ops/s
Head        slang_persistent      1024   21,594,009.129  ± 0.77%  ops/s
Get         slang_persistent      1024       11,254.908  ± 1.70%  ops/s

Primitive, with reflection - note: uses ~4x less memory:

Operation   Impl                Params            Score  ± Error   Unit
Create      slang_persistent      1024       23,179.890  ± 1.36%  ops/s
Head        slang_persistent      1024   14,401,390.967  ± 2.22%  ops/s
Get         slang_persistent      1024        8,707.254  ± 1.84%  ops/s

i.e. ~10-50 times slower.

However, simple specialization (e.g. if Vector were an interface with e.g. IntVector/CharVector children) reveals (note: uses ~4x less memory):

Operation Impl                  Params            Score  ± Error   Unit
Create    slang_persistent        1024      279,322.949  ± 3.44%  ops/s
Create    slang_persistent_int    1024      655,092.717  ± 1.46%  ops/s

Head      slang_persistent        1024  168,508,482.722  ± 0.83%  ops/s
Head      slang_persistent_int    1024  269,753,246.425  ± 0.91%  ops/s

Get       slang_persistent        1024       78,920.869  ± 0.87%  ops/s
Get       slang_persistent_int    1024      252,564.494  ± 2.06%  ops/s

which is only ~60% of the original speed with boxed end result (i.e. a get that returns an Integer).
If we provide specialized methods (which could be accessed via casting to IntVector), it would have the same speed as the original (using a lot less memory).

---

EDIT:
specialized for most primitives and the numbers are pretty good! (26cbb13#diff-c6c1876105d111251f38e0916d4d99a4R75)
Also, I found a way of avoiding boxing at the end (making te whole solution viable), take a look :)

Operation  Impl                 Params            Score  ± Error   Unit
Create     slang_persistent       1024      353,200.887  ± 7.15%  ops/s
Create     slang_persistent_int   1024      711,118.523  ± 1.79%  ops/s

Head       slang_persistent       1024  144,142,491.461  ± 1.36%  ops/s
Head       slang_persistent_int   1024  207,905,574.556  ± 0.95%  ops/s

Get        slang_persistent       1024      106,121.968  ± 1.50%  ops/s
Get        slang_persistent_int   1024      214,445.932  ± 1.49%  ops/s

Iterate    slang_persistent       1024      116,656.843  ± 1.49%  ops/s
Iterate    slang_persistent_int   1024    2,163,161.600  ± 1.42%  ops/s

[l0rinc]

related to #1449

[l0rinc]

change this to

public static Class<?> toPrimitive(Class<?> wrapper) {
    return wrapper;
}

to disable primitive conversion

[l0rinc]

@danieldietrich, @zsolt-donca, @eduardmanas, @ruslansennov, @gpanther, opinions?

[l0rinc]

separated all the reflective calls

[danieldietrich]

Hi Lorinc,

thank you for the investigation and the resulting insights. Javaslang will not provide specializations for generic types (at least in the core module). My vision is to leverage http://openjdk.java.net/jeps/218 to get around the current restrictions of generics.

We could think about an additional module (javaslang-specialized?) that contains special versions of our collections but I think it is not worth the effort - it will lead to a maintenance hell because all changes to the core have to be duped to that module. Who will maintain it over time?

From the very beginning of Javaslang I decided to live with the shortcomings of the language (null, Objects vs. primitives, ...). That's the reason there are no specializations.

DD

[l0rinc]

getting the array that contains the given index enables the user to avoid boxing :)
package private for now, could be used internally in CharSeq or BitSet

[l0rinc]

non-boxed head access

[l0rinc]

@danieldietrich, it seems I managed to work around the problem that specialization can have, i.e. I don't have to repeat any algoriths, it's contained in general getter/setter/newInstance/getLength methods, as seen in the code (no need for specialized subclasses).

Also, not everybody can wait another 4 years for automatic specialization to appear, especially that this POC proved to be a viable alternative :).
Will try to apply it to the whole Vector impl to see what benefits/drawbacks it has.
Please bare with me :).

[l0rinc]

My first full primitivization attempt for Vector: 212242a#diff-5f4a536088f7f19a51ebbef20cf7b3ef

The code looks basically the same, the only significant change in the algorithm is the way we access the array, i.e. instead of a[b] = c we have setAt(a, b, c).
Will investigate the reason why append and prepend are slower now, but otherwise the primitive internals are a lot faster for many methods (e.g. create and iterate are 3-5x faster, using 4x less total memory) :)

@danieldietrich, @ruslansennov, opinions :)?