[hibernate-dev] [HV] Memory footprint improvements

[Guillaume Smet]

On Wed, Jul 19, 2017 at 3:19 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> ## AnnotationMetaDataProvider#configuredBeans
>
> So, in AnnotationMetaDataProvider, we keep a cache of the annotation
> metadata found while building the aggregated BeanMetaData.
>
> It might be useful if you have a class hierarchy for instance as you would
> only build the annotation of the parent class once.
>
> But... as we initialize the bean metadata lazily, we need to keep this
> cache during the whole lifecycle of the application.
>
> 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
>
> Usually, in HV, we take the 1/ route so I was a bit surprised 2/ was
> chosen here.
>
> Thoughts?
>

One additional point here is that the data structure cached here are really
not designed to be kept in memory (as opposed to the aggregated ones).

Typically, ConstrainedExecutable has a reference to a
java.lang.reflect.Method and it's quite heavy (~ 1 kB).

Concrete example with (again) the RealmEntity of Keycloak:

- ConstrainedExecutable of setSmtpConfig(Map): ~ 1.5 kB
- Total size of the BeanConfiguration: ~ 173 kB
(this with the new additional cascading metadata for container elements
which are quite heavy in this building phase)

So my vote would go for 1/ and I would accept the additional startup cost.

-- 
Guillaume