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

Andrej Golovnin andrej.golovnin at gmail.com
Mon Jun 2 09:19:52 UTC 2014

Hi David,

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.

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

More information about the core-libs-dev mailing list