[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-runtime-dev
Subject: Re: RFR: 5043030 (reflect) unnecessary object creation in reflection
From: Andrej Golovnin <andrej.golovnin () gmail ! com>
Date: 2014-05-29 12:24:09
Message-ID: B7E4385F-DAFA-452C-9A07-0415120978CB () gmail ! com
[Download RAW message or body]
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);.
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=
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic