Bug: the last allocated object can not be finalized? Shall we clear the stack after we construct the gc_cleanup object? about bdwgc HOT 4 CLOSED

All right, maybe gc think the 'aaa' variable is still using in stack. If I put allocation in a independent function, everything is fine.

from bdwgc.

See that ESP+4 to ESP+12 stores the address unexpectedly. And here is the asm of gc_cleanup::gc_cleanup() in Debug mode.

from bdwgc.

My feeling is that this is a judgment call. If there is an easy way to
clean more dead registers or stack locations at minimal cost, then it may
be worth doing. But a conservative collector is never going to guarantee
that "all dead objects" will be collected. Even for a non-conservative GC,
that's a tough notion to define, and Java doesn't try. No code should be
relying on running a finalizer at a certain point.

In this particular case, it's not clear to me there is a cheap/easy
solution. Especially if this only happens in debug mode.

I would generally be more concerned with stack locations that may not be
overwritten for a long time than with registers that might keep an object
live for a single GC.

On Mon, Jan 4, 2016 at 7:32 AM, taigacon [email protected] wrote:

All right, EAX and ECX still hold the address of the latest allocated
object ( in Debug mode ). Shall we clear all the registers before we call
GC_gccollect() ?

—
Reply to this email directly or view it on GitHub
#85 (comment).

from bdwgc.

@hboehm writes:

Even for a non-conservative GC, that's a tough notion to define

Indeed. See http://www.memorymanagement.org/glossary/d.html#term-dead

It is not possible, in general, for garbage collectors to determine exactly which objects are dead and which are live. Instead, they use some approximation to detect objects that are provably dead, such as those that are unreachable.

And also http://www.ravenbrook.com/project/mps/master/manual/html/topic/finalization.html#cautions

Don’t rely on finalization for your program to work. Treat it as an optimization that enables the freeing of resources that the garbage collector can prove are unreachable.

This is a message I've been repeating for many years :)

from bdwgc.