RVM
  1. RVM
  2. RVM-190

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

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.9.0, 2.9.0.1, 2.9.1
    • Fix Version/s: 3.2
    • Component/s: MMTk
    • Labels:
      None
    • Number of attachments :
      0

      Description

      For example, see MM_Constants. Things like:

      public static final boolean GENERATE_GC_TRACE = Selected.Constraints.get().generateGCTrace();

      block javac compile time folding of anything that depends on GENERATE_GC_TRACE. This in turn, impacts VM_JavaHeader.getObjectHashCode (one important example).

      Since we're generating Selected, we should generate it in a way that flattens all of the constants it is trying to export to jikesrvm into "flat" static final booleans instead of generating method calls on final objects that block folding.

        Activity

        Hide
        Steve Blackburn added a comment -

        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.

        Show
        Steve Blackburn added a comment - 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.
        Hide
        David Grove added a comment -

        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.

        Show
        David Grove added a comment - 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.
        Hide
        Steve Blackburn added a comment -

        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/

        Show
        Steve Blackburn added a comment - 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/
        Hide
        Ian Rogers added a comment -

        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.

        Show
        Ian Rogers added a comment - 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.
        Hide
        David Grove added a comment -

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

        Show
        David Grove added a comment - pushed off to 2.9.3; this would be nice to fix, but doesn't block a 2.9.2 release.

          People

          • Assignee:
            Unassigned
            Reporter:
            David Grove
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: