[
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 statements.
--
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
