The tests illustrate the use of v8::EmbedderHeapTracer.
Bug: v8:7176
Change-Id: Ic383c968691fddb0ec96d66cb33ee42b9c304a75
Reviewed-on: https://chromium-review.googlesource.com/811924
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49934}
There's three common situations in which we need to create JSFunction
objects. 1) from the compiler, 2) from tests, and 3) everything else
(mostly during bootstrapping).
This is an attempt to simplify case 3), which previously relied on
several Factory::NewFunction overloads where it was not clear how the
semantics of each overload differed.
This CL removes all but one overload, and packs arguments into a new
NewFunctionArgs helper class.
It also removes the hacks around
SFI::set_lazy_deserialization_builtin_id by explicitly passing
builtin_id into Factory::NewSharedFunctionInfo.
Drive-by-fix: Properly set is_constructor hint in
SimpleCreateSharedFunctionInfo.
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ica94d95e72e443055db5e7ff9e8cdf4115201ef1
Reviewed-on: https://chromium-review.googlesource.com/757094
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49224}
In the current implementation of hash code for objects (identity hash),
we do not bother to shift the hash when we retrieve it from the
hash-length bitfield in a property array. (Even worse, we store shifted
value even if we do not have property array or inside dictionaries.)
That means that the hash-code for objects is always divisible by 1024.
Since our hash table uses a simple masking with (2^logsize - 1) to
obtain the bucket, we get terrible hash collisions - essentially, our
hash table degenerates to a linked list for fewer than 1024 elements.
This CL always shifts the hash code so that the value in the lowest
21 bits is uniformly distributed.
This results in big improvements on medium to large hash tables.
A program storing 1M elements into a WeakMap gets roughly
17x faster. A program retrieving 1M elements from a Map
improves even more dramatically (>100x).
const a = [];
for (let i = 0; i < 1e6; i++) a[i] = {};
const m = new Map();
console.time("Map.set");
for (let i = 0; i < 1e6; i++) {
m.set(a[i], i);
}
console.timeEnd("Map.set");
console.time("Map.get");
let s = 0;
for (let i = 0; i < 1e6; i++) {
s += m.get(a[i]);
}
console.timeEnd("Map.get");
const w = new WeakMap();
console.time("WeakMap.set");
for (let i = 0; i < 1e6; i++) {
w.set(a[i], i);
}
console.timeEnd("WeakMap.set");
Before the fix:
Map.set: 157.575000
Map.get: 28333.182000
WeakMap.set: 6923.826000
After the fix:
Map.set: 178.382000
Map.get: 185.930000
WeakMap.set: 409.529000
Note that Map does not suffer from the hash collision on insertion because
it uses chaining (insertion into linked list is fast regardless of size!), and
we cleverly avoid lookup in the hash table on update if the key does not have
identity hash yet. This is in contrast to the WeakMap, which uses
open-addressing, and deals with collisions on insertion.
Bug: v8:6916
Change-Id: Ic5497bd4501e3b767b3f4acb7efb4784cbb3a2e4
Reviewed-on: https://chromium-review.googlesource.com/713616
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48480}
By adding a per test source file namespace, we can avoid a lot of
symbol collisions in jumbo builds.
While we're at it, let's remove some "using" statements that also
cause trouble.
Bug: chromium:746958
Change-Id: I6f8a723e1ba5905888638e0687b23193f3f012ca
Reviewed-on: https://chromium-review.googlesource.com/676803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48102}
There's no need for these to be static.
Bug: v8:5717
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia704cdcb9ee9666c7724b78d58c56217cd5876ae
Reviewed-on: https://chromium-review.googlesource.com/624869
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47490}
This no longer causes allocation, so it's safe to unhandlify.
This will allow us to use directly call into C++ (via CallCFunction)
to calculate the hash instead of going through the runtime (via
%GenericHash).
Bug: v8:5717
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia561efb4d89d7a3d10c28913537b45b3ce477bb3
Reviewed-on: https://chromium-review.googlesource.com/624519
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47489}
* Avoid "using namespace" statements, which trigger clang's -Wheader-hygiene
warnings in jumbo builds.
* Undefine created macros at the end of source files.
BUG=chromium:746958
Change-Id: I5d25432c314437f607b0e1be22765a6764267ba6
Reviewed-on: https://chromium-review.googlesource.com/610962
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#47347}
This reverts commit 8196e10265.
Reason for revert: Performance regression due to hashcode lookup.
Original change's description:
> [builtins] Move most WeakMap/WeakSet code from JS to C++ builtins
>
> They were already implemented mostly in C++ (only error/negative
> cases were handled in script), so this is mostly just a cleanup.
> Only the constructors remain in script after this CL.
>
> Bug: v8:6354
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
> Reviewed-on: https://chromium-review.googlesource.com/531670
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45924}
TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org
Bug: v8:6354, chromium:733238
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia5a741b9587886298f3ca057f6a6adeba556b8e0
Reviewed-on: https://chromium-review.googlesource.com/537207
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45966}
They were already implemented mostly in C++ (only error/negative
cases were handled in script), so this is mostly just a cleanup.
Only the constructors remain in script after this CL.
Bug: v8:6354
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
Reviewed-on: https://chromium-review.googlesource.com/531670
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45924}
Most callers passed kFinalizeIncrementalMarkingMask, so use that as
a default argument (not using default argument syntax to avoid including
heap.h in cctest.h).
Change-Id: I904f1eb3a0f5fdbe63eab16f6a6f01d04618645d
Reviewed-on: https://chromium-review.googlesource.com/488104
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44950}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
Adds the marking logic to mark the young generation.
BUG=chromium:651354
Review-Url: https://codereview.chromium.org/2498583002
Cr-Commit-Position: refs/heads/master@{#41104}
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}
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}
- Move usable functions into proper heap-utils.h/.cc files and remove
utils-inl.h file
- Fix assumptions accross the board relying on certain behavior that is not
invariant
This is a requirement for modifying page size.
BUG=chromium:581412
LOG=N
R=ulan@chromium.org
Review-Url: https://codereview.chromium.org/1999753002
Cr-Commit-Position: refs/heads/master@{#36410}
Preparing the young generation for (real) non-contiguous backing memory, this
change removes object masks that are used to compute containment in semi and new
space. The masks are replaced by lookups for object tags and page headers, where
possible.
Details:
- Use the fast checks (page header lookups) for containment in regular code.
- Use the slow version that masks out the page start adress and iterates all
pages of a space for debugging/verification.
- The slow version works for off-heap/unmapped memory.
- Encapsulate all checks for the old->new barrier in Heap::RecordWrite().
BUG=chromium:581412
LOG=N
Review URL: https://codereview.chromium.org/1632913003
Cr-Commit-Position: refs/heads/master@{#33857}
The test expectations should fail consistently in both release and debug
builds. DCHECK is only meant for debug-only checks in production code.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1506753002
Cr-Commit-Position: refs/heads/master@{#32639}
Reason for revert:
Breaks http://build.chromium.org/p/client.v8/builders/V8%20Arm%20-%20debug%20-%202/builds/2372
Original issue's description:
> [heap] GC flag cleanup/restructuring.
>
> * GC's flags are now proper flags and not int.
> * Callback flags are not threaded through but only set once like gc flags
> * Callers of methods that trigger GCs need to pass a reason when not using
> the default parameters.
>
> Furthermore, each GC invocation can be passed the GC and GCCallback flags. We
> usually override the currently set flags upon finishing a GC cylce, but are able
> to restore the previously set if desired. This is useful for explicitely
> triggered scavenges or external requests that interrupt the current behaviour.
>
> BUG=
>
> Committed: https://crrev.com/f4f3b431b9ce0778d926acf03c0d36dae5c0cba4
> Cr-Commit-Position: refs/heads/master@{#30457}
TBR=hpayer@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1303393004
Cr-Commit-Position: refs/heads/master@{#30463}
* GC's flags are now proper flags and not int.
* Callback flags are not threaded through but only set once like gc flags
* Callers of methods that trigger GCs need to pass a reason when not using
the default parameters.
Furthermore, each GC invocation can be passed the GC and GCCallback flags. We
usually override the currently set flags upon finishing a GC cylce, but are able
to restore the previously set if desired. This is useful for explicitely
triggered scavenges or external requests that interrupt the current behaviour.
BUG=
Review URL: https://codereview.chromium.org/1314863003
Cr-Commit-Position: refs/heads/master@{#30457}
When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1163803002
Cr-Commit-Position: refs/heads/master@{#28742}
* Hash code is now just done with a private own symbol instead of the hidden string, which predates symbols.
* In the long run we should do all hidden properties this way and get rid of the
hidden magic 0-length string with the zero hash code. The advantages include
less complexity and being able to do things from JS in a natural way.
* Initially, the performance of weak set regressed, because it's a little harder
to do the lookup in C++. Instead of heroics in C++ to make things faster I
moved some functionality into JS and got the performance back. JS is supposed to be good at looking up named properties on objects.
* This also changes hash codes of Smis so that they are always Smis.
Performance figures are in the comments to the code review. Summary: Most of js-perf-test/Collections is neutral. Set and Map with object keys are 40-50% better. WeakMap is -5% and WeakSet is +9%. After the measurements, I fixed global proxies, which cost 1% on most tests and 5% on the weak ones :-(.
In the code review comments is a patch with an example of the heroics we could do in C++ to make lookup faster (I hope we don't have to do this. Instead of checking for the property, then doing a new lookup to insert it, we could do one lookup and handle the addition immediately). With the current benchmarks above this buys us nothing, but if we go back to doing more lookups in C++ instead of in stubs and JS then it's a win.
In a similar vein we could give the magic zero hash code to the hash code
symbol. Then when we look up the hash code we would sometimes see the table
with all the hidden properties. This dual use of the field for either the hash
code or the table with all hidden properties and the hash code is rather ugly,
and this CL gets rid of it. I'd be loath to bring it back. On the benchmarks quoted above it's slightly slower than moving the hash code lookup to JS like in this CL.
One worry is that the benchmark results above are more monomorphic than real
world code, so may be overstating the performance benefits of moving to JS. I
think this is part of a general issue we have with handling polymorphic code in
JS and any solutions there will benefit this solution, which boils down to
regular property access. Any improvement there will lift all boats.
R=adamk@chromium.org, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1149863005
Cr-Commit-Position: refs/heads/master@{#28622}
Add a finalize incremental marking mode for CollectAllGarbage to finalize incremental marking when incremental marking is in progress, but we want a full gc at a given CollectAllGarbage call site.
Default mode for CollectAllGarbage is finalize incremental marking and perform a full GC.
BUG=
Review URL: https://codereview.chromium.org/1082973003
Cr-Commit-Position: refs/heads/master@{#27831}
Contribution of PowerPC port (continuation of 422063005, 817143002,
866843003, and 901083004. The bulk of the changes are to remove some
hard coded assumptions about heap page size within existing tests.
The remaining change is to use a larger heap page size for PPC linux
as this provides a performance benefit due to the larger memory page size.
modified: src/base/build_config.h
modified: src/heap/heap.cc
modified: test/cctest/test-alloc.cc
modified: test/cctest/test-constantpool.cc
modified: test/cctest/test-heap.cc
modified: test/cctest/test-spaces.cc
modified: test/cctest/test-weakmaps.cc
modified: test/cctest/test-weaksets.cc
R=danno@chromium.org, svenpanne@chromium.org
BUG=
Review URL: https://codereview.chromium.org/910333004
Cr-Commit-Position: refs/heads/master@{#26833}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/900123003
Cr-Commit-Position: refs/heads/master@{#26451}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/891473005
Cr-Commit-Position: refs/heads/master@{#26425}
A new map wich references its keys weakly is added to v8.h. Internally it uses the same storage as JSWeakMap but doesn't depend on the JavaScript part of WeakMap implementation in weak-collection.js, hence it can be instantiated without entering any context.
BUG=chromium:437416
LOG=Y
Review URL: https://codereview.chromium.org/886473005
Cr-Commit-Position: refs/heads/master@{#26401}
Groups and implicit references are no longer relevant at this point.
Also add tests that fail if the first or second round of ephemeral
marking is omitted
BUG=none
R=mstarzinger@chromium.org,hpayer@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/761343004
Cr-Commit-Position: refs/heads/master@{#25606}
