RVM

Performance regression due to string handling

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Runtime
  • Labels:
    None
  • Number of attachments :
    0

Description

Performance runs 3355 [1], 3356, and 3358 [2] showed a significant performance hit on a couple of benchmarks, presumably due to one or more of revisions 14091, 14092, and 14093, which relate to the way we handle strings.

Performance runs 3361 [3], 3365, and 3366 [4] show that while revision 14095 did appear to have fixed the regression in bloat's performance [5], it only partially fixed the problem with chart [6], and perhaps mtrt [7] (though mtrt is very noisy so it is less clear than for chart).

We should rectify chart's performance before moving on to other performance-related commits.

Looking back at 3355, 3356 and 3358, I wonder if we shouldn't just back them out? I'm not familiar enough with the code to know whether they constitute general improvements to the structure of the code (and are therefore worthwhile changes in their own right), but the did not improve performance and significantly degraded performance in some spots, so that leaves me wondering... I'll leave that to Ian to make the call since he's the one who invested the time.

Either way we need to fix the regression on chart (and possibly mtrt).

[1] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3355/performance_report
[2] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3358/performance_report
[3] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3358/performance_report
[4] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3358/performance_report
[5] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3366/production/default/perf-dacapo/bloat-10/bloat-10-time.large.png
[6] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3366/production/default/perf-dacapo/chart-10/chart-10-time.large.png
[7] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3366/production/default/perf-jvm98/mtrt-10/mtrt-10-time.large.png

Issue Links

This issue is related to:
RVM-435 Don't allocate memory when converting C buffers to Strings or Classes Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ian Rogers added a comment -

Yes, recent commits are addressing this issue.

Show
Ian Rogers added a comment - Yes, recent commits are addressing this issue.
Hide
Permalink
Steve Blackburn added a comment -

Indeed. We're inching forward very nicely. See also:

http://jikesrvm.anu.edu.au/~dacapo/release/graphs/3/3-perf.png

The challenge is to try to ensure the movement is monotonically upward.

I'm giving some thought as to how we can reduce noise in our performance runs and thus make it easier for all of us to spot regressions among all the upward and downward movement due to noise. Noise reduction in perf measurements is not a straightforward problem due to the non-deterministic nature of the AOS, scheduler, etc.

Show
Steve Blackburn added a comment - Indeed. We're inching forward very nicely. See also: http://jikesrvm.anu.edu.au/~dacapo/release/graphs/3/3-perf.png The challenge is to try to ensure the movement is monotonically upward. I'm giving some thought as to how we can reduce noise in our performance runs and thus make it easier for all of us to spot regressions among all the upward and downward movement due to noise. Noise reduction in perf measurements is not a straightforward problem due to the non-deterministic nature of the AOS, scheduler, etc.
Hide
Permalink
Ian Rogers added a comment -

Since r14106 all the performance regressions should now be fixed (I'll be watching any how). My concern in fixing the unnecessary allocations is not that they have been costing us performance but to allow a clearer picture on GC performance. The fact a rogue allocation in JNI caused by a local variable aliasing with another (fix in r14096) inhibiting a register from being SSA and thereby simple escape analysis/scalar replacement failing and thereby up to halving the GC performance is a worry.

I wonder if we could do daily GC visualizations where we can see object life times on a chart? Maybe something like type vs time, a line from the start and end of an object's life time. Maybe we could also colour code where the allocations were happening.

Other interesting visualizations would be the boot image space reports (don't forget RVM-226 where 0.5MB of the boot image goes to long arrays for normally unused MMTk statistics) that currently provide a per package break down of where space goes. Probably more important is to get regular profile reports so we can watch where execution time is going (for example my simple reports [1]).

[1] http://www.cs.man.ac.uk/~irogers/dacapo_profile.txt

Show
Ian Rogers added a comment - Since r14106 all the performance regressions should now be fixed (I'll be watching any how). My concern in fixing the unnecessary allocations is not that they have been costing us performance but to allow a clearer picture on GC performance. The fact a rogue allocation in JNI caused by a local variable aliasing with another (fix in r14096) inhibiting a register from being SSA and thereby simple escape analysis/scalar replacement failing and thereby up to halving the GC performance is a worry. I wonder if we could do daily GC visualizations where we can see object life times on a chart? Maybe something like type vs time, a line from the start and end of an object's life time. Maybe we could also colour code where the allocations were happening. Other interesting visualizations would be the boot image space reports (don't forget RVM-226 where 0.5MB of the boot image goes to long arrays for normally unused MMTk statistics) that currently provide a per package break down of where space goes. Probably more important is to get regular profile reports so we can watch where execution time is going (for example my simple reports [1]). [1] http://www.cs.man.ac.uk/~irogers/dacapo_profile.txt
Hide
Permalink
Ian Rogers added a comment -

Yay [1] ! green, green, green...

[1] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3379/performance_report

Show
Ian Rogers added a comment - Yay [1] ! green, green, green... [1] http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/perf/3379/performance_report

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.