[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Aliasing and Garbage Collection
Hi,
Tom wrote:
> I am a bit concerned (and hoping that I've misunderstood) by the suggestion
> that the overhead of GC can also be removed by simply 'buying twice as much
> memory', and not reclaiming anything. In a program with lots of dynamic
> allocation, i.e. most programs, especially OO, memory would be leaked very
> rapidly, I would imagine most Java code could get through a megabyte in a
> matter of seconds. It might work if you buy a million times as much memory!
This was not the point.
To put things straight: I think two concepts are mixed (by me, and maybe some
others):
1. Garbage Collection: the process of collecting unused memory fragments.
2. Memory Defragmentation: the process of reordering memory fragments such
that the memory is used more efficiently.
The overhead of memory defragmentation can be traded for buying more
(less than twice at much) memory.
In principle, this has nothing to do with Garbage Collection. Sorry for
causing the confusion.
Some more remarks on the performance overhead of Garbage Collection:
The overhead of Garbage Collection can be O(#pointercopies).
Use the following scheme:
- when allocating a memory fragment, register the object is shared
once "shareCount = 1"
- when copying a pointer, register the object is shared once more
"shareCount++"
- register the release of a pointer.
void free { sharedCount--; if (sharedCount==0) { call private free } }
In other words: Garbage Collection need only cost a ~fixed percentage
of the CPU performance.
However, in practice other strategies are used that are O(amount of memory).
Such approaches are of limited use in real-time systems. I think the
O(#pointercopies) option could be of use there.
Cheers,
Marcel