[
https://issues.apache.org/jira/browse/DRILL-5116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15806955#comment-15806955
]
ASF GitHub Bot commented on DRILL-5116:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/716#discussion_r95053721
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/compile/ClassBuilder.java ---
@@ -141,7 +142,9 @@ public ClassBuilder(DrillConfig config, OptionManager
optionManager) {
// A key advantage of this method is that the code can be
// saved and debugged, if needed.
- saveCode(code, name);
+ if (cg.persistCode()) {
--- End diff --
It is the method to ask that the generated code be saved... Perhaps the
confusing bit is that there are two methods of the same name:
`persistCode(boolean)` which is called to ask to persist the code, and
`persistCode()` which is used to check if the code should be persisted.
(Somehow, `isPersistCode` or `isCodePersisted` just didn't seem as clear...)
On the next PR, I'll see if I can come up with a clearer name. At that
time, I'll find a way to test the two "dead" operators so that all support
plain Java. Once that is done, I can remove the calls to `supportsPlainJava`
and comments about using `persistCode` that now appear in each operator to mark
those that are plain-Java ready.
> Enable generated code debugging in each Drill operator
> ------------------------------------------------------
>
> Key: DRILL-5116
> URL: https://issues.apache.org/jira/browse/DRILL-5116
> Project: Apache Drill
> Issue Type: Improvement
> Affects Versions: 1.9.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Minor
> Labels: ready-to-commit
>
> DRILL-5052 adds the ability to debug generated code. Some of the code
> generated by Drill's operators has minor problems when compiled directly
> using the new technique. These issues are ignore by the byte-code-merge
> technique uses in production. This ticket asks to try the DRILL-5052 feature
> in each operator, clean up any minor problems, and ensure each operator
> generates code suitable for debugging. Use the new
> {{CodeGenerator.plainOldJavaCapable()}} method to mark each generated class
> as ready for "plain-old Java" code gen.
> The advantages of this feature are two:
> 1. Ability to step through the generated code to increase understanding of
> existing operators and to ease development of improvements to existing
> operators and of any new operators we choose to create.
> 2. Open the door to experimenting with how to improve performance of the
> generated code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
