Bug#730280: visualvm: Stacks.c compresses 64-bit pointers to 2+30bits, assumption looks unportable

[Steve Cotton]

Source: visualvm
Version: 1.3.3-2
Severity: normal

Splitting a lesser issue from Lucas' FTBFS #713198

On Sat, Jun 22, 2013 at 14:05 +0200, Lucas Nussbaum wrote:
> /usr/lib/jvm/java-6-openjdk-amd64 jdk15
> ../src-jdk15/Stacks.c: In function 'convert_jmethodID_to_jint':
> ../src-jdk15/Stacks.c:108:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
>          return (jint)jmethod;
>                 ^
> ../src-jdk15/Stacks.c: In function 'convert_jint_to_jmethodID':
> ../src-jdk15/Stacks.c:122:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>          return (jmethodID)method;

The warnings in Stacks.c refer to lines in a conditional
compilation based on whether sizeof(jmethodID)==sizeof(jint).
The warning is on the version that isn't used.  Someone's used a
normal runtime conditional instead of a preprocessor conditional.

However, I'm not sure that the version used is better.  IIUC, it
compresses 64-bit address to 32-bits, using an assumption that
addresses will fit within 4 pools, and each pool will fit within
30 bits.

All the pointers that these handle are to the same type of small
structure, so on amd64 they'll probably always fit in 32-bits
anyway, and it'll probably always work.  But on an architecture
where it breaks, I'm wondering if the "4 pools" assumption will
make it work on all test-cases, and then fail on large projects.

Steve