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

[Gunnar Morling]

2017-09-25 13:47 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> I'm missing something.  IIUC the discovery was that, e.g., having something
> like `BaseHibernateSearchLogger` in module-A and then something like
> `RealLogger` in module-B that extends `BaseHibernateSearchLogger` causes
> extra space to be taken up within the VM memory space.  Yet this is still
> exactly what you do.  What am I missing?
>

Same question here.

Also, does it only apply when inheriting from a base logger in another
module or also when inheriting from a logger in the same module? I.e. is
this issue related to cross-module boundaries or rather any kind of
inheritance of logger types?


> Out of curiosity, is this specific to WildFly/Modules and how it handles
> Class loading?  Or is this something in the JVM itself?
>
> Another thing I'd like to point out that I believe helps with performance
> in regards to loggers is what I have been doing in ORM which is to use just
> a single instance of named loggers, which you can see in the loggers in the
> `org.hibernate.internal.log` package :
> https://github.com/hibernate/hibernate-orm/tree/master/
> hibernate-core/src/main/java/org/hibernate/internal/log
>
> On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
> > 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
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>