Is it possible to implement System.gcPause() ?

[bobrokrol]

Description

I'm curious if its possible to pause garbage collection to prevent unexpecred pauses in most innapropriate times.
Starling and AIR harman teams did a lot of work to use pools everyehere, but GC still persistantly pauses runtime. It seems that garbage collectiom has its own overhead regardless how many objects need to be erased.
So I think if it would be possible to pause it and then invoke it in convinient time, it would help to reduce jumps when you need stable framerate.

[ajwfrost]

I think it would be possible to postpone this prior to the final (non-incremental) work, which is where it causes glitches .. I'm not sure what the side effects might be though!

The below function is called with a "little and often" approach:
CollectionWork

The function that takes the time is when it's finished incremental marking - i.e. FinishIncrementalMark which then does the final lot of marking (non-stack roots, queue and stack, etc) and then does the "sweep" to clean up all of the non-marked objects:
FinishIncrementalMark

So, we could ensure that this final method doesn't get called whilst there's a pause in the GC. Or we could avoid any incremental work at all (i.e. setting the nogc flag). At which point, it looks like reference-counted collection still happens (very swift) but the mark-and-sweep GC is disabled.

Would be fascinating to see what happens to memory usage with this setting! I guess if you look at Scout, you see the occasional big drops in memory usage - when GC sweeps and you see a slow-down. Those just wouldn't happen, so memory would continue to increase. I don't see any reason why it wouldn't recover after you've set the GC back to normal.... we can try it :-)

There's a lot of requests around mmgc, so we may set up a new air.system.GC object to control stuff like this... which would be an "AIR v52" thing..

[bobaoapae]

This will be awesome.

[bobrokrol]

So, we could ensure that this final method doesn't get called whilst there's a pause in the GC. Or we could avoid any incremental work at all (i.e. setting the nogc flag). At which point, it looks like reference-counted collection still happens (very swift) but the mark-and-sweep GC is disabled.

Yes I think it's what may help, at least would be nice to test

Would be fascinating to see what happens to memory usage with this setting! I guess if you look at Scout, you see the occasional big drops in memory usage - when GC sweeps and you see a slow-down. Those just wouldn't happen, so memory would continue to increase. I don't see any reason why it wouldn't recover after you've set the GC back to normal.... we can try it :-)

In general it would be great to have something very simple and easy that will add more control control over GC so it would be possible to adjust it behaviour to concreete project.
Thats why I asked for pause as I guess it should not destroy anything. But if its possible to add more control over itarations and decide when to delete large / small objects it would be great. May be there is some constants / hardcoded values that would be possible to adjust. I mean anything thst is simple to implement but let us adjust ot behavioir may help.

There's a lot of requests around mmgc, so we may set up a new air.system.GC object to control stuff like this... which would be an "AIR v52" thing..

Would be great!