Hi Tobias, On Wed, 24 Sep 2014, Tobias Pietzsch wrote:
> As a weekend project I have started to look into bytecode modification > using the wonderful ASM library (http://asm.ow2.org). It is great that you continue our conversation from the hackathon last year in Madison: http://fiji.sc/2013-05-03_-_ImgLib2_Hackathon_in_Madison I am very glad that you have returned to this work, with a promising initial foray into a general solution. I do have some questions and suggestions: - Why use ASM over Javassist? At the hackathon, we used Javassist because it is easier to use, we have much better documentation (e.g. http://fiji.sc/Javassist) and we already ship it with Fiji. - If the plan is to use it inside Fiji, why not use version 4.0 of ASM which is in Fiji already as a transitive dependency of JRuby? Requiring a newer version (5.0.2) is prone to cause problems... - The most challenging requirement of any potential performance improvement is the separation of concerns: to truly be able to optimize ImgLib2 routines, the optimization has to be decoupled from the implementation because ImgLib2 is data type, storage and dimension independent and developers need to be able to provide more sophisticated optimizations for specific scenarios than automatic byte code manipulation can provide - As usual, we'll want to carefully consider the issue of dependencies relating to imglib2 core. Augmenting ImageJ OPS with this feature would avoid complicating the imglib2 core with any dependencies. - I seem to recall that I demonstrated a much higher performance win at the hackathon April/May 2013, what is the reason that the new approach does not reach those numbers? > I have cleaned up what I have played with and put it on github > https://github.com/tpietzsch/neon. - A quick web search shows that there is an active, successful Neon library for WebDAV communication. To avoid legal and social problems, we'll need to choose a different name for the project. > I think it is orthogonal to what you do with compile-time code > generation currently and therefore might complement it nicely. - I agree that the bytecode manipulation and code generation strategies can complement each other nicely. I am looking forward to the upcoming ImgLib2 hackathon so that we can show you how OPS tackles the performance issue in a way that facilitates extensibility and keeps concerns well separated! If you have a chance to explore OPS in depth before the hackathon, it would be very helpful to expedite later discussion. - I encourage you to study ImageJ OPS before continuing this project because it provides the necessary infrastructure already, matured over a course of several iterations. - For demonstration purposes, using a Java Agent at startup is great; We will definitely want to explore practical ways of applying the bytecode manipulation. It should be achievable -- we do it already in the ImageJ Legacy project to rewrite portions of ImageJ1 as needed. Ciao, Johannes _______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
