Uploaded image for project: 'JikesRVM'
  1. JikesRVM
  2. RVM-160

Performance investigation: trivial loop structures result in major performance differences

    Details

    • Type: Bug
    • Status: Open
    • Priority: Medium
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.2
    • Component/s: Compiler: Optimizing
    • Labels:
      None

      Description

      Daniel has been looking into performance problems in MMTk. Here's a snippet of code from scanObject. Tracing rate is 430 on the first version, 465 on the second one. We need to look into how the opt compiler is generating code for these two versions of the loop and figure out why they aren't identical.

      while (values.isNonEmpty()) {
      ObjectReference v = values.pop();
      scanObject(v);
      };

      vs.

      if (values.isEmpty()) return;

      do {
      ObjectReference v = values.pop();
      scanObject(v);
      } while (values.isNonEmpty());

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            zyridium Daniel Frampton added a comment -

            There are a range of other performance anomalies similar to the above that we have been seeing when experimenting with the tracing loop.

            Significant performance differences for equivalent code was also seen when we changed from jikes to ecj and saw a noticeable performance drop.

            The presence of odd examples like the one I mentioned to Dave and shown above – where we have two versions of a cut down TraceLocal.completeTrace – makes life rather complicated .

            Changing inline decisions does not appear to be the problem, as almost all of MMTk's inlining decisions are directed explicitly with annotations.

            Perhaps part of this problem can be avoided by gathering and using edge counter/profile information?

            A related issue to this is adding an improved measure of tracing rate. Current figures are reported by FixedLive, which has its limitations.

            Show
            zyridium Daniel Frampton added a comment - There are a range of other performance anomalies similar to the above that we have been seeing when experimenting with the tracing loop. Significant performance differences for equivalent code was also seen when we changed from jikes to ecj and saw a noticeable performance drop. The presence of odd examples like the one I mentioned to Dave and shown above – where we have two versions of a cut down TraceLocal.completeTrace – makes life rather complicated . Changing inline decisions does not appear to be the problem, as almost all of MMTk's inlining decisions are directed explicitly with annotations. Perhaps part of this problem can be avoided by gathering and using edge counter/profile information? A related issue to this is adding an improved measure of tracing rate. Current figures are reported by FixedLive, which has its limitations.

              People

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

                Dates

                • Created:
                  Updated: