Primitive boolean array packing
maurizio.cimadamore at oracle.com
Mon Oct 8 16:30:05 UTC 2018
what you describe here is also overlapping with Project Panama, which
allows you to define a Java wrapper for a packed struct using layout
descriptions. If you go down that path, you can, I believe, address the
memory footprint issues w/o touching the VM (e.g. by changing the
implementation of some of these classes to use Panama structs). Could be
a worthwhile experiment to try and do that!
On 06/10/18 23:05, B. Blaser wrote:
> Per JVMS, primitive boolean arrays are currently using 8 bits (one
> byte) per boolean value, see  (baload/bastore).
> We've see in some threads  that 'BitSet' or 'EnumSet' are
> occasionally preferred solutions as they are using boolean vectors
> (aka long values) using 8x less memory.
> But as the spec  allows primitive boolean array packing, I made a
> quick experiment which is available here:
> This is a partial draft implementing primitive boolean array packing
> (8x smaller) at machine-level (vs BitSet at class-level):
> * only x86 interpreter implemented => c1/c2/inlining disabled for
> methods using baload/bastore (not much performance regression when
> building the jdk and running the tests)
> * unsafe access partially implemented
> * array copy currently not implemented
> * -XX:+/-BooleanPacking to enable/disable the feature currently not implemented
> A couple of residual tier1 tests are still failing due to the
> unfinished implementation.
> I didn't search much if such experiments have already been
> accomplished, but I'd like to take the temperature of this feature as
> completing the implementation represents a significant amount of work.
> Is this something that is worth exploring?
> Thanks in advance for any feedback.
>  https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.baload
>  http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012504.html
More information about the jdk-dev