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

[Steve Ebersole]

Generally speaking, generating one instance of something versus generating
N is better.  It has the potential to affect performance in regards to
memory consumption in relation to the size of N


On Mon, Sep 25, 2017 at 7:12 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 25 September 2017 at 12:47, Steve Ebersole <steve at hibernate.org> wrote:
> > 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?
>
> Good point. The problem is not "to not extend anything" but to not
> extend another interface which also contains some hundreds of logging
> messages you're not actually needing.
>
> I introduced the `BaseHibernateSearchLogger` for it to contain the
> ones which I'd still want to share, at least for a little longer. In
> an ideal cleanup this interface would be empty.
>
> >
> > Out of curiosity, is this specific to WildFly/Modules and how it handles
> > Class loading?  Or is this something in the JVM itself?
>
> The JVM itself: it affects all our users.
> It's interesting for WildFly too but mainly because a lot of libraries
> composing WildFly do similar stuff.
>
> >
> > 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
>
> I like that but especially in terms of user friendlyness. What makes
> you think it would affect performance?
>
> And thanks for teaching me about @ValidIdRange, I didn't know that one :)
>
> Thanks,
> Sanne
>
>
> >
> > 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
>