db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5947) Factor out common code from generated classes
Date Fri, 12 Oct 2012 15:43:03 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475086#comment-13475086

Knut Anders Hatlen commented on DERBY-5947:

I think it's true that reflection is a lot cheaper now than it was in the early days of Cloudscape.
And in Java 7 there are method handles[1], which are supposed to be even faster (as they are
strongly typed). There are also library methods [2] that let you chain method handles together
and produce new ones that represent compound expressions like if/else, try/catch, manipulation
of arguments and return values, etc. So Bryan's ideal future may not be that far away. :)

My biggest problem with the byte code generation is that loading the generated class significantly
slows down the SQL compiler. I recently ran an experiment where I replaced the use of org.apache.derby.impl.services.reflect.ReflectLoaderJava2
with the OpenJDK-internal class sun.invoke.anon.AnonymousClassLoader (described in [3] and
[4]), which would load the generated classes without registering it in the JVM's dictionary.
This change made compilation of a VALUES 1 statement go more than three times faster, and
compilation of a natural join between two system tables went almost twice as fast. It also
helped the regression tests, as they do a lot of compilation. So if we could find a portable
way to get rid of the code generation/class loading without hurting the runtime performance,
I'd be all for it.

I don't think trimming down the size of the generated classes will help the compilation performance
much, as we still need to load as many classes as before, but hopefully reducing the amount
of generated code now will make it easier to eliminate it completely when we're ready to make
that move.

[1] http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandle.html
[2] http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MethodHandles.html
[3] https://blogs.oracle.com/jrose/entry/anonymous_classes_in_the_vm
[4] http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html
> Factor out common code from generated classes
> ---------------------------------------------
>                 Key: DERBY-5947
>                 URL: https://issues.apache.org/jira/browse/DERBY-5947
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
> There's some code that's added to all classes generated by Derby's query compiler. For
example, there are three static fields that contain statistics used to check if the plan is
stale, and there are getter and setter methods for each of the three fields. The fields and
their accessor methods take up 468 bytes in every generated class.
> We should see if we can factor out some of this code so that there is a single shared
copy in BaseActivation. Advantages would be: less complicated byte-code generation, less memory
occupied by generated classes in the statement cache, smaller disk footprint for stored prepared

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message