Re: [hibernate-dev] [HV] Memory footprint improvements

On Sat, Jul 22, 2017 at 2:44 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; 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