RFR: 8299684: (bf) JNI direct buffer functions with large capacity behave unexpectedly [v9]

[Alan Bateman]

On Mon, 16 Jan 2023 00:39:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Apparently it is not needed so removed in 38ea7997be2be59e2cea97c7dabf929210c0edfa.
>
> No wonder I couldn't find this change! The catch of OOME was added because I still believe that trying to allocate a buffer of capacity Integer.MAX_VALUE will throw OOME (at least some of the time). If that happens then the test should not fail.

No objection to having the test pass if malloc fails but it would be better if the native newDirectByteBuffer were changed to just call JNI NewDirectByteBuffer with a given address so that the malloc + JNI function aren't in the same native method. That allows the test to distinguish malloc returning NULl from NewDirectByteBuffer throwing OOME. The native method freeDirectByteBufferMemory can be split too so that there is native method get the direct buffer address. With these changes, the test can use Unsafe allocateMemory/freeMemory (changing to FFM APIs in the future) or have native methods that do the malloc/free. The more basic methods means the test can be improved,  e.g. checkBuffer doesn't currently test that GetDirectBufferAddress returns the address that the DBB was created to wrap.

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

PR: https://git.openjdk.org/jdk/pull/11873