Replacing Unsafe.allocateInstance

[Chris Hegarty]

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