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

David Holmes david.holmes at oracle.com
Thu Jan 9 23:59:34 PST 2014


Hi Gilles,

On 9/01/2014 10:58 PM, Gilles Duboscq wrote:
> Hello,
>
> As i wrote in a bug report [1]:
> Currently, calling AllocObject or Unsafe.allocateInstance with a
> primitive type (e.g. unsafe.allocateInstance(int.class)) leads to a
> segmentation fault because Classes representing primitive types do not
> have an associated Klass.
>
> While AllocObject or allocateInstance should in principle never be
> called with a Class representing a primitive, it should probably not
> crash in such a case since it throws sensible exceptions for many other
> invalid arguments (interfaces, abstract types, arrays, j.l.Class).

As per the bug report both Unsafe and JNI require the caller to pass the 
correct parameters to a method and if they do not then crashes are 
entirely possible. The intent is to avoid penalizing correct code with 
unnecessary checks.

The existing checks (check_valid_for_instantiation) arise simply from 
the fact that the underlying allocation routine is used by other parts 
of the VM that do require more extensive checks.

> The proposed fix [2] just throws an InstantiationException if the Klass
> is NULL.

While this may seem quite innocuous I am concerned about setting a 
precedent for "fixing" unsafe/JNI when used incorrectly.

David

> -Gilles
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8031427
> [2] http://lafo.ssw.uni-linz.ac.at/alloc_object.diff


More information about the hotspot-runtime-dev mailing list