RFR: 5043030 (reflect) unnecessary object creation in reflection

[Andrej Golovnin]

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