RFR(XS): 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types

[John Rose]

On Jan 21, 2014, at 12:57 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:

> I agree,  for this case, it is consistent and add safety without additional cost.  Also, the crash is an artifact of how we handle primitive types so probably would take time to debug and discover why this crashed.   In general, JNI and Unsafe do not check their arguments and there will need to be sufficient motivation to add checking.   I will sponsor this change for you.

Thank you Coleen.  I added a summarizing comment about the design of Unsafe to https://bugs.openjdk.java.net/browse/JDK-8031427

— John

P.S.  Here it is:

David is right, and we all agree, that we do not want to encourage the idea that Unsafe (per se) can somehow be made "safer".

Here are some thoughts about Unsafe that will help us make decisions like this...

The key goal of Unsafe is to be able to force the generation of simple low-level instruction sequences in the highest optimization modes of the compiler.

Adding more required checks to those highest optimization modes would defeat this purpose, unless they are somehow of zero cost.

But, it is friendly to the user if we add cheap but informative error checks to Unsafe. There are already cases where the JNI methods called by the interpreter (in unsafe.cpp) make "courtesy checks" that the compiled intrinsics (in library_call.cpp) do not make. (Look for IAE and NPE in unsafe.cpp.)

In the present case, the underlying null check is very cheap even in optimized code, and is already present in the C2 intrinsic. So that particular "courtesy check" can be extended through all optimization levels.

In general, when should we offer such a "courtesy check"? Under some combination of the following conditions: It is cheap (at the optimization levels it is applied), it improves test diagnostics (by throwing instead of crashing), it aligns the behavior of Unsafe with some other thing like JNI, it reduces user surprise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140122/8cf2c743/attachment.html