Implemented really weak handles.

Implemented really weak handles.

Really weak handles are like normal weak handles except that objects
are collected as soon as they are found to be unreachable and not on
the next GC.  When used for wrapper objects really weak handles can
significantly reduce time spent in GC.  With them we do more minor and
less major collections.

Note, in this change I also removed global object handle counting,
which nobody was using and which can be easily put back if someone
needs it again.

[Christian Plesner Hansen, 2009-10-06 13:47:21]

Overall lgtm.

The state NEAR_DEATH has become misleading since it is now also used after an
object is dead.  Maybe we should find a better name.

When doing the callback in PostGarbageCollectionProcessing are we passing a
stale object pointer to the callback?  If so we should use an empty handle for
really weak handles instead.

http://codereview.chromium.org/260017/diff/2006/2007
File include/v8.h (right):

http://codereview.chromium.org/260017/diff/2006/2007#newcode399
Line 399: inline void MakeReallyWeak(void* parameters, WeakReferenceCallback
callback);
I think we need to find a more informative name.  Alternatively we could use
MakeWeak for both and use a parameter to control when the callback is issued.

http://codereview.chromium.org/260017/diff/2006/2009
File src/global-handles.cc (right):

http://codereview.chromium.org/260017/diff/2006/2009#newcode96
Line 96: void MakeWeak(void* parameter, WeakReferenceCallback callback,
The 'callback' parameter should be moved to the next line as well.

http://codereview.chromium.org/260017/diff/2006/2009#newcode115
Line 115: ASSERT(!IsNearDeath() || !really_weak_);
Are we sure this can't happen?  Wouldn't it be safer to just ignore it in that
case, rather than ASSERT?

http://codereview.chromium.org/260017/diff/2006/2009#newcode410
Line 410: for (int i = 0; i < object_groups->length(); ++i) {
Changing from i++ to ++i shouldn't make any difference -- I'd prefer to keep the
i++ for consistency.

http://codereview.chromium.org/260017/diff/2006/2011
File test/cctest/test-api.cc (right):

http://codereview.chromium.org/260017/diff/2006/2011#newcode2963
Line 2963: CHECK(false);
UNREACHABLE()?

http://codereview.chromium.org/260017/diff/2006/2011#newcode2981
Line 2981: const Mode mode_;
Why const?

[antonm, 2009-10-29 10:16:59]

One problem and one observation.  If you don't think they are real problems,
could you add unittests to prove that?

Problem. Imagine we have objects A and B, A refers to B, A is held only by weak
handle, B is only held by really weak handle.  Now, GC occurs and both A and B
are found to be only weakly reachable.  Now imagine that weak reference callback
of A makes A strongly reachable.  If I understand this change correctly, that's
a problem as B would be already collected even though it becoms stronlgy
reachable after A's weak callback.

One solution I can immediately think of is to collect immediately only objects
held exactly by one really weak handle, but I am not sure what's the price to
pay.

Another solution is to defer collect after all weak callbacks were ran, but that
seems quite heaviweight.

Observation. Imaging object A held by really weak handle.  Once again GC occurs,
finds this A only weakly reachable and collects it.  However, before weak
reference callback of A is invoked, some other weak reference callback is
invoked which  goes back to V8.  This running code attempts to access A's handle
(e.g. via DOM node map), handle is yet in the map (A's weak reference callback
hasn't been invoked), but object is already collected.  Cure is simple---for
caches one need to check if handle is near death---but that need to be
implemented and has (probably non-existent) performance penalties.