[heap] Fix weird unaligned allocation limits

Allocation observers used to set allocation limits with the intention
to statistically sample allocations that crossed those points. Those
limits had random alignment, but since object allocations are always
kTaggedSize-aligned, there is no benefit to having the limit be finer
grained. This patch makes sure that the limit is always aligned, which
in turn implies that the available space in a linear allocation area
is always a multiple of kTaggedSize.

Bug: v8:9700
Change-Id: Ib2980b4b8e792cf516cb734b451862c9e2a98029
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813026
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63895}

src/heap/spaces.cc

@@ -1912,19 +1912,8 @@ Address SpaceWithLinearArea::ComputeLimit(Address start, Address end,
     // Generated code may allocate inline from the linear allocation area for.
     // To make sure we can observe these allocations, we use a lower limit.
     size_t step = GetNextInlineAllocationStepSize();
-
-    // TODO(ofrobots): there is subtle difference between old space and new
-    // space here. Any way to avoid it? `step - 1` makes more sense as we would
-    // like to sample the object that straddles the `start + step` boundary.
-    // Rounding down further would introduce a small statistical error in
-    // sampling. However, presently PagedSpace requires limit to be aligned.
-    size_t rounded_step;
-    if (identity() == NEW_SPACE) {
-      DCHECK_GE(step, 1);
-      rounded_step = step - 1;
-    } else {
-      rounded_step = RoundSizeDownToObjectAlignment(static_cast<int>(step));
-    }
+    size_t rounded_step =
+        RoundSizeDownToObjectAlignment(static_cast<int>(step - 1));
     return Min(static_cast<Address>(start + min_size + rounded_step), end);
   } else {
     // The entire node can be used as the linear allocation area.