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