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

[Sanne Grinovero]

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