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());
Bug
Open
Major
Performance investigation: trivial loop structures result in major performance differences
.
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.
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.