java bytecode ijar/turbine research work

[niloc132]

When a dependency changes in any way, we currently recompile all downstream projects and dependencies, as we can't detect if the changes matter or not. That is, a given task specifies its inputs (the project it depends on, and the file patterns that matter), and the contents of those inputs are hashed - when the hash of the inputs is different, we assume that the task must be re-run on those inputs.

For some things like running closure-compiler with compilationLevel=ADVANCED, this is true, practically any JS change could matter, plus or minus some whitespace changes. (The likelihood of whitespace-only changes is fairly low, though the cost of compilation is high, so this might possibly be a reasonable use case to test for if we can get it for free from https://github.com/Vertispan/j2clmavenplugin/issues/119.)

For javac and j2cl, this isn't the case, we can break down changes like this:

• when building plain bytecode: any change to any resource, or any change to the API/annotations of any type can matter here. If we support java plugins (and allow reading the bodies of methods etc) we might need to care about the implementation as well, but to my knowledge those tend to be compiler-specific and not generally safe. Still, medium risk, consider optimizing this case with caution.
• when building stripped bytecode: codegen has already been done, we only need this bytecode for downstream builds of this type or j2cl tasks. As such, we only need to detect API/annotation changes from upstream.
• when building j2cl JS: for j2cl to know what calls can be made and how to structure them, we only need the API/annotations from dependencies.

For at least the second two bulletpoints, we may be able to save ourselves from some recompiles by adding some work. Two basic plans to consider:

• Port the ijar tool to java, and process the stripped bytecode, then make the stripped-bytecode and j2cl tasks depend on this ijar bytecode instead of the real bytecode for dependencies. This adds an intermediate task before those downstream javac and j2cl tasks, but provides more resilient caching against changes that don't affect the api.
• Replace javac with https://github.com/google/turbine when building stripped bytecode. Assuming turbine by itself is roughly as fast as javac+ijar, this would be a simpler change (no additional tasks, less cached output), but at present turbine has no tags, no releases, and extremely sparse documentation.
• Third option: write our own, possibly incorporating a GwtIncompatible-stripping tool, so that this compiler operation can act on unstripped source code or bytecode. The form this could take would vary based on if we try to modify a parser/compiler or just add an asm step that modifies bytecode already being produced. This shouldn't be undertaken lightly, and assumes that J2CL will soon also do such stripping internally (an idea that has been floated before).

Evaluating performance of javac+ijar relative to turbine effectively requires implementing both options, but if we assume for the sake of argument that ijar costs no time/memory at all, we can pit turbine directly against javac. If performance of turbine is comparable or better, it seems easy enough to just use turbine for now (since we never use this stripped bytecode output). If it is substantially worse, we could still adopt it for projects in the current reactor, until ijar is evaluated.

Finally, turbine apparently is capable of running annotation processors, but it isn't clear to me what form that output would take. If the output is full source code and minimal bytecode, we would still need a custom step to strip GwtIncompatible types and members, but this starts to be a possible option to entirely replace unstripped javac as well.

[treblereel]

1) ijar: i have taken a look at sources and it can be rewritten to java, but the complexity of the task is medium to hard. What is nice, ijar has good tests so we can check that java port is one to one compatible with the original. As i can see, ijar is just a tool to process stripped bytecode, so no apt. 2) i did several turbine tests, it acts pretty much like javac, producing bytecode, but as far as i remember for j2cl we still need .java. 3) it's possible to write our own stripper, but i think it's better to investigate solutions we have at this moment, so i think, we should try turbine first.

[niloc132]

See notes from https://github.com/Vertispan/j2clmavenplugin/pull/165#issuecomment-1118081459 for perf - for a production build from a clean checkout (i.e no cache, etc), the performance improvement seems to be something like 3-5% faster with no other changes made, only replacing the stripped-bytecode tasks. By itself, that seems like a clear win. Note that in this case is about the worst possible scenario for a build, since closure is still dominating the build times for an ADVANCED build.

That said, this means that the gains will be much higher (percentage wise) when doing BUNDLE_JAR builds, and should be tested at least lightly for j2cl:watch, but more heavily for clean builds with just optimizationLevel=BUNDLE_JAR to see what a "cold start" would look like. Without the ADVANCED build dominating the build times, they might drop from 100s down to, say, 30s, and that 5s is no longer a 5% improvement, but a 15% improvement.