Replacing Unsafe.allocateInstance

Henri Tremblay henri at
Tue Jun 30 14:10:39 UTC 2015

I indeed noticed that having a constant class seems indeed to constant fold.

So far, I was also suspecting that having a Constructor was allowing to
cache part of the work.

Then, if we want to keep things simple, we can just get rid of
Unsafe.allocateInstance and keep ReflectionFactory.

On 30 June 2015 at 08:08, Paul Sandoz <paul.sandoz at> wrote:

> On Jun 27, 2015, at 2:54 AM, Henri Tremblay <henri at> wrote:
> > My latest benchmarks were showing it much slower than
> > ReflectionFactory.newConstructorForSerialization. I must confess I
> haven't
> > had the time to investigate correctly to see where the difference is
> coming
> > from. And haven't try with JDK9 yet.
> >
> I observe similar performance results on JDK9.
> Place the type in a static final field and you should see similar
> performance to ordinary object construction. So in part it might be because
> HotSpot cannot constant fold certain operations associated with the type.
> You will also notice a difference if say java.util.ArrayList is used
> instead of java.lang.Object. The former is slightly faster. I dunno why.
> I suspect ReflectionFactory.newConstructorForSerialization is faster than
> Unsafe.allocateInstance because the former spins up a class that
> specifically constructs the type. Although it appears the wrapping
> Constructor around an instance of that spun up class may be susceptible to
> profile pollution.
> Paul.

More information about the jdk9-dev mailing list