2017-09-25 13:47 GMT+02:00 Steve Ebersole <st...@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? > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
