On 25 September 2017 at 12:47, Steve Ebersole <st...@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 <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
