[hibernate-dev] [HV] Memory footprint improvements

[Guillaume Smet]

On Sat, Jul 22, 2017 at 2:44 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I'm not familiar enough with the whole picture but I strongly suspect you
> should explore ways to get out of this lazy initialization strategy.
>

We have a Jandex POC but it's far from being ready for prime time.

Not something we will be able to tackle soon.


> Maybe keep building it lazily during bootstrap(s) but then add a "drop
> cached metadata" hook which containers could invoke explicitly at the end
> of bootstrap of an app?
> Worst case you'll have to rebuild the metadata on demand.
>

Currently, at the end of the bootstrap of an app, you might have not
validated a bean at all, so you don't have any metadata. But I suppose you
were suggesting that we would have tackled the "load metadata lazily"
subject before that. If so, of course, we wouldn't have to keep this
metadata anymore.


> So, here, we have to find a compromise:
>
> 1/ either favor the memory footprint but the annotation of a given class
> could be analyzed several times in the case of a class hierarchy
> 2/ or favor the startup cost (it's not a runtime cost, it's paid only once
> when validating the first bean of a given class) and have a higher memory
> footprint
>
>
> I guess my proposal above is 3/, trying to have both benefits.
>

Yeah, not something we can fix soon.


> Usually, Yoann and I are on the "Let's do it" side and the others on the
> "I'm not sure it's worth it" when it comes to CollectionHelper, but
> considering how well the first round has paid, I think we should at least
> give it a try.
>
>
> I'm also quite sure it's worth applying such optimisations.
> I'm only skeptical about the value of sharing such code via shared
> libraries.
>
> I'd even go a step further : try avoiding wrapping into immutable when
> those collections are exposed exclusively to code we directly control. The
> JIT can do much magic but it won't avoid allocating the wrappers so that's
> not cheap at all, but that's of course a maintenance / clean code /
> performance tradeoff.
> Would be great to validate automatically that we treat them as effectively
> immutable, maybe that's possible via annotations and some code validation
> tools?
>

Yeah, I think the wrapping is here to stay for now.


>
> I once thought about completely removing the method metadata if the method
> wasn't annotated at all but then I thought that the overriding rules would
> prevent us to do that.
>
> Gunnar, am I right on this?
>
> So basically, I think we can't really do anything about this.
>
>
> Drop it as soon as we figure it's not useful?
>

Unfortunately, as we load the metadata lazily, they can be useful at any
time. That's the issue.


>
> I also thought that it was useless to look for annotations on
> java.lang.Object but then again I think the overriding rules force us to do
> so.
>
>
> I'm not following here. Why is it not safe to skip annotations on Object?
>

There are some overriding rules you have to follow in BV.

For instance:


*If a sub type overrides/implements a method originally defined in several
parallel types of the hierarchy (e.g. two interfaces not extending each
other, or a class and an interface not implemented by said class), no
parameter constraints may be declared for that method at all nor parameters
be marked for cascaded validation.*
So, you can't simply withdraw the metadata because there are no HV
information on the methods. Just the fact that a method is here has
consequences.

-- 
Guillaume