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

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev