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

[Sanne Grinovero]

On 25 September 2017 at 13:09, Gunnar Morling <gunnar at hibernate.org> wrote:
> 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?

It's just that the generated code looks at the actual definitions, not
only the declared ones.
Since it's a different interface you'll get a new copy of each logger
definition; this might sound irrelevant but in this specific case gets
quite large in terms of metadata, so it's worth keeping in mind when
designing these inheritances.

I'm not saying such inheritance needs to be avoided at all costs; just
raising awareness of this effect. In the Hibernate Search case seems
reasonable to clean it up - in other cases I guess but I'm not sure if
it's worth it to take concrete action but I like us to be aware of the
tradeoffs.

Thanks,
Sanne

>
>>
>> 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
>
>