|[12 earlier articles]|
|Re: Compile Time Garbage Collection impossible? firstname.lastname@example.org (2006-09-28)|
|Re: Compile Time Garbage Collection impossible? email@example.com (Greg Buchholz) (2006-09-28)|
|Re: Compile Time Garbage Collection impossible? bobduff@shell01.TheWorld.com (Robert A Duff) (2006-09-30)|
|Re: Compile Time Garbage Collection impossible? firstname.lastname@example.org (Daniel C. Wang) (2006-09-30)|
|Re: Compile Time Garbage Collection impossible? email@example.com (glen herrmannsfeldt) (2006-09-30)|
|Re: Compile Time Garbage Collection impossible? firstname.lastname@example.org (Wolfram Fenske) (2006-09-30)|
|Re: Compile Time Garbage Collection impossible? email@example.com (Satish Chandra Gupta) (2006-10-03)|
|Re: Compile Time Garbage Collection impossible? firstname.lastname@example.org (Oliver Bandel) (2006-10-08)|
|From:||Satish Chandra Gupta <email@example.com>|
|Date:||3 Oct 2006 18:18:50 -0400|
|Posted-Date:||03 Oct 2006 18:18:50 EDT|
I think that compile time garbage collection is impossible, and
existing approximation are not good enough or scalable. (it is my
opinion, but what do I know?)
But there have been some success in developing runtime tools to
identify and isolate problems due to holding references beyound useful
life an object. I will list two approaches:
1. Leakbot at IBM Research : It identifies "leaking regions" in Java
programs by doing heapdump analysis. References can be found at
and this technology has gone into products such as Rational
and Memory Dump Diagnostic tool bundled with WebSphare. So this one is
pretty scalable and useful. I have used with heap dumps from
production environments having 20+ million objects and almost 39+
2. Tools to identify Lag, Drag, Void and Use of various objects in
heap: Originally it was done for Haskell (N. Rojemo and C. Runciman,
"Lag, drag, void and use -- heap profiling and space-efficient
compilation revisited," Proceedings of the ACM SIGPLAN International
Conference on Function Programming, pp. 34-41, 1996), and later for
Java as well (R. Shaham, E. K. Kolodner, and M. Sagiv, "Heap Profiling
for Space-Efficient Java," Proceedings of ACM SIGPLAN Conference on
Programming Language Design and Implementation, pp. 104-113, 2001).
Of course, these tools wouldn't GC the "useless but rechable" objects
automatically. They just indicate where you need to look to fix your
program so that a reference to unused objects doesn't remain alive.
Interestingly, Shaham/Kolodner/Sagiv indicate that the future work
would be to use the drag analysis results for directing static
analysis in a compiler to automatically do some code transformation
for reducing drag.
my 2 bits,
--- glen herrmannsfeldt <firstname.lastname@example.org> wrote:
> A.L. wrote:
>> Determining what objects could be deallocated during compilation is
>> equivalent to "halting problem" that is undecidable. i.e. there is
>> no algorithm possible that could do this for all possible programs.
> I don't disagree, but determining deallocation at
> run-time isn't so easy, either.
> In addition to circular linked lists, which as already mentioned are
> a problem for reference count GC, there is memory allocated in main
> and not referenced later. Those two are often indicated in Java
> documentation. ...
Return to the
Search the comp.compilers archives again.