RVM
  1. RVM
  2. RVM-160

Performance investigation: trivial loop structures result in major performance differences

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 3.2
    • Component/s: Compiler: Optimizing
    • Labels:
      None
    • Number of attachments :
      0

      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());

        Activity

        Hide
        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
        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:
            David Grove
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: