Hi Tim,
The latest Pull Request for the Hash Aggr operator (#938) does turn the
“plain java” on for the mainline code, as these new template code changes (in
the Hash Table) caused the “byte twiddling” to break in some subtle way.
This is the first attempt; and as it (hopefully) will work well we’ll continue
with other operators.
Thanks,
Boaz
On 9/15/17, 11:34 AM, "Paul Rogers" <[email protected]> wrote:
Hi Tim,
This question has come up multiple times. The “plain Java” is very handy
for developing code with code generation. It also seems to be faster, smaller
and simpler than the byte-code-merge mechanism. (However, rewriting byte codes
is has the benefit of sounding much more sophisticated than simply invoking the
Java compiler!)
I suspect that there is a healthy concern that there may be subtle problems
with letting Java compile code without our help in twiddling with the byte
codes.
The way to address this concern is to run a full set of functional and
performance tests with the “plan Java” mechanism turned on. But, no one has had
the time to do that…
That said, feel free to turn “plain Java" on during development; we now
have sufficient experience to show that Java does, at least in development,
produce code at least as good as what we produce via our byte-code merge
mechanisms. With the added benefit that you can debug the code. (By contrast,
when using the byte-code merge approach, there is no matching source code for
the debugger to step through… I believe that folks have, instead, used print
statements to visualize the execution flow.)
Thanks,
- Paul
> On Sep 14, 2017, at 1:41 PM, Timothy Farkas <[email protected]> wrote:
>
> Hi All,
>
> As I've been looking at the TopN operator and code generation, I've been
wondering why we have 2 forms of code generation:
>
>
> * One is the method of stitching compiled methods into a template
class with ASM.
> * The other simply creates a class that extends the TemplateClass and
compiles it without using custom ASM techniques. This is the PlainJava
technique.
>
> With my high level understanding, it seems like using the PlainJava
approach would be the simplest, and would also probably be the most performant
since we inherit all the java compiler optimizations. Is there a specific
reason why we still use our custom ASM technique? Would it be safe to start
retiring the old ASM technique in favor of PlainJava?
>
> Thanks,
> Tim
