[hibernate-dev] [HV] Memory footprint improvements

[Sanne Grinovero]

On 23 July 2017 at 21:23, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> 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.

Just nitpicking, as I guess skipping a single class isn't going to
revolutionize the world, but can't you take advantage of the basic
assumption that all objects extend `java.lang.Object` ?

In short, that paragraph doesn't seem to apply.

Thanks,
Sanne

>
> --
> Guillaume