* 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}
I tried to limit the use of v8::Isolate::GetCurrent() and v8::internal::Isolate::Current() as much as possible, but sometimes this would have involved restructuring tests quite a bit, which is better left for a separate CL.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12716010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13953 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
1) While marking the backing hash table of a WeakMap we also need to
record the slot because it might be on an evacuation candidate.
2) With incremental marking one backing hash table might be marked more
than once because the WeakMap might have gone through a white to gray
transition.
3) The corner case when the allocation of the backing hash table itself
causes a GC, leads to a WeakMap with an undefined table field, so we
still need to handle this case correctly.
R=vegorov@chromium.org
TEST=mjsunit/harmony/proxies-example-membrane --stress-compaction
Review URL: https://chromiumcodereview.appspot.com/9985010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11385 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes processing of WeakMaps so that value entries on an evacuation
candidate are correctly recorded in the slots buffer. We didn't pass the
correct slot into the backing hashtable while visiting values.
Also the live bytes counter for large object space pages was not reset
correctly when incremental marking is aborted.
R=vegorov@chromium.org
BUG=v8:2060
TEST=cctest/test-weakmaps/Regress2060
Review URL: https://chromiumcodereview.appspot.com/10034010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11264 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
