Comments on: Recycle Refinements in 3.0

Here is a question for REBOL experts to consider:

When recycle refinements are specified, should GC always be triggered?

In 3.0 recycle is defined as:

recycle: native [
    {Recycles unused memory.}
    /off {Disable auto-recycling}
    /on {Enable auto-recycling}
    /ballast {Trigger for auto-recycle (memory used)}
    size [integer!]
    /torture {Constant recycle (for internal debugging)}
]

So, for example, if you write:

recycle/off
some code
recycle/on

Does each of those calls initiate GC (garbage collection)?

Currently, /off does not initiate GC, but /on does.

There are also the /torture and /ballast refinements to consider. They both trigger GC as well at this time, but should they?

In addition, recycle now returns the number of freed series (or none if no GC was done). This is informational only, and you can ignore it, but it can be handy at times, so it has been added.

Note that /ballast refinement is new in 3.0. It allows you to control the frequency of GC. For example, if you want less frequent auto-GC, you can set the ballast number higher. For example, if you are processing many images, setting the ballast higher will reduce the time consumed by GC, but there will be an increase in system memory usage. A tradeoff that you get to control.

This leads to the further question of: should the refinements return their prior values? If you set /ballast, should recycle return the prior value? If so, should a GC be performed or not, and the number of freed series cannot be returned in that case (because the prior ballast is returned).

Also, /torture is the same as setting /ballast to zero, so I'm thinking that /torture will get removed. It's always been "unofficial" anyway.

I think you get the issues, they are somewhat minor, but let's hear your thoughts on it so we can make it work the best possible way.

11 Comments

Comments:

Volker 31-Jul-2006 2:24	No implicit trigger please. For one it is not needed, simply use "recycle/on recycle". For the other, its a performance tool (good idea to add /balance btw). Calming down the gc for speed and then enforcing one is contraproductive. Specially when a gc is not needed. For example an image-procesing-loop may balance for a lot images, but in some usage only process a few. But that loop is called multiple times. But still it does not exceed the old balance. Now without balancing at all, no recycle would happen. With it happens on every loop. Returning the old balance-value would be good IMHO. Then a memory-eating loop needs no big planing, just a recycle/balance around it. One issue: should recycle wrap around code, to be safe with errors? eg "recycle/balance 12345 [this need lot of memory]" if an error is triggered, memory is auto-reset.
Gabriele 31-Jul-2006 4:37	:) I'd say: do a recycle on recycle/on, but not on /off or /ballast (however, if the new ballast is smaller than the current used memory, maybe it should? it would at the next allocation anyway, wouldn't it?)
Mario 31-Jul-2006 4:37	:) What about a recycle/now refinement? It should be ignored when used with /off. About the returned value I will suggest (despite I'm the first that doesn't find it smart/elegant) to return a series with both the values in order to have a standard behaviour. Otherwise the /now refinement should be used only with /on returning the number of freed series and in all the other cases (/off too) return the previous /ballast (this makes sense as when you turn it off you may want to store the timing for instance when you are saving a config and exiting)
Gregg Irwin 31-Jul-2006 13:18	:) I would vote for no implicit trigger if refinements are used. In the case of /on or /ballast, it will then recycle when it needs to. That makes it simple to understand, and I think it's cleaner to separate the behavior of changing a setting from triggering an action.
John Niclasen 31-Jul-2006 13:48	I can imagine a 'panic' situation, where I would like the system to respond to me. I guess, those situations occur, when the system is recycling and disc-swapping etc. Stopping recycle and GC in such a situation would be nice, so recycle/off shouldn't trigger GC. It's like I want to say: "Stop whatever you're doing, please!" And "stop" shouldn't mean: "Oh, and do this also."
Cyphre 1-Aug-2006 11:59	I also vote for no implicit trigger if refinements are used. Also, when talking about the GC features: I don't know if this is technically possible in the Rebol GC but would be also possible to force the GC to recycle specific series? Something like: my-buffer: make binary! 200000 do-something-with-my-buffer my-buffer: none recycle/force my-buffer So this way programmer would be 100% sure the memory used for my-buffer has been freed for another use. What do you think?
Goldevil 1-Aug-2006 17:00	If recycle/torture is equivalent to recycle/ballast 0, it could be certainly removed. I don't understand how /torture can be usefull. Very very low memory system ? Otherwise, I agree to avoid triggering for any refinement.
Maxim Olivier-Adlhoch 2-Aug-2006 14:42	no triggering please... the point of controling the GC is that we want it to happen when its really usefull/optimal. I second the vote for recycle/now in my tests, handling the recycle manually is extremely beneficial I have seen some memory intensive loops double in speed (and quintuple in ram, but who cares when you have 4GB). I also wish there could be a way to list (much like cyphre tells) a series to explicitely GC. maybe a special /this refinement could then be added. This would allow us to call recycle/off within loops and still control a fine-grained amount of GC action we know is usefull.
Anton Rolls 10-Aug-2006 2:06	Isn't recycle/now the same as recycle (without any refinements)?
HY 10-Aug-2006 6:34	A remarque that's similar: I remember being disappointed and confused before realizing that random/seed only took the seed and didn't also return a random value...
Ladislav Mecir 16-Aug-2006 6:51	I do not want to always start recycle either. Programmers will have more control if only Recycle without refinements starts the garbage collection.

Post a Comment:

You can post a comment here. Keep it on-topic.