The current memory segment implementation defines a hierarchy with 3 concrete classes: one for heap segments, one for native segments and one for mapped segments.

Since there can be many kinds of heap segments (e.g. created from a byte[] or from a float[]) the current implementation is prone to type profile pollution problems: if enough heap segments are created (of different kinds), the JIT compiler will give up on speculating on the heap segment kind, which will then result in poor performances.

The solution is to create a sharp subclass for each heap segment case.