Our synchronization protocol for top and limit only guarantees that we
read the new limit in case we read the new top. However, it could happen
that we read the old top but the new limit. In the allocation slow path
we reset both top and limit to 0 first and then reset it to the
free list allocation boundaries.

With --no-inline-new we are changing top/limit a lot, so it could happen
that we read the old value for top (0) but a regular address for limit.
In such cases large parts of the heap would be incorrectly considered
pending. Handle these cases here by checking that top is non-zero.

This is temporary fix, we believe that it is at least theoretically
possible to read non-0 but non-consistent values for top/limit as well.
This will be addressed in a subsequent CL.

Bug: v8:11778
Change-Id: I6b581f2a6df3f24c16443717b0cde9a18c5f3f40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2903155
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74655}