<AWT Dev> JNI JavaVM* pointer - above 32 bits now with Java 9?
peter.brunet at oracle.com
Fri Jul 17 21:53:48 UTC 2015
You can ignore this query. There was an obscure change in the code from
using the JavaVM* pointer to using a dialog window handle which would be
limited to 32 bits and thus not a problem. The JavaVM* pointer appears
to be limited to calling Attach/DetachCurrentThread.
On 7/17/15 2:53 PM, Pete Brunet wrote:
> This is a JNI question. Is the JavaVM* pointer returned by GetJavaVM
> guaranteed to not have any bits in the upper 32?
> There is old code I am working with that stores the JavaVM pointer in
> longs (32 bits on 64 bit Win) and uses longs to transfer the value all
> around within the code and to/from an external native API.
> It's not been a problem in the past but since 9 b58 and the switch to
> VS 2013 java.exe has the High Entropy Virtual Addresses bit set which
> means that all memory addresses in a 64-bit app are guaranteed to be
> above 4gb ( 4294967295 aka 0xFFFFFFFF) and thus have bits in the upper
> 32, but I don't know if that also applies to the JavaVM* pointer.
> If there will be address bits in the upper 32 one possible workaround
> to save recompilation by users of the external native API might be to
> save the upper 32 bits after calling GetJavaVM and then prepend those
> bits whenever the long comes back in from the external API. The users
> of the external API never manipulate those bits; they receive the bits
> when starting to use the API.
> Is there a better list for this question?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the awt-dev