Tune GC heuristics for big remsets. #12632
Conversation
|
Most of the conflicts seems to be cause by my reorganization for gc debugging. Will push a rebased version later. |
Take the number of pointers transgressing the generational frontier into account when deciding wether to do a young or an old gen collection. Helps #10428. Didn't run the bench suite yet.
|
The original branch is backed up at the yyc/gctune.bak branch with the commit SHA 238ed08. Rebased version force pushed to the ob/gctune branch. |
| @@ -1708,10 +1715,12 @@ static int push_root(jl_value_t *v, int d, int bits) | |||
| } | |||
| } | |||
| else if (vt == (jl_value_t*)jl_module_type) { | |||
| // should increase nptr here | |||
There was a problem hiding this comment.
is this an action item, or a comment on what it does, or neither?
There was a problem hiding this comment.
This does look like a dangerous comment.
|
Cool! How much does it help readdlm? |
|
so this is the change that has been rotting away on one of my branches for a long time. Last time I tried it solved the runaway heuristic thing, and brought down the time from 95% gc to around 20% in my recollection. I probably wont have time to test it again until next week. |
|
Bump. It would be nice to run the performance tests and get this in for 0.4. |
|
i take full responsability |
Tune GC heuristics for big remsets.
|
@carnaval is drunk |
Take the number of pointers transgressing the generational frontier
into account when deciding wether to do a young or an old gen
collection. Helps #10428. Didn't run the bench suite yet.