Re: [hibernate-dev] Bytecode enhancement
On Thu 2012-10-04 10:00, Steve Ebersole wrote:
See https://hibernate.onjira.com/browse/HHH-7667
I want to investigate expanding Hibernate's support for bytecode
enhancement. I can see 3 main fronts to this:
1) offloading map lookups from the PersistenceContext . Currently we
keep state associated with each entity in a map (a special type of map
called IdentityMap) on the PersistenceContext, keyed by the entity.
Profiling consistently shows these maps as a hot-spot. The main thing
we keep in the PersistenceContext in regards to the entity is called an
EntityEntry, which is kept in an IdentityMap<Object,EntityEntry> (again,
the entity is the key). So the thought here is to invert this from
`map.get( entity )` to something like `( (Enhanced) entity
).getEntityEntry()`
I was discussing this with Sanne. One "workaround" to the heavy
IdentityMap price is to keep a contextual cache. I am pretty sure these
IndeitityMap lookups are done over and over for a given operation.
We might be able to:
- pass along the EntityEntry instead of relying on the lookup several
times
- use a cache of lookups for either the most recent or for the
contextual operation.
The cache would be array based and thus not involve hashcode or lookup.
for ( int index = 0 ; index < cache.length ; index++ ) {
if ( searchedO == cache[index] ) {
entityEntry = entityEntryCache[index];
}
}
if ( entityEntry == null ) {
identityMap.get(searchedO);
//add to cache
}
Alternatively, I don't remember what is costly, the actual lookup or the
computation of the identity hashcode.
If that's the former, we can take the bet and use the entity hashcode
instead but still use == instead of equals. The risk is more collisions
or in case of a rogue implementation of hashCode not finding the entity.
These options seems more lightweight than relying on bytecode
enhancement to keep a placeholder.
2) More performant dirty-checking. This already exists, to an extent,
in the current Hibernate bytecode. The idea being that we could use
"interception" within the enhanced entity to know when it becomes dirty.
Well, almost. What is missing is "deep checking of mutable state
fields". For example, an entity attribute of type Date that is
"changed" via entity.getSomeDate().setTime( ... ). The entity needs to
be found dirty here, because its "someDate" attribute value has changed,
but interception will not catch this. And I think this should be
configurable (whether the user wants us to perform "deep mutable state
checking"). We have all the pieces in place to handle this already
through Type.isMutable() as Hibernate already does a great job of
finding dirty fields in the most flexible manner. We just need to
determine how to best wire that up into enhancement.
Either check the deep state via the type system or consider an element
as dirty when it is read.
3) Alternative means for lazy loading of entity state, meaning an
alternative to using proxies for the same purpose. This is different,
too, from the current enhancement capability of lazy loading of property
state. Lazy property loading is meant to delay loading of certain
field(s) until they are accessed.
You lost me on that one, I'm not sure what you mean here.
Emmanuel