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
