RFR: 8255128: linux x86 build failure with libJNIPoint.c

[Jorn Vernee]

On Tue, 3 Nov 2020 17:40:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c
>> 
>> This removes the reported warning.
>> 
>> Note that the _LP64 macro was not being propagated to the benchmark native libraries on Windows. The comment says that this is due to pack200, but since this has been removed [1], it seemed safe to propagate the macro now (backed up by testing).
>> 
>> CC'ing hotspot-runtime since I know some people there were looking forward to having this fixed.
>> 
>> Testing: tier1-3
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8232022
>
> test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/libJNIPoint.c line 32:
> 
>> 30: #define PTR_TO_JLONG(value) ((jlong) (value))
>> 31: #else
>> 32: #define JLONG_TO_PTR(value, type) ((type*) (jint) (value))
> 
> Maybe the jlong thisPoint argument comes from a pointer so it's ok.  Not nice, but if you say so, I'll go along.

Yes, it's the same pointer that is returned from allocate. It's just stored in a `jlong` on the Java side (this would be a requirement on x64), but it's not expected that the high-order bits are used.

Do you have a suggestion for handling this otherwise?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1017