4:18 p.m.
This is my first message posted here after I finally succeeded in
subscribing to Hibernate dev mail list.
As well known, we utilized the following 'lazy initialization' pattern
extensively in our codebase to save memory:
if ( activeFactoryNames == null ) {
activeFactoryNames = new ArrayList<>();
}
However, even since JDK7, ArrayList has gone through refactoring to
keep from allocating
memory for 10 elements in advance, if the instance was created by
default constructor and the allocation of memory
is only done when some element is really added in future. Namely,
ArrayList has the lazy initialization feature built-in.
E.g., see
https://stackoverflow.com/questions/33688753/jdk-api-documentation-is-inc...
for details. You can also browse the source code of ArrayList to confirm.
[image: Screen Shot 2020-08-18 at 4.06.58 PM.png]
Needless to say, the lazy initialization pattern has serious NPE issue
if it is not coded carefully (which is tedious and error-prone per
se).
As an active Hibernate v6 contributor, I am troubled by such NPE issue
again and again.
Is it a good timing to get rid of the above lazy initialization pattern for now?
Hopefully my message is good food for thought. No finger pointing. Just curious.
2:09 a.m.
Hey Nathan,
I like the idea in general and but you have to be careful with changing
this as I assume this was done to save memory by creating the list, only
when at least one element would be added to the list. I guess if we
always initialize the list, we'd have to do something like the following
in the end `this.activeFactoryNames = activeFactoryNames.isEmpty() ?
Collections.emptyList() : activeFactoryNames` which is probably not that
bad, assuming we probably already do something similar.
I don't think anyone would object to such an improvement regarding NPE
safety as long as the final memory consumption stays the same. It would
be a pity though if we unnecessarily created lots of empty ArrayLists.
Am 18.08.2020 um 22:18 schrieb Nathan Xu:
This is my first message posted here after I finally succeeded in
subscribing to Hibernate dev mail list.
As well known, we utilized the following 'lazy initialization' pattern
extensively in our codebase to save memory:
if ( activeFactoryNames == null ) {
activeFactoryNames = new ArrayList<>();
}
However, even since JDK7, ArrayList has gone through refactoring to
keep from allocating
memory for 10 elements in advance, if the instance was created by
default constructor and the allocation of memory
is only done when some element is really added in future. Namely,
ArrayList has the lazy initialization feature built-in.
E.g., see
https://stackoverflow.com/questions/33688753/jdk-api-documentation-is-inc...
for details. You can also browse the source code of ArrayList to confirm.
Screen Shot 2020-08-18 at 4.06.58 PM.png
Needless to say, the lazy initialization pattern has serious NPE issue
if it is not coded carefully (which is tedious and error-prone per se).
As an active Hibernate v6 contributor, I am troubled by such NPE issue
again and again.
Is it a good timing to get rid of the above lazy initialization
pattern for now?
Hopefully my message is good food for thought. No finger pointing.
Just curious.
_______________________________________________
hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
4:22 a.m.
Welcome to the list Nathan!
I would be cautious in removing such lazy initialization patterns: even
when the array is not immediately allocated, we still often have reasons to
not want to allocate the wrapping object.
While of course each such choice relates to a specific context, so this
should not be taken as a golden rule nor enforced globally, there are
several examples of large classes in Hibernate ORM which *might* need a
significant amount of collections to be initialized, but only to deal with
very specific corner cases, sometimes only in combination with obscure
configurations.
Combining such considerations about instances which are very rarely used
with further considerations such as how wide-spread this library is used in
the world, and how "hot" some of these code paths are, then I feel we are
responsible to make these as efficient as possible. A NPE is certainly
something we need to avoid but it's a concern which we can address with
just a little bit of care.
I'll also remind that most of such patterns have been introduced only after
a problem was noted during profiling; in case of new code I'm occasionally
guilty of writing code in such style on first shot, but I generally do so
only when I think it's worth it - as I would agree that code readability
and ease of maintenance has a value as well.
Finally, remember one nice hint I got from the OpenJDK engineers: a
null-check is most often free in terms of code efficiency.
Thanks
On Tue, 18 Aug 2020 at 21:18, Nathan Xu <nathan.qingyang.xu(a)gmail.com>
wrote:
This is my first message posted here after I finally succeeded in
subscribing to Hibernate dev mail list.
As well known, we utilized the following 'lazy initialization' pattern
extensively in our codebase to save memory:
if ( activeFactoryNames == null ) {
activeFactoryNames = new ArrayList<>();
}
However, even since JDK7, ArrayList has gone through refactoring to keep from allocating
memory for 10 elements in advance, if the instance was created by default constructor and
the allocation of memory
is only done when some element is really added in future. Namely, ArrayList has the lazy
initialization feature built-in.
E.g., see
https://stackoverflow.com/questions/33688753/jdk-api-documentation-is-inc...
for details. You can also browse the source code of ArrayList to confirm.
[image: Screen Shot 2020-08-18 at 4.06.58 PM.png]
Needless to say, the lazy initialization pattern has serious NPE issue if it is not coded
carefully (which is tedious and error-prone per se).
As an active Hibernate v6 contributor, I am troubled by such NPE issue again and again.
Is it a good timing to get rid of the above lazy initialization pattern for now?
Hopefully my message is good food for thought. No finger pointing. Just curious.
_______________________________________________
hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
8:48 a.m.
Thanks for the null-check tip! I appreciate that.
As a matter of fact, NPE issue still bothers us a lot. This recent PR from the community
is another validation: https://github.com/hibernate/hibernate-orm/pull/3499How to
systematically combat NPE is a good topic and still highly relevant. Maybe we can talk
about it later.
I didn't anticipate we should abandon the 'lazy initialization' pattern
totally (even when we limited its scope to ArrayList constructed by default constructor).
My point is to raise the awareness that since JDK7, ArrayList has a lazy-initialization
feature built-in already. We still pay the cost to create an empty ArrayList (without
allocating 10 elements in advance), but the overhead might be worthwhile for it leads to a
more elegant and maintainable codebase.
9:03 a.m.
On Wed, 19 Aug 2020 at 13:48, Nathan Xu <nathan.qingyang.xu(a)gmail.com> wrote:
Thanks for the null-check tip! I appreciate that.
As a matter of fact, NPE issue still bothers us a lot. This recent PR from the community
is another validation: https://github.com/hibernate/hibernate-orm/pull/3499How to
systematically combat NPE is a good topic and still highly relevant. Maybe we can talk
about it later.
I didn't anticipate we should abandon the 'lazy initialization' pattern
totally (even when we limited its scope to ArrayList constructed by default constructor).
My point is to raise the awareness that since JDK7, ArrayList has a lazy-initialization
feature built-in already. We still pay the cost to create an empty ArrayList (without
allocating 10 elements in advance), but the overhead might be worthwhile for it leads to a
more elegant and maintainable codebase.
Noted, thanks. But I still recommend to keep this pattern as the
overhead has been proven to be very significant in some cases. We'll
just need to be careful with any change, but that's always the case :)
1345
days inactive
1346
days old
4 comments
3 participants
participants (3)
-
Christian Beikov -
Nathan Xu -
Sanne Grinovero