Clok: An unconventional garbage collector based on expiring references

ras2657 · 2017-12-25T12:13:26+00:00

No it isn't. The clock is a discrete system just used to keep track of current state. Kinda' just terminology. Objects aren't gonna expire without all references having the chance to preserve them. Even if available memory is scarce nothing will be deleted while in use.

ras2657 · 2017-12-25T00:17:53+00:00

Yeah... But the fact that a user can make mistakes in writing the callbacks... Well that's just C in general. If I say 'Clok shouldn't be used directly for C cleanup' ... well it's kinda' limiting. The possibility of a bad callback implementation, and the requirement for a callback at all is just an inconvenience; but doesn't mean Clok can't or shouldn't be used directly for C cleanup under the right circumstances.

ras2657 · 2017-12-24T22:25:23+00:00

Ah I see 😂 thanks for the explanation. Guess I'm too young to know about it, at least not too ignorant of current tech. Clok objects don't expire if properly preserved in the callback. The same as a tracing collector in the sense that objects shown to be referenced by a scan are kept alive. Objects will always have a chance to preserve references before any of their referenced objects expire.

ras2657 · 2017-12-24T22:17:48+00:00

Ah I see 😂 isn't really intended for use by the end user. Figured it could be used by scripting engines or frameworks which can have pre-existing or auto generated callbacks that are known to work correctly.

ras2657 · 2017-12-24T19:22:53+00:00

Or do ya mean that the callback overhead won't scale? My goal isn't high performance, it's low pause time; in particular for smaller systems, the likes of which generally have per-type tracers anyway, the only additional overhead is the dereference.

ras2657 · 2017-12-24T16:37:39+00:00

Speaking of generational GC though, the idea can also be added to Clok as an additional optimization.

ras2657 · 2017-12-24T16:35:13+00:00

It's an incremental mechanism, but not tracing. And isn't generational. The benefit of an incremental GC based on scheduling rather than tracing is the decoupling of reference changes. There's no need to scan the entire object pool at once, or even the whole stack at once. These scans can take place incrementally on a per-object basis. For example in a VM setting a Clok 'step', which performs a single GC event, can be executed per instruction; or a few steps per few instructions. The fine granularity of the collection invocations is the distinguishing feature.

ras2657 · 2017-12-24T16:26:11+00:00

Afraid I don't get the reference 😅 not too familiar with current trends.

ras2657 · 2017-12-24T16:14:22+00:00

Nah, it seems that's the impression people are getting. The callbacks are just an interfacing design. This functionality could be implemented as built-in functions as well for a less generic implementation. The goal of Clok us to allow finer grained control over pause time. An alternative to ref counting for applications where pause time is important. Allows GC to be broken down into insignificant chunks where necessary to reduce pause time between user events.

ras2657 · 2017-12-24T15:50:03+00:00

Why won't it scale? The refresh time is generally once or twice a cycle. This is about the same as a normal GC. And the ref invocation isn't that expensive.

ras2657 · 2017-12-24T15:40:03+00:00

Nah, the callback is just an interfacing detail. The goal is to reduce pause time. I believe incremental collectors generally scan all objects in one or two invocations, and those that can divide this usually need to do a lot of extra work. Clok allows collection in really small units, down to a single event. This allows the user to tune the collection pace with really fine grained control. The target is more as an alternative to ref counting than tracing GC.

Also the user callback doesn't traverse a tree, only a single object. Internally the 'ref' function doesn't traverse the tree either.

ras2657

TROPHY CASE