RVM

Opt compiler memory usage

Details

  • Type: Wish Wish
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Compiler: Optimizing, MMTk
  • Labels:
    None
  • Number of attachments :
    0

Description

I did some rough calculations yesterday of the size of things like BURS tree nodes and space efficient graph nodes in the opt compiler. A BURS tree node needs about 71bytes of memory, which will get rounded up to 74bytes. A space efficient graph node is about 48bytes in size. With headers and alignment we possibly push the total size to around 138bytes. In LIR to MIR we will create a space efficient graph node and BURS tree node per instruction, with the IR containing between 100 and a few thousand instructions this could push the amount of space requested into the region of 100s of kb.

A generational GC should recognize that nearly of this is junk and bin it. But for some benchmarks (like Jython that has large basic blocks just containing calls) we may be overflowing the nursery. It would be good if it were some how possible to monitor the opt compiler doing bad things to the GC. This would help identify if strange performance of the opt compiler were down to GC (and then we can fix the size of the opt compiler IR).

Issue Links

is related to

Improvement - An improvement or enhancement to an existing feature or task. RVM-188 BURS in the DaCapo Jython benchmark is more expensive than normal

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

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

So my really poor attempt to work out whether there is an issue here was to run the RVM with -X:opt:phases=true -X:gc:verbose=2 and then look at where the string "
[GC" appeared next to a line containing "BURS". For DaCapo eclipse (large and 3 iterations) 1452 methods are opt compiled, the run lasts for 172s and the number of occurrences of BURS and GC is 26. Copying this for Jython the numbers are 539 methods, run lasts 50s and the number of occurrences of BURS and GC is 19. So (hand wave hand wave) we're twice as likely to see GC and BURS together when running Jython compared to eclipse. This isn't necessarily bad but in may be a point in trying to diagnose the poor BURS performance on Jython compared to other benchmarks.

Show
Ian Rogers added a comment - So my really poor attempt to work out whether there is an issue here was to run the RVM with -X:opt:phases=true -X:gc:verbose=2 and then look at where the string " [GC" appeared next to a line containing "BURS". For DaCapo eclipse (large and 3 iterations) 1452 methods are opt compiled, the run lasts for 172s and the number of occurrences of BURS and GC is 26. Copying this for Jython the numbers are 539 methods, run lasts 50s and the number of occurrences of BURS and GC is 19. So ( hand wave hand wave ) we're twice as likely to see GC and BURS together when running Jython compared to eclipse. This isn't necessarily bad but in may be a point in trying to diagnose the poor BURS performance on Jython compared to other benchmarks.
Hide
Permalink
David Grove added a comment -

One thing to note is that the way we do compilation timing, the reported compile times do not include any GC that happened during the compile. So the time reported being spent in BURS really is time in BURS. We're taking advantage of the fact we're on green threads and accumulation time at context switches for the compilation thread.

Show
David Grove added a comment - One thing to note is that the way we do compilation timing, the reported compile times do not include any GC that happened during the compile. So the time reported being spent in BURS really is time in BURS. We're taking advantage of the fact we're on green threads and accumulation time at context switches for the compilation thread.
Hide
Permalink
Ian Rogers added a comment -

So using lots of memory in the opt compiler pushes up the time spent in GC threads but has limited effect on measured compilation or measuring compilation phases. The limited effect is to push allocation time into the allocation slow path and possibly there could be some waiting/spinning for locks that occurs here. I will make a test to try this out but will kill this issue if this is the case. We may well be allocating too much in the opt compiler but it shouldn't relate to large increases in the compilation time.

Show
Ian Rogers added a comment - So using lots of memory in the opt compiler pushes up the time spent in GC threads but has limited effect on measured compilation or measuring compilation phases. The limited effect is to push allocation time into the allocation slow path and possibly there could be some waiting/spinning for locks that occurs here. I will make a test to try this out but will kill this issue if this is the case. We may well be allocating too much in the opt compiler but it shouldn't relate to large increases in the compilation time.
Hide
Permalink
David Grove added a comment -

I think the conclusion was that although making the opt compiler less of a memory pig would be a good thing, it wasn't the problem with jython BURS cost.

Show
David Grove added a comment - I think the conclusion was that although making the opt compiler less of a memory pig would be a good thing, it wasn't the problem with jython BURS cost.

People

  • Assignee:
    Daniel Frampton
    Reporter:
    Ian Rogers
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: