[hibernate-dev] JVM metadata costs vs the use of inheritance across Logger interfaces

[Sanne Grinovero]

Our friend and colleague Andrew Dinn from the OpenJDK team is working
on a series of blog posts to help people understand the impact of
certain design choices on the cost of internal JVM metadata and native
memory; this affects bootstrap costs of both the JVM and our
libraries, overhead at runtime in terms of permanent memory waste,
etc..

So as these blogs will be out soon I'm not going to dive into more
details or how I discovered this, but as a draft reviewer I had the
privilege to already play with the technique and send a PR to
Hibernate Search as result of verifying some theories.

In a nutshell Andrew's work allowed me to spot that having a Logger
interface in module A extended by another Logger in module B is
causing it to generate a significant amount of duplication of Class
definition metadata: the generated loggers are quite verbose in terms
of such costs and don't benefit from inheritance as one would expect:
the cost of B is (A+B), if you ignore benefits from symbol
de-duplication. In this specific example I could measure more than
200K of wasted space. That's not small for a single jar! Incidentally
in this case it also bloats the jar file size.

A code patch might be more clear to explain than emails; this is what
I recommend we do in all projects:
 - https://github.com/hibernate/hibernate-search/pull/1546

N.B. the verbosity of the generated code is related with runtime
performance so I don't think we'll to remove the generated Logger
metadata, and certainly don't plan to switch logger implementations as
there are many more aspects to take into account - yet we might have
identified an anti-pattern which is multiplying this cost N times
without a good reason and it's quite easy and under our control to
avoid that.

Thanks,
Sanne