RFR: 5043030 (reflect) unnecessary object creation in reflection (original) (raw)

roger riggs roger.riggs at oracle.com
Tue Jun 3 13:13:24 UTC 2014

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::postvmobjectalloc 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::postvmobjectalloc call is only needed, because today the native code itself allocates an object by calling javalangboxingobject::create(type, value, CHECKNULL);. Right, sorry - I was misunderstanding the purpose of the postvmobjectalloc 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::callstatic(&boxedvalue, klasshandle, vmSymbols::valueOfname(), valueOfsignature, &args, THREAD); But maybe I misunderstood the implementation of JavaCalls. Best regards, Andrej Golovnin

More information about the core-libs-dev mailing list