On Sun, 11 May 2014 16:33:04 -0400, Walter Bright
<[email protected]> wrote:
On 5/11/2014 2:48 AM, Benjamin Thaut wrote:
Mostly percise doesn't help. Its either fully percise or beeing stuck
with a
impercise mark & sweep.
This is not correct. It helps because most of the false pointers will be
in the heap, and the heap will be accurately scanned, nearly eliminating
false references to garbage.
It doesn't matter where the false pointers are. The largest issue with
false pointers is not how many false pointers there are. It only matters
how large the block is that it "points" at. The larger your blocks get,
the more likely they are "pointed" at by the stack. On 32-bit systems,
allocate 1/256th of your memory space (i.e. 16.5MB), and the likelihood of
random data on the stack pointing at it is roughly 1/256. This problem is
just about eliminated with 64-bit pointers.
Yes. D, for example, requires that objects not be self-referential for
this reason.
As previously stated, self referencing does not preclude GC moving. This
statement is simply false, you can self reference in D for objects. You
cannot for structs, but not because of a possibility for the moving GC,
but because of the requirement to be able to move a struct instance.
And in fact, even if it's forbidden, "requires" is too strong a word --
there is no static or runtime prevention of this.
-Steve
