Re: Compile Time Garbage Collection impossible?

On 22 Sep 2006 22:29:03 -0400, the.real.doctor.zoidberg@gmail.com
wrote:


>Why isn't Compile-Time-Garbage-Collection feasible? Consider a Java
>compiler which produces assembly code for a specific target instead of
>Java's bytecode cenario. The objective is to use Java without the need
>for a GC or VM.


Java only specifies that implementations use automatic memory
reclamation - it does *not* specify the method to use. A perfectly
acceptable automatic method is not to collect at all and in fact this
is the method used in JavaCard and certain implementations of Java ME.




>I'm asking why it isn't possible because otherwise there would be at
>least one compiler to use that technique, instead of having to run a
>GC in the VM.


It is possible and there are compilers using it. Google region-based
memory management and real time java. IIRC, the original research on
regions was done for ML, but it's use has since been researched in and
incorporated into a number of languages.


However, region inference is (currently) feasible only in the single
threaded case. If an object is shared among threads it can be
difficult or impossible for the compiler to statically determine the
lifetime of the object. You can address this somewhat by copying or
by handing off objects, keeping single thread semantics as much as
possible rather than sharing, but in a multithreaded program region
inference will still retain some objects beyond their useful life just
like any other automatic system.




>When a program is compiled, the compiler has to transverse all its
>code to ensure type safety (for safe languages), so what would be the
>problem in "freeing" objects after their scope, or even better, after
>the last reference in their scope?


Scoping refers to visibility, not to lifetime. Many objects continue
to live outside their scopes of visibility.




George

Return to the comp.compilers page.
Search the comp.compilers archives again.