[
https://issues.apache.org/jira/browse/TAJO-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14107997#comment-14107997
]
ASF GitHub Bot commented on TAJO-906:
-------------------------------------
Github user hyunsik commented on the pull request:
https://github.com/apache/tajo/pull/113#issuecomment-53152719
Thanks for the review. I've updated the follows according to ASF license
policy.
* ASM is BSD license. So, according to [Modifications to
NOTICE](http://www.apache.org/dev/licensing-howto.html#mod-notice), I didn't
modify NOTICE file.
* Instead, I've added ASM license to only LICENSE file.
* Removed ASF standard license header from ASM source codes.
* Please refer to [Treatment of Third-Party
Works](http://www.apache.org/legal/src-headers.html)
> Runtime code generation for evaluating expression trees
> -------------------------------------------------------
>
> Key: TAJO-906
> URL: https://issues.apache.org/jira/browse/TAJO-906
> Project: Tajo
> Issue Type: Improvement
> Components: physical operator
> Reporter: Hyunsik Choi
> Assignee: Hyunsik Choi
> Fix For: 0.9.0
>
>
> We have used EvalNode for two purposes:
> * logical planning of expressions
> * evaluation of expressions
> EvalNode still is very nice for the purpose of logical planning. But, each
> EvalNode tree takes Datum included in a tuple and results in a Datum as a
> evaluation result.
> So, the current approach requires many object creations, and causes interpret
> overheads, meaning that each one evaluation involves tree traverses and many
> function calls. interpretation involves also many branches, and it is harmful
> to CPU pipelining.
> I propose Java byte code generation for each expression, and I'll use ASM
> (http://asm.ow2.org/) for it. This approach will write native java byte code,
> eliminating many condition branches and function calls. In addition, it is
> easier to deal with java primitive data types for expressions.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
