[ImageJ-devel] imglib2-neon project for runtime bytecode transformation

[Johannes Schindelin]

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