RFR: 5043030 (reflect) unnecessary object creation in reflection

David Holmes david.holmes at oracle.com
Mon Jun 2 03:07:23 UTC 2014


Hi Andrej,

Sorry for the delay getting back to you.

On 29/05/2014 10:24 PM, Andrej Golovnin wrote:
> Hi David,
>
>>>
>>> The valueOf calls may also allocate a new object so you can't just
>>> delete the JvmtiExport::post_vm_object_alloc call. Unfortunately you
>>> can't tell whether a new object was allocated or not. It is only for the
>>> smaller primitive types that any kind of Object caching is mandated.
>>
>> It is only for the smaller values (-128 to +127) of the integer primitives types (plus boolean) that caching is mandated. Float.valueOf and Double.valueOf always create objects.
>>
>
> You are right, that #valueOf call may allocate an object.
> But as far as I understand currently the JvmtiExport::post_vm_object_alloc call
> is only needed, because today the native code itself allocates an object
> by calling java_lang_boxing_object::create(type, value, CHECK_NULL);.

Right, sorry - I was misunderstanding the purpose of the 
post_vm_object_alloc call:

http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#VMObjectAlloc

So from the perspective that you are diverting this back to Java code 
the hotspot changes look okay to me.

The more general question, for the core-libs folk, is whether changing 
everything to use valueOf is overkill (given the limits of the required 
caching mechanisms) or good to do from a consistency perspective. I'm 
slightly on the overkill side of things but not enough to reject things.

On the performance/benefit side, if I read things correctly you only see 
the 9GB of Boolean objects because you disable reflection-inflation - is 
that right? In that case, as Joel states, the gains are not really 
general, but on the other hand I don't see anything wrong with trying to 
improve the general efficiency here even if the greatest benefit comes 
from a "non-mainstream" usecase.

David
-----

> My code changes this behavior and delegates object allocation back to Java
> by calling
>
>    JavaCalls::call_static(&boxed_value,
>                           klass_handle,
>                           vmSymbols::valueOf_name(),
>                           valueOf_signature,
>                           &args,
>                           THREAD);
>
> But maybe I misunderstood the implementation of JavaCalls.
>
> Best regards,
> Andrej Golovnin
>



More information about the core-libs-dev mailing list