Replacing Unsafe.allocateInstance

[Henri Tremblay]

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.
newConstructorForSerialization.

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

> On Jun 27, 2015, at 2:54 AM, Henri Tremblay <henri at tremblay.pro> 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.
>