Replacing Unsafe.allocateInstance

[Henri Tremblay]

I'm really happy to read your answers :-)

I'm looking forward for your feedback on the benchmark. I'll revisit it
myself when I have time.

I'm in fact hoping that my benchmark is plainly wrong. That would simplify
things :-)

On 29 June 2015 at 14:17, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> Henri,
>
> As part of the investigation into replacements for current Unsafe usages,
> allocateInstance is on our list. We’re just not at the point of having
> anything to share yet. But it is, like anything else, being considered.
>
> On 29 Jun 2015, at 17:02, Henri Tremblay <henri at tremblay.pro> wrote:
>
> > I do understand this is not the classical way to do an object. So it
> might
> > need to be protected even though the current way to do it are not that
> much.
> >
> > It needs to be in the official API, like other Unsafe methods because it
> is
> > useful and needed. It is currently used by the serialization API. So
> other
> > frameworks that want to emulate the serialization should also be allowed
> > to. Right now they are hacking (for instance XStream) like Objenesis is
> > doing. JMock, Mockito and EasyMock are also hacking (using Objenesis or
> > something alike).
>
> I have taken a look at some of these libraries, and it is disappointing
> that they have had to resort to such “hacks”. But as you say, that is the
> reality that they have been facing for the past 10+ years.   I’m hopeful
> that we’ve moved on and can accept that this type of object creation
> happens in the real world, and work towards a supported “safer” way in the
> future.
>
> > It's been more than 10 years. So, being pragmatic, not having to hack
> > around would be a great relief.
>
> > *Note:* We do not need to advertise it too much ;-) I'm don't plan to add
> > Object.allocateInstance. Maybe moving com.sun.deploy.util.ReflectionUtil
> to
> > java.lang.reflect.
>
> Core reflection seems like the best fit, with the appropriate security
> restrictions.
>
> > I'm interested about performance because I do know some are using
> Objenesis
> > to instantiate objects quickly. I had some requests about that in the
> past.
> > However, I'm not sure that is still useful since my latest benchmarks are
> > showing that "new" is as fast. But indeed, 20ns is pretty fast.
>
> Ah, I was not aware that performance was super critical here. ( I have not
> looked into your benchmark results yet ).
>
> newConstructorForSerialization() will do a ‘new’ followed by an
> invokespecial on the no-args (super)class constructor, or j.l.Object in
> some of your cases.
>
> -Chris.
>
> > On 27 June 2015 at 10:52, Andrew Haley <aph at redhat.com> wrote:
> >
> >> On 27/06/15 01:54, Henri Tremblay wrote:
> >>> The problems to solve seem to be:
> >>>
> >>>   1. Find a place to put the new method in the official java.* API
> >>>   2. Make it fast
> >>
> >> But Java is designed to stop people from creating objects without a
> >> constructor.  There are several places where this is required in order
> >> to guarantee security.  So I can't see much hope of it ever being part
> >> of the official API.
> >>
> >> As to why Unsafe.allocateInstance() is slow, I have to admit that's a
> >> mystery to me.  allocateInstance() should inline quite nicely.  I
> >> suppose it might be a little bit slower if HotSpot can't determine
> >> during compilation the class you're trying to create.  But I'm looking
> >> at UnsafeFactoryInstantiator.java and it should be fine.
> >>
> >> The only thing to do is to do some measurements and look at the
> >> generated code.  Mind you, 20ns is still pretty fast.
> >>
> >> Andrew.
> >>
>
>