On Mon, 12 May 2014 13:52:20 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
On 5/12/2014 7:46 AM, Steven Schveighoffer wrote:
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.
Generally, it is a bad idea to allocate such large blocks on the GC
heap. GC's work best when the size of the objects being allocated is
very small relative to the size of the heap space.
Fortunately, it's a mathematical inevitability that large allocations
relative to the GC size are rare, and so it isn't much of a pain to
handle them manually.
The issue arises when one allocates such a large block for temporary use
repeatedly, but expects it to be collected between allocations. The
consequences are extremely disastrous.
The workaround is simply to keep it around, but that's not always a
scalable solution.
And in fact, even if it's forbidden, "requires" is too strong a word --
there is
no static or runtime prevention of this.
It's still forbidden. Andrei wrote a template that will verify this at
runtime, but I don't recall its name.
Can you cite the spec where it says it's forbidden? Forgotten templates
are not a convincing argument.
Regardless, Java can use a moving GC, and allows self references. The idea
that self references prevent a moving GC is simply false. If you think
about it a bit, you will understand why.
-Steve
