OpenEuphoria

RE: Garbage Collection

• Posted by Mike <vulcan at win.co.nz> Jun 27, 2005
• 505 views

Rob,

What if the program flow were analysed and redundant RefCount ops were 
optimised out? I was (& still am) hoping to do this in my E_to_C 
translator. Eg:

function add_1(sequence s) 
  return s + 1
end function

-- parser detects that parameter s is potentially PBR rather than PBV
-- though, fundamentally, all parameters (excluding integers) are PBR
-- since the RefCount on s will always be 1 at the start of the
-- function. See comments below.

sequence a, b

a = "abc" -- refCount is 1
a = add_1(a) -- no copy of variable a need be done

b = a -- refCount is 2
a = add_1(a) -- copy of variable a must be done


I guess this implies that RefCount ops for routine parameters are made 
before the routine is invoked. This also might slightly increase in code 
size in some cases (for the interpreter?). Detecting the potential for 
such an optimization will require adroit code analysis, but could be 
worth it (especially where large sequences are being used) IMO. I 
suspect that this idea would require less change to Euphoria 
(internally) compared with implementing true GC.

Fragmentation (if it became a problem) could be thwarted by allowing the 
user to invoke a consolidation function (that you'd add to Euphoria) at 
some safe place in the app.


Regards,
Mike


Robert Craig wrote:

--snip

> Main Advantages to GC over RC in Euphoria:
>    - eliminates all DeRef's (faster program execution 
>      and reduced size (by 15%?) of translated code. 
>      Less chance for coding errors.)
>    - very fast allocation of blocks (with most methods) and deallocation
>      is a no-op
>    - eliminates overheads (such as ref count field) on each block of 
>    storage
>    - eliminates storage fragmentation (with most methods) that could
>      prevent allocation of a big block, even though many small
>      non-contiguous blocks are free
> 
> Main Disadvantages:
>    - random pauses in execution (there are ways to control this but
>      not completely eliminate it. RC can also cause small pauses sometimes,
>      but that can be almost completely eliminated quite easily)
>    - for efficiency you must pre-reserve memory well in excess of what 
>      you actually need
>    - some Ref's of a sequence would have to become full copies
>      (maybe you could "lock" sequences that are going to be modified
>      repeatedly)
>    - RC seems to have better cache performance, since it reuses
>      blocks that were used recently, while GC keeps moving further
>      into fresh areas of memory
>    - GC is known for introducing subtle bugs. The algorithms must
>      be implemented very carefully.
> 
> If anyone has any ideas on this, please post them.
> I'm still actively thinking about all these issues.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com