Control over GC (enable/disable/set-ceiling, etc)

#1

Maybe this is too “fringe”, but, I would like to see some level of control over the garbage collector where I can either change dynamically change the bar for when gc happens or disable/enable it explicitly.

What would be the use case? I sometimes need to do “semi-hard” real time stuff (e.g. millisecond level granularity) with GPIO (read and write with protocol dictated time constraints) and a full gc would throw that timing off. Most of the time, impressively, the actual uLisp code isn’t the bottle-neck, but as my code base grows, gc rears its head at inopportune times.

I did a rather clumsy hack in my fork https://github.com/tcoram/ulisp-arm to accomplish this.

Is this request too fringe? (I actually use uLisp for real deploy-able embedded devices and find it more than adequate!)

#2

[Offtopic: your avatar, unenlarged, looks like a weaponised raspberry. (Yeah, I know, mine, too.)]

#3

LMAO. Yeah, I suppose. It’s very old school, an airbrush illustration of Oliver Wendell Jones I did back in the 1980s.

#4

@tcoram it’s a good suggestion, but I wonder how many people would find that useful. I imagine most uLisp users just let garbage collection do its thing without worrying about it. I welcome a discussion about it.

#5

My 2c: when I needed it to not interfere, I forced it. Like, JUST before you do X, call gc — and X thereafter is perfectly smooth. VERY rare occasions, btw — when operating at the top of memory usage on low-end microcontrollers.

#6

TBH, Where it is most useful to me, is for larger apps (or larger chunks of data), where I am always precariously close to the ceiling of WORKSPACESIZE. Since eval will call gc, the app may pause in critical sections. Of course, I’m pushing the limits by having such large applications…

My change is simply:

// if (Freespace <= WORKSPACESIZE>>4) gc(form, env);
if (Freespace <= gc_low_threshold) gc(form, env)

where gc_low_threshold can be modified by the interpreter.