On PPC64 linux the OS page size is 64KB, therefore when the
snapshot is created the serialized heap already has LO_SPACE
allocated(the allocation goes beyond the 1st page of
CODE_SPACE and hence LO_SPACE is allocated).
I've updated the testcase to check if the delta
of the LO_SPACE is zero.
R=mlippautz@chromium.org, ulan@chromium.org, vogelheim@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2394893002
Cr-Commit-Position: refs/heads/master@{#40014}
Reason for revert:
No real improvement as we still lack the ability to promote from
scavenges/young gen GCs.
Let's keep this in mind for later.
Original issue's description:
> [heap] Remove border page
>
> A page now belongs either the nursery *or* the intermediate gen. The page that
> contained objects of both spaces is removed in this change.
>
> BUG=chromium:636331
>
> Committed: https://crrev.com/42ece47446f0dbd3779d6e0e00dce97a1931a9f9
> Cr-Commit-Position: refs/heads/master@{#39778}
TBR=ulan@chromium.org,hpayer@chromium.org
BUG=chromium:636331
Review-Url: https://codereview.chromium.org/2383443002
Cr-Commit-Position: refs/heads/master@{#39854}
Reason for revert:
OOMs in nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/9572
Original issue's description:
> [heap] New heuristics for starting of incremental marking.
>
> The motivation for this patch is to move more marking work to tasks.
> This is done by postponing the start of incremental marking until
> a marking task is running.
>
> This patch introduces a soft and a hard limits for incremental marking.
> When the soft limit is reached, the marking task is scheduled.
> If the hard limit is reached before the task is running, then
> incremental marking is started without waiting for the task.
>
> BUG=chromium:616434
> LOG=NO
>
> Committed: https://crrev.com/55683ddd2a32e0dfb8df66271fbf53e3618cce9d
> Cr-Commit-Position: refs/heads/master@{#39831}
TBR=hpayer@chromium.org,ulan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:616434
Review-Url: https://codereview.chromium.org/2375983002
Cr-Commit-Position: refs/heads/master@{#39833}
The motivation for this patch is to move more marking work to tasks.
This is done by postponing the start of incremental marking until
a marking task is running.
This patch introduces a soft and a hard limits for incremental marking.
When the soft limit is reached, the marking task is scheduled.
If the hard limit is reached before the task is running, then
incremental marking is started without waiting for the task.
BUG=chromium:616434
LOG=NO
Review-Url: https://codereview.chromium.org/2364923002
Cr-Commit-Position: refs/heads/master@{#39831}
This patch simplifies code for speeding up marking and
removes write barrier counter.
The step size is now computed based in two parts:
- bytes to mark in order to keep up with allocation,
- bytes to mark in order to make progress.
BUG=chromium:616434, chromium:646139, chromium:644819
LOG=NO
Review-Url: https://codereview.chromium.org/2359903002
Cr-Commit-Position: refs/heads/master@{#39827}
A page now belongs either the nursery *or* the intermediate gen. The page that
contained objects of both spaces is removed in this change.
BUG=chromium:636331
Review-Url: https://codereview.chromium.org/2209583002
Cr-Commit-Position: refs/heads/master@{#39778}
This patch changes incremental marking work scheduling from combination
of idle/delayed tasks to ordinary short-running tasks and moves
more marking work from V8.Execute to tasks by accounting how much
bytes were marked in tasks.
BUG=chromium:616434
LOG=NO
Review-Url: https://codereview.chromium.org/2321553002
Cr-Commit-Position: refs/heads/master@{#39348}
Now callers of Heap::CollectGarbage* functions need to
specify the reason as an enum value instead of a string.
Subsequent CL will add stats counter for GC reason.
BUG=
Review-Url: https://codereview.chromium.org/2310143002
Cr-Commit-Position: refs/heads/master@{#39239}
This patch
- extracts the logic of keeping track of allocated bytes
from the actual incremental marking step.
- replaces OldSpaceStep with a check for incremental marking start.
- removes the force_marking parameter of AdvanceIncrementalMarking.
BUG=chromium:616434
LOG=NO
Review-Url: https://codereview.chromium.org/2304123003
Cr-Commit-Position: refs/heads/master@{#39213}
This way we avoid the cyclic dependency between objects.h and heap.h and still
have one definition. Add a static assert that this size is indeed smaller than
the payload of a page.
Follow ups can finally remove the dependency on spaces.h for all heap.h users.
R=ulan@chromium.org,bmeurer@chromium.org,vogelheim@chromium.og
Review-Url: https://codereview.chromium.org/2311203002
Cr-Commit-Position: refs/heads/master@{#39206}
Replace first page size in the snapshots with a heap logic that trims pages
after deserialization. The snapshot provided page sizes was just an
approximation, while the heap knows exactly where to trim.
Furthermore, trim the pages directly after deserialization, leaving no wiggle
room for further objects. This avoids pollution of the immortal immovable pages
with regular objects, e.g. Contexts. The downside is that we potentially require
expanding the space with a new page.
BUG=chromium:636331
Review-Url: https://codereview.chromium.org/2311963002
Cr-Commit-Position: refs/heads/master@{#39200}
Rebuilding (after touching certain files) is crazy slow because
includes are out of control. Many of these files we need to rebuild are
cctests which pull in more includes than they need.
BUG=v8:5294
Review-Url: https://codereview.chromium.org/2304553002
Cr-Commit-Position: refs/heads/master@{#39080}
Reason for revert:
Tanks pretty much alle metrics across the board. Probably LO space limit too low but needs investigation.
Original issue's description:
> [heap] Switch to 500k pages
>
> Decrease regular heap object size to 400k. In a follow up, we can now get rid of
> the new space border page while keeping the 1M minimum new space size.
>
> This reverts commit 1617043c10.
>
> BUG=chromium:636331
>
> Committed: https://crrev.com/2101e691caeef656eb91f1c98620b3955d337c83
> Cr-Commit-Position: refs/heads/master@{#38916}
TBR=ulan@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:636331
NOPRESUBMIT=true
Review-Url: https://codereview.chromium.org/2289493002
Cr-Commit-Position: refs/heads/master@{#38960}
Decrease regular heap object size to 400k. In a follow up, we can now get rid of
the new space border page while keeping the 1M minimum new space size.
This reverts commit 1617043c10.
BUG=chromium:636331
Review-Url: https://codereview.chromium.org/2278653003
Cr-Commit-Position: refs/heads/master@{#38916}
Before this patch all tracing scopes in incremental marking would be reset
during a gc tracer start/stop cycle. This patch handles scopes the same way it
does other incremental marking metrics.
Also:
- Align finalization metric with regular marking metric.
- Smaller cleanups
BUG=chromium:639818
Review-Url: https://codereview.chromium.org/2273673002
Cr-Commit-Position: refs/heads/master@{#38834}
Before this patch all tracing scopes in incremental marking would be reset
during a gc tracer start/stop cycle. This patch handles scopes the same way it
does other incremental marking metrics.
Also:
- Align finalization metric with regular marking metric.
- Smaller cleanups
BUG=chromium:639818
R=jochen@chromium.org
Review-Url: https://codereview.chromium.org/2264033002
Cr-Commit-Position: refs/heads/master@{#38822}
Reason for revert:
Tanks octane
Original issue's description:
> [heap] Improve size profiling for ArrayBuffer tracking
>
> Eagerly account for retained sizes during ArrayBuffer tracking. Following up on this,
> we can now do Scavenges if the amount of memory retained from new space is too large.
>
> BUG=chromium:621829
> R=jochen@chromium.org,hpayer@chromium.org
>
> Committed: https://crrev.com/28e13bd6a75c9467dae43043e7b741a1387d5252
> Cr-Commit-Position: refs/heads/master@{#38731}
TBR=jochen@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:621829
Review-Url: https://codereview.chromium.org/2261513003
Cr-Commit-Position: refs/heads/master@{#38739}
Eagerly account for retained sizes during ArrayBuffer tracking. Following up on this,
we can now do Scavenges if the amount of memory retained from new space is too large.
BUG=chromium:621829
R=jochen@chromium.org,hpayer@chromium.org
Review-Url: https://codereview.chromium.org/2210263002
Cr-Commit-Position: refs/heads/master@{#38731}
Slots in ConsString/SlicedString can point to an evacutaion candidate.
The MakeExternal function makes in-place conversion to external string.
After the conversion we can have a recorded slot containing an external
pointer. As long as the external pointer is aligned, this is not a
problem. We clear the recorded slots to fix verify-heap checks.
BUG=chromium:631969
LOG=NO
Finalizing CL: https://codereview.chromium.org/2199863002/
Review-Url: https://codereview.chromium.org/2242183003
Cr-Commit-Position: refs/heads/master@{#38653}
Decrease regular heap object size to 400k. In a follow up, we can now get rid of
the new space border page while keeping the 1M minimum new space size.
BUG=chromium:636331
This reverts commit 555c961990.
Review-Url: https://codereview.chromium.org/2232653003
Cr-Commit-Position: refs/heads/master@{#38608}
Previously, we would both instrument the code, and add/remove
BreakPointInfo objects through BreakLocation. This is bad design and
unsuitable for having two different code kinds.
We would now add/remove BreakPointInfo objects, and use that as source
of truth when instrumenting the code. If we have both bytecode and FCG
code, we would simply apply these break points twice to either.
Notable changes:
- Removed many functionality from BreakLocation.
- Instrumentation (patching code for breaks) happens by applying break
point info onto code.
- Instrumentation (code patching) is done by the BreakIterator. For
bytecode, it's BytecodeArrayBreakIterator. For FCG code, it's
CodeBreakIterator.
- Changes to code instrumentation mostly involves clearing current
instrumentation and then (re-)applying break points.
- DebugInfo can now reference both bytecode and FCG code.
R=jgruber@chromium.org, mstarzinger@chromium.org
BUG=v8:5265
Review-Url: https://codereview.chromium.org/2238893002
Cr-Commit-Position: refs/heads/master@{#38596}
Reason for revert:
Failures on waterfall:
e.g. http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11134
Original issue's description:
> [heap] Switch to 500k pages
>
> - Decrease regular heap object size to 300k, keeping the same ration (60%)
> between this limit and page size.
>
> In a follow up, we can now get rid of the new space border page while
> keeping the 1M minimum new space size.
>
> Some results (v8.infinite_scroll; 3 runs):
> - evacuate.avg: +15.3% (1.4->1.2)
> - evacuate.max: +24.4% (2.4->1.8)
>
> BUG=chromium:581412
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org, yangguo@chromium.org
>
> Committed: https://crrev.com/ffe5c670e1559d11e7b252e15fec38765e7dbe4f
> Cr-Commit-Position: refs/heads/master@{#38533}
TBR=hpayer@chromium.org,ulan@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:581412
Review-Url: https://codereview.chromium.org/2229403003
Cr-Commit-Position: refs/heads/master@{#38537}
- Decrease regular heap object size to 300k, keeping the same ration (60%)
between this limit and page size.
In a follow up, we can now get rid of the new space border page while
keeping the 1M minimum new space size.
Some results (v8.infinite_scroll; 3 runs):
- evacuate.avg: +15.3% (1.4->1.2)
- evacuate.max: +24.4% (2.4->1.8)
BUG=chromium:581412
LOG=N
R=hpayer@chromium.org, ulan@chromium.org, yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2013713003
Cr-Commit-Position: refs/heads/master@{#38533}
This CL introduces a new fast flat instantiations cache for the first 1024 object templates.
After that we fall back to the existing slower dictionary cache.
Drive-by-fix: de-handlify and clean up some code in api-natives.cc
BUG=chromium:630217
Review-Url: https://codereview.chromium.org/2170743003
Cr-Commit-Position: refs/heads/master@{#38146}
Reason for revert:
Still crashing.
Original issue's description:
> [heap] Reland "Remove black pages and use black areas instead."
>
> BUG=chromium:630969,chromium:630386
> LOG=n
>
> Committed: https://crrev.com/9e37a07c8de0a20ef2681e26824ff4d329102603
> Cr-Commit-Position: refs/heads/master@{#38057}
TBR=ulan@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:630969,chromium:630386
Review-Url: https://codereview.chromium.org/2183383004
Cr-Commit-Position: refs/heads/master@{#38129}
