Better gc control

[KaruroChori]

My last proposal for now.
Everything else it way too specific for my application and would not beneficial to anyone else.

Summary

To expand the current support of the underlying garbage collection mechanism in txiki.
To expose the interface needed for a finer control already enabled by quickjs, and to extend it with some additional hooks.

Rationale

One of the distinguishing features of quickjs compared to other engines is its reliance on a reference counting mechanism to handle the lifetime of all the object without cyclic dependencies. Otherwise, a more traditional garbage collector is employed, but the approach is to give ample freedom to the developer about when and how it should run. This might well be never, or based on fixed/dynamic thresholds.

As a result, we can either try to design code which avoids cyclic references to have a fully deterministic runtime execution in critical parts and perform manual gc events only in safe regions, or keep it mostly deterministic, with rare gc events to handle on a case by case basis. This makes quickjs particularly suitable for a wide range of real-time applications on embedded systems as long as the formal requirements are not too strict.

It would be nice if txiki would expose the underlying GC logic and events via callbacks, so that we can tune the thresholds and run custom code before and after any of those events is triggered. For example, if I am controlling a system which can be paused in a safe state, I might want to do that, perform the GC routine and resume the execution right after.

Proposed interface

Something like this, replacing the current gc function.

const gc = {
    run : ()=>void,
    fixed_threshold : (value:number)=>void,
    dynamic_threshold : (value:number)=>void,
    manual : ()=>void,
    register_before_callback : (fn:()=>boolean)=>void,  //If the callback returns false the current gc event will not be performed.
    register_after_callback : (fn:()=>void)=>void
}

While running one of those callbacks no further GC events should be considered.

[saghul]

Hey there!

Part of this discussion needs to happen on QuickJS-ng too, specifically the extra hooks, but there are improvements we can do today.

Exposing a form of JS_SetGCThreshold would make sense. Setting it to -1 effectively disables the GC, so we could implement the following API today:

const gc = {
    run : ()=>void,
    setEnabled : (value:boolean)=>void,
    setThreshold : (value:number)=>void,
}

There is certain overlap between enabled and threshold, but I think separating the 2 makes sense.

As for your proposal:

    fixed_threshold : (value:number)=>void,
    dynamic_threshold : (value:number)=>void,

What's the difference between these 2?

    manual : ()=>void,

What's the difference between this and run?

    register_before_callback : (fn:()=>boolean)=>void,  //If the callback returns false the current gc event will not be performed.
    register_after_callback : (fn:()=>void)=>void

These hooks make sense to ma, but we need to discuss that in QuickJS.

[KaruroChori]

In the original proposal:

• run is the manual execution of it, like current behaviour.
• fixed_threshold would be to ensure a single value of memory allocations being considered beyond which to trigger the gc automatically.
• dynamic_threshold would set a multiplier based on the previous threshold which triggered the previous gc event. Basically it is a factor to have an exponential dampening of the gc events frequencies. The logic is already implemented in the base quickjs code if I recall correctly, but the multiplier is fixed right now.
• manual was an alias to set it to -1. I don't particularly like magic values, so I preferred an explicit command for that with a clearer semantic.

[saghul]

I see. So I think we're very close.

• Your manual overlaps with my setEnabled which I find a bit more obvious.
• setThreshold could take 2 parameters fixed and dynamic if / when supports it.

Would you like to work on adding the part we can add now, and extend it later?

[KaruroChori]

If we were to make things proper I think it would be even better to create two properties enabled and threshold with getter and setter properties to show and change these values.

tjs.gc.enabled = true
tjs.gc.threshold = {type:'fixed', value:10e5}

console.log(tjs.gc.enabled)

Would it be suitable?

Yes, I will put this reduced version in the pipeline, and wait consensus in the other repository for the callbacks.

[saghul]

Sounds good! I guess threshold needs to just take a number for now, and we can turn it into an object later. So please, go ahead!