8:25 p.m.
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
8:47 p.m.
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...
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
9:09 p.m.
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?
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 <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
9:11 p.m.
On 25 September 2017 at 12:47, Steve Ebersole <steve(a)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...
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 <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
9:18 p.m.
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
9:31 p.m.
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.
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/main/java/org/hibernate/internal/log
>>
>> 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
>
>
10:37 p.m.
Generally speaking, generating one instance of something versus generating
N is better. It has the potential to affect performance in regards to
memory consumption in relation to the size of N
On Mon, Sep 25, 2017 at 7:12 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 25 September 2017 at 12:47, Steve Ebersole
<steve(a)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...
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 <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
11:21 p.m.
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
> >
> >
2416
days inactive
2416
days old
7 comments
3 participants
participants (3)
-
Gunnar Morling -
Sanne Grinovero -
Steve Ebersole