Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Keep a constant metadata placeholder for unconstrained entities

Description

Andrej Golovnin wrote:

After updating JBoss 7 to use the Hibernate Validator 4.3.0 and
adding <property name="javax.persistence.validation.mode" value="NONE"/>
to our persistence.xml file I was able to reduce memory consumption
of SerializableValidatorFactory from ca. 90MB to ca. 256KB.
What I was not able to do, is to avoid loading of Hibernate Validator
and Hibernate Envers at all as we don't use them.

Emmanuel's reply:

If you do not use Hibernate Validator annotations, 90MB might indeed be too much Hardy, I wonder if we could optimize the memory model and JPA initialization so that we check if a class has constraints and if it does not, Hibernate Validator keeps a small placeholder to remember that but does not consume any other memory for this non validated class. We could save a lot instead of building the model and keeping it in memory.

Environment

None

Activity

Show:

Hardy FerentschikJune 19, 2012 at 3:15 PM

There is a rather lengthy discussion related to this topic against this commit as well - https://github.com/hferentschik/hibernate-validator/commit/ebe874fbf8c24add30361a60550fe0b1acb0cdc8

Important seems to me:

Really BeanMetaData is doing a little bit more than just keeping validation related data. It is also used to cache some reflection calls (aka class hierarchy and property names). I am tempted to say that to truly solve one would have to separate these two things. A first step could be to see what happens when reflection is used (what is the real performance impact). After that the caching of reflection calls could be done in a different "cache".

If we are able to separate these two things it should be quite easy to have the placeholder approach.

Hardy FerentschikJune 12, 2012 at 10:43 PM

Right. And the class data is even held in the perm gen, but I will investigate this a little more.

The problem is that the bean meta data also contains the bean descriptor for the unconstrained entity. For nothing else it contains the bean type itself. It is perfectly ok to ask for the bean descriptor for an unconstrained bean as well. If we go for the specialized implementation we need to find a solution for this as well. I am not sure its worth it. The memory footprint is really small if you take the class data out of the picture. I will add some actual numbers as well. Also the bean meta data cache uses soft references now.

Emmanuel BernardJune 12, 2012 at 5:43 PM

The bean class reference is shared by the classloader so it doe snot add up to the memory consumed by Hibernate Validator, correct?

I am actually thinking that we could have a specialized implementation of BeanMetaData that has no state. We would save up on:

  • all those unnecessary references

  • we could reuse the same instance to represent all non validated classes and save up on the BeanMetaDataManager cache

Hardy FerentschikJune 12, 2012 at 5:16 PM

I started with making sure to use Collections.emptyXYZ whereever possible and also to only keep method meta data for constrained/cascaded methods - https://github.com/hferentschik/hibernate-validator/tree/HV-589

Turns out the biggest size culprit is the bean class. Our BeanMetaData only holds a reference to it, so I don't know whether we should really care about it.

Hardy FerentschikJune 11, 2012 at 5:39 PM

Not sure about a singleton placeholder instance (if this is what you mean), but I think we can gain a lot by "nulling" all these map, list and set referencing for unconstrained classes. I am working an a prototype ...

Fixed

Details

Assignee

Reporter

Participants

Emmanuel Bernard
Gunnar Morling
Hardy Ferentschik

Components

Fix versions

Affects versions

Priority

Created May 12, 2012 at 12:30 PM
Updated January 28, 2014 at 9:51 AM
Resolved January 9, 2014 at 7:21 PM