<AWT Dev> JNI JavaVM* pointer - above 32 bits now with Java 9?

[Pete Brunet]

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.

Pete

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?
>
> Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20150717/826d2847/attachment.html>