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?
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 <sa...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
