Do not finish GlobalHandles::PostGarbageCollectionProcessing if weak callback...

Do not finish GlobalHandles::PostGarbageCollectionProcessing if weak callback
triggered it already (it's not safe).

[Mads Ager (chromium), 2009-08-21 05:58:16]

LGTM.

http://codereview.chromium.org/174141/diff/1002/12
File src/global-handles.cc (right):

http://codereview.chromium.org/174141/diff/1002/12#newcode279
Line 279: int time_stamp = 0;
You could expose Heap::mc_count() instead of introducing a new variable for
this.

http://codereview.chromium.org/174141/diff/1002/12#newcode292
Line 292: // Weak callback triggered another GC, the only safe thing
Could you describe in the comment why it is unsafe to delete the DESTROYED
nodes: When we return to the other instance of PostGarbageCollectionProcessing
the p in the code below could have been deleted if it was Disposed in the
callback.

http://codereview.chromium.org/174141/diff/1002/12#newcode294
Line 294: // or abort it, let's abort as it's simpler :)
Terminate comment with '.' and remove the smiley.  :)

http://codereview.chromium.org/174141/diff/1002/11
File src/heap.cc (right):

http://codereview.chromium.org/174141/diff/1002/11#newcode490
Line 490: if (!old_value) allow_allocation(false);
Just call allow_allocation with old_value?

[Mads Ager (chromium), 2009-08-21 06:09:28]

http://codereview.chromium.org/174141/diff/1002/12
File src/global-handles.cc (right):

http://codereview.chromium.org/174141/diff/1002/12#newcode279
Line 279: int time_stamp = 0;
On 2009/08/21 05:58:16, Mads Ager wrote:
> You could expose Heap::mc_count() instead of introducing a new variable for
> this.

Talking to Kasper, maybe it would be better to use Heap::gc_count() instead so
that the fix does not assume that global handle processing only occurs when
using the MarkCompact collector.

[Mads Ager (chromium), 2009-08-21 08:50:11]

Anton, I will land this one after a couple of minor changes.  I would like to
push to trunk now and I would like this to be in that push.

Thanks for fixing this.