[hibernate-dev] Bytecode interception and attribute name versus attribute index

[Gunnar Morling]

> You want us to delay enhancement until after the persisters are built.

No, I mean to let enhancement define the attribute ordering and
initialize persisters with that previously defined order.

> What I suggest longer term is a slight variation...

Yes, that sounds nice.


2015-11-12 16:07 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> But see that is exactly the problem.  That cannot work.  You want us to
> delay enhancement until after the persisters are built.  But building the
> persisters requires access to the Class.  But by that time since we have the
> Class reference we can no longer enhance it.  It's a chicken-egg problem.
>
> What I suggest longer term is a slight variation, where we drive the
> "indexing" based on the mapping model.  Actually that also will not work as
> the code is today.  Really what I'd like to do is to leverage the
> jandex-binding work.  Specifically there we have a Jandex-driven pre-parsing
> of the domain model (including XML augmentation).  That model would be
> perfect for this.
>
> On Thu, Nov 12, 2015 at 9:00 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> It would be a one-time effort during persister initialisation; At that
>> time a look-up would happen in order to seed persisters with
>> attributes in the order as determined by the enhancer. Then at
>> runtime, upon getter/setter invocation, the index values passed from
>> the enhanced code would be used as is for array index access in
>> persisters.
>>
>> 2015-11-12 15:30 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > But I think that just redefines the same problem.  Just that now instead
>> > of
>> > String->Integer we need some Integer->Integer resolution.  Not sure that
>> > really gains us anything.
>> >
>> > On Thu, Nov 12, 2015 at 8:29 AM Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >>
>> >> I have no estimate as to how much this would help.  Many of the
>> >> improvements coming from the performance work have been of the sort
>> >> that is
>> >> removing Map lookups; some of them across VERY small (and finite) sets
>> >> of
>> >> Map keys.  My concern here is that the Map look up occurs any time an
>> >> enhanced entity's getter or setter is called, which seems like a
>> >> potentially
>> >> bigger performance impact.
>> >>
>> >> I'm going to table this for now until the jandex-binding work.  But as
>> >> part of that work, I think it makes a ton of sense to make sure we
>> >> develop a
>> >> strategy for consistent ordering of processing attributes.
>> >>
>> >> On Thu, Nov 12, 2015 at 2:36 AM Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >>>
>> >>> Is there any estimate what would be gained perf-wise by doing this
>> >>> optimization?
>> >>>
>> >>> > First, this obviously is more fragile than relying on names; if the
>> >>> > order
>> >>> > changes but the bytecode is not re-enhanced, that could lead to very
>> >>> > subtle, nasty problems.
>> >>>
>> >>> Agreed, but to me it seems acceptable with such optimization having to
>> >>> be explicitly enabled and the docs of that setting describing this
>> >>> matter clearly.
>> >>>
>> >>> > The other issue is that this requires us to be able to consistently
>> >>> > be
>> >>> > able
>> >>> > to order the attributes.
>> >>>
>> >>> Maybe the enhancer could enhance entities with a (static) method
>> >>> returning the attribute order it works with, or maybe some separate
>> >>> contract for making this order available. Then at runtime this order
>> >>> could be fed to persisters et al. for enhanced entities.
>> >>>
>> >>> Not sure whether it's doable or how complex it'd be, just throwing out
>> >>> the idea.
>> >>>
>> >>> --Gunnar
>> >>>
>> >>>
>> >>> 2015-11-11 21:37 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >>> > As I work on HHH-10267, a thought that keeps coming up in my head is
>> >>> > that
>> >>> > it would be great to avoid Map lookups in the enhancement and
>> >>> > interception
>> >>> > code.
>> >>> >
>> >>> > As an example of what I mean, consider the reader for a String field
>> >>> > named
>> >>> > `name` which roughly looks like:
>> >>> >
>> >>> > public String $$_hibernate_read_name() {
>> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>> >>> > "name",
>> >>> > this.name );
>> >>> > }
>> >>> >
>> >>> > In the interception code we need to resolve the attribute name
>> >>> > ("name"
>> >>> > above) to the pertinent information from the persister,etc.
>> >>> > Typically
>> >>> > this
>> >>> > is a Map lookup; sometimes it is a done by iterating a String[] of
>> >>> > the
>> >>> > attribute names.
>> >>> >
>> >>> > Ultimately the information is taken from persister and friends,
>> >>> > which
>> >>> > means
>> >>> > that the information is generally already readily consumable via
>> >>> > array
>> >>> > access once we have resolved the name to a proper index.  Which got
>> >>> > me
>> >>> > thinking it would be great if we could encode the attribute index
>> >>> > into
>> >>> > the
>> >>> > enhanced entity directly.  Going back to the example about.. if we
>> >>> > knew
>> >>> > that the "name" attribute was the 4th attribute (index=3) according
>> >>> > to
>> >>> > the
>> >>> > entity persister we could leverage that information for better
>> >>> > performing
>> >>> > access to the attribute metadata in the enhanced code and
>> >>> > interceptor:
>> >>> >
>> >>> > public String $$_hibernate_read_name() {
>> >>> >     return (String) $$_hibernate_getInterceptor().readObject( this,
>> >>> > 3,
>> >>> > this.name );
>> >>> > }
>> >>> >
>> >>> > One gotcha - always has to be one devil right ;)  Ok, 2 really...
>> >>> >
>> >>> > First, this obviously is more fragile than relying on names; if the
>> >>> > order
>> >>> > changes but the bytecode is not re-enhanced, that could lead to very
>> >>> > subtle, nasty problems.
>> >>> >
>> >>> > The other issue is that this requires us to be able to consistently
>> >>> > be
>> >>> > able
>> >>> > to order the attributes.  The Enhancer currently does not rely on
>> >>> > the
>> >>> > built
>> >>> > metadata (org.hibernate.mapping) at all; it parses the entity
>> >>> > annotations
>> >>> > (completely annotation specific) on its own.  Given the 2-phase
>> >>> > break
>> >>> > down
>> >>> > in JPA bootstrapping, having Enhancer leverage the built metadata is
>> >>> > not
>> >>> > really going to be possible.  Which is unfortunate, because doing so
>> >>> > would
>> >>> > be nice for other reasons (like supporting XML mappings for
>> >>> > enhancement
>> >>> > as
>> >>> > well, etc).
>> >>> >
>> >>> > That's a lot of information, sorry about that :)
>> >>> >
>> >>> > But anyone have thoughts on that?
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev at lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev