Structure of org.jikesrvm.memorymanagers.mminterface.Selected is blocking compile time folding of static final booleans

Dave, is your concern limited to cases where Jikes RVM tries to realize constants defined in MMTk? Or do you have concerns about the reverse too?

To clarify, some time ago we introduced glue to enable MMTk to be entirely separable, compiled as a standalone jar. My recollection was that we very thoroughly performance tested it.

Much more recently, the code you cite above was introduced. I am not sure whether it was performance tested or if perhaps the assumption was made that since the pattern worked on the other side, it should be fine on this side. As I understand it, this code (MM_Constants) is intended to provide a reciprocal level of modularity.

My point is that we have a real, concrete objective in shipping MMTk as a standalone jar, but its less clear we need to take modularity in the reverse direction to such lengths.

If I've understood things right, then we should be able to fairly aggressively attack the above (fairly simply too). I just want to be sure I understand things right first, though.

I think its a general concern (static final boolean's not being javac time compile constants) in code where we really care about getting the absolute last bit of performance.

Thanks to all of the improvements Ian has made in the last couple of years, the opt compiler is pretty good at chasing through chains of final fields and constant propagating the end values, so it's less of a concern than it used to be But, having the "dead" code in the bytecodes will inflate inline size estimates, which in terms impacts how much inlining we're going to do (we may be missing opportunities).

In this particular case, I think we can just change the way in which we generate the glue classes Jikes RVM sees and fix the immediate problem.

I suspect this sort of thing could be costing you some missed inlining opportunities in MMTk in general, but modularity goals could outweigh a few percent in performance. Also, MMTk is more aggressive in using @Inline pragmas than we are in the rest of Jikes RVM, so it's possible that compensates for the inliner making conservative size estimates.

A few weeks ago, when trying to track some historical performance regressions, Daniel and Robin noticed that ecj was compiling things quite differently to jikes. This, (or more precisely, an opt compiler reliance on jikes' way of doing things) was the source of one of our performance regressions.

At the time, I wondered about doing some bytecode transformations. What about dragging ASM [1] (or similar) into the build process? This could be used to reduce our reliance on javac optimizations and be a little more in control of what is happening. Of course it means pulling in another dependency, but on the other hand, our build system now allows us to do so relatively easy, particularly for java (rather than unix/OS) tools. One of ASM's claims is that it is small ("33KB instead of 350KB for BCEL"). I've used BCEL extensively in the past, but not used ASM.

Some people are using such tools with Jikes RVM already for their research, so if we did think it was worthwhile then I imagine it would get used by others for a variety of research tasks.

Just a thought....

[1] http://asm.objectweb.org/

I would like to see a bytecode transformation stage in the build, but this is probably a separate issue than this. My motivation for a bytecode transformation toolkit is to apply annotations to methods and fields we'd rather not go into the source and edit, @Pure annotations on Classpath libraries, @Immutable annotations on the ordinal to switch case maps produced by javac to handle switches on enums, .. We could detect these cases by making our class loader more complex, but this may have a detrimental effect at runtime. I think the jikes/ecj/javac issue Daniel and Robin have been looking at (RVM-160) should be fixed in the opt compiler without a reliance on ASM.

pushed off to 2.9.3; this would be nice to fix, but doesn't block a 2.9.2 release.