When allocation is forced because we already did two GCs we need to force GCs...

When allocation is forced because we already did two GCs we need to force GCs
even if we are attempting to allocate in young space.  There were a few cases
where this wasn't done.  Also misc. changes to make diagnosis of errors like
this one easier.

Committed: http://code.google.com/p/v8/source/detail?r=3010

[antonm, 2009-10-02 12:53:32]

Erik, any ideas about performance implications for DOM---GC changes sometimes
hit it badly?

http://codereview.chromium.org/251072/diff/1/2
File src/api.cc (right):

http://codereview.chromium.org/251072/diff/1/2#newcode110
Line 110: printf("%s: %s\n", location, message);
is it a reminder of debugging or intended change?

[Mads Ager (chromium), 2009-10-02 13:00:00]

LGTM with the print statement Anton pointed out removed.

[Erik Corry, 2009-10-02 13:09:24]

I don't expect this to be a noticeable performance hit, since the
force_allocation is a fully inlineable reference to a static variable.  Since
it's a correctness issue (causing crashes on Android) we have to commit it
anyway, though we can certainly try to find a faster solution if it turns out to
be noticeable.

http://codereview.chromium.org/251072/diff/1/2
File src/api.cc (right):

http://codereview.chromium.org/251072/diff/1/2#newcode110
Line 110: printf("%s: %s\n", location, message);
On 2009/10/02 12:53:33, antonm wrote:
> is it a reminder of debugging or intended change?

I guess it's a remainder of debugging.  It certainly would have saved me a lot
of time if it had been in there when I started investigating this issue.  For
some reason the VM crashes shortly after going though this function, so the
message is lost.

I'm going to change it to a PrintF that is only done in DEBUG mode.  This
routine is only called if no other error handler has been registered, so that
seems harmless and potentially very useful.