Closed
Bug 544695
Opened 14 years ago
Closed 14 years ago
Garbage collector policy should not be the same at all heap sizes
Categories
(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
flash10.1
People
(Reporter: lhansen, Assigned: lhansen)
Details
(Whiteboard: Has patch)
Attachments
(1 file)
10.17 KB,
patch
|
treilly
:
review+
|
Details | Diff | Splinter Review |
The garbage collector policy mainly affects non-reference-counted memory and as such it can be seen as analogous to the policy for the "old heap" in a generational system. There isn't normally a lot of performance pressure on that heap, but there is memory control pressure: While a 2x load factor is fine in a small heap it is too much in a large heap. For truly large heaps a factor as low as 1.1 may be appropriate. We should have a policy that provides breathing room for smaller programs but that run the incremental gc fairly aggressively in large heaps, so that large heaps don't grow excessively. (Adobe internal context: WE #2534231 and WE #2519943.)
Assignee | ||
Comment 1•14 years ago
|
||
Changes GCHeapConfig::gcLoad from a single value to a short table, with hopefully suitable heap size cutoffs for each, introduced as GCHeapConfig::gcLoadCutoff. Changes GCPolicyManager::adjustL to search the short table. (Only called at the end of a major GC cycle, so not a performance issue.) Changes avmshell.cpp to allow the table of load factors and cutoffs to be provided, and moves the definition of the "X" parameter (max multiplier) to a new argument.
Attachment #425677 -
Flags: review?(treilly)
Assignee | ||
Updated•14 years ago
|
Priority: -- → P2
Whiteboard: Has patch
Target Milestone: --- → flash10.1
Comment 2•14 years ago
|
||
Comment on attachment 425677 [details] [diff] [review] Patch Cool, this makes a lot of sense
Attachment #425677 -
Flags: review?(treilly) → review+
Assignee | ||
Comment 3•14 years ago
|
||
tr-argo changeset: 3675:c85fe7340d1e
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Status: RESOLVED → VERIFIED
Comment 4•13 years ago
|
||
Food for thought: Here are the default load factors, fed explicitly on the command line: % ./shell/avmshell.r5842 -load 2.5,10,2.0,25,1.75,50,1.5,75,1.25,100,1.1,150,1.05 ../../distilled3.abc tf1: 28060 ms - callLater test minmem: 2052 K maxmem: 615552 K If I peel off that 1.05, so that 1.1 becomes the max inverse load factor: % ./shell/avmshell.r5842 -load 2.5,10,2.0,25,1.75,50,1.5,75,1.25,100,1.1 ../../distilled3.abc tf1: 19923 ms - callLater test minmem: 2052 K maxmem: 628060 K And peeling off another layer: % ./shell/avmshell.r5842 -load 2.5,10,2.0,25,1.75,50,1.5,75,1.25 ../../distilled3.abc tf1: 13504 ms - callLater test minmem: 2052 K maxmem: 648668 K (The point being that we don't need to go all the way back to an inverse load factor of 2 to bring performance back for this benchmark.) Running the shell is fun and all, but my plan for now is to scribble out some formulas and see if I can come up with a disciplined argument for or against them.
OS: Mac OS X → Windows 7
Comment 5•13 years ago
|
||
(In reply to comment #4) > Food for thought: oops, that was supposed to go on Bug 619885.
You need to log in
before you can comment on or make changes to this bug.
Description
•