Use --with-jvm-variants for identifying a 64 vs 64-compressedrefs build

[jdekonin]

Currently binaries are generating for the 64bit compressed platforms (default) and not the 64bit version. Using --with-jvm-variants would appear to be the option that should detail which one or both versions should be created.

[archanaNogriya]

@jdekonin
Where I can find what flag we need to pass which can create binary for noncompress 64 build? and where?
The JVM variants to build from, comma separated list that can include: server, client, kernel, zero and zeroshark.

[archanaNogriya]

However client VM is only available on 32-bit systems

[jdekonin]

I don't see this as a simple enable a flag fix. Rather create (or maybe repurpose existing) flag(s) that will provide make instructions as to what set of binaries need to be generated.

Currently configure detects the 64bit platform and architecture and then configuration translates that to the J9 cmprssptrs version. See closed/autoconf/custom-hook.m4.

Turning on 32bit versions shouldn't be difficult, but that should be done under a different issue and only once we have some sort of story around how to specify cmprssptrs or non-cmprssptrs.

[groeges]

There are several issue that are related to this issue:

eclipse-openj9/openj9#479
eclipse-openj9/openj9#643

These are being discussed and worked on.
Main thought in issue #643 is to make this a runtime choice and not a compile time choice.

[DanHeidinga]

Main thought in issue #643 is to make this a runtime choice and not a compile time choice.

Making this a runtime choice is at least 6 months of work, and will likely negatively effect startup performance. I think we need to continue to pursue the combining a compressed & non-compressed into a single package.