On 25 September 2017 at 13:31, Gunnar Morling <gunnar(a)hibernate.org> wrote:
My question would be why do you need the inheritance to begin with? You could just invoke
the methods on the logger interface defining them. It'll require you to have two (or
more) fields for the logger references, but then you'll get just a set of more related
and coherent methods offered from each such logger, which may be better than mangling
everything together into one interface.
+1 I'd surely recommend to avoid the inheritance to new codebases, I
just had various other factors currently making me not like to totally
remove the shared methods in a single step but I agree that's where we
should be headed.
In the grand scheme of things, I'm not going to disrupt error code
stability (user friendlyness of people googling these codes) for the
sake of 12 bytes so that can wait a bit, likely some of those methods
won't even exist in the next major release.
Thanks,
Sanne
2017-09-25 14:18 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> On 25 September 2017 at 13:09, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > 2017-09-25 13:47 GMT+02:00 Steve Ebersole <steve(a)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?
>
> It's just that the generated code looks at the actual definitions, not
> only the declared ones.
> Since it's a different interface you'll get a new copy of each logger
> definition; this might sound irrelevant but in this specific case gets
> quite large in terms of metadata, so it's worth keeping in mind when
> designing these inheritances.
>
> I'm not saying such inheritance needs to be avoided at all costs; just
> raising awareness of this effect. In the Hibernate Search case seems
> reasonable to clean it up - in other cases I guess but I'm not sure if
> it's worth it to take concrete action but I like us to be aware of the
> tradeoffs.
>
> Thanks,
> Sanne
>
> >
> >>
> >> 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...
> >>
> >> On Mon, Sep 25, 2017 at 6:32 AM Sanne Grinovero <sanne(a)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(a)lists.jboss.org
> >> >
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >