Hi David,
Sorry, crossed some email threads, in hotspot the compiler has no
involvement.
Changes to remove explicit wrapper types are being proposed in the
libraries
where the compiler can handle the boxing.
Roger
On 6/2/2014 10:19 PM, David Holmes wrote:
Hi Roger,
On 3/06/2014 12:15 AM, roger riggs wrote:
Hi David, et.al.
I would let the compiler do auto-boxing where necessary. (Assuming
object identity is not necessary).
I don't see where the compiler comes into this one. ???
David
-----
If type disambiguation is necessary then use a cast to the target
type and
let the compiler do the rest. It keeps the source code simple and
readable.
But I don't think it is worth a proactive pervasive change.
The gain is overshadowed by the overhead of the reviews.
$.02, Roger
On 6/1/2014 11:07 PM, David Holmes wrote:
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
