RFR: 5043030 (reflect) unnecessary object creation in reflection

[Coleen Phillimore]

Hi,
I no longer have the original change.  Can you resend?
thanks,
Coleen

On 6/2/14, 5:19 AM, Andrej Golovnin wrote:
> Hi David,
>
>
>> 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.
>>
> I'm glad to hear that.
>
>
>> 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.
>>
> In case my vote counts, I'm for consistency. :-)
>
>
>> 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?
>
> No. The most of those objects are allocated by calls to
> java.lang.reflect.Field.get(). I disable reflection-inflation only on the
> server side just to save a little bit more memory. On the client side I'm
> still using reflection-inflation, because here is the startup time more
> important.
>
>
>> 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.
>>
> I would not call what we do a "non-mainstream" use case. We have a classic
> JEE application which make use of nearly all JEE APIs. All of those Boolean
> objects are allocated by a very famous JPA implementation, which use
> Reflection API to set/get properties of our domain objects.
>
> We have the same problem with Integer objects too. I brought the example
> with Boolean objects just because at least in the theory we should have per
> JVM only two instances of Boolean class. But in the reality we have to many
> of them.
>
> Best regards,
> Andrej Golovnin