[hibernate-dev] [HV] Memory footprint improvements
guillaume.smet at gmail.com
Thu Jul 20 08:23:17 EDT 2017
On Wed, Jul 19, 2017 at 3:19 PM, Guillaume Smet <guillaume.smet at gmail.com>
> ## 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
> Usually, in HV, we take the 1/ route so I was a bit surprised 2/ was
> chosen here.
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.
More information about the hibernate-dev