This avoids the appearence of a leak due to storing a JSObject
as the microtask_state in the strong root list, and allows callers
to call Isolate::RunMicrotasks() without having any v8::Context
available (as at least Blink has interest in doing).
The queue is now a strong root, represented as a FixedArray of JSFunctions
(or empty_fixed_array, if it's empty); it doubles in size when it needs to grow.
The number of elements in the queue is stored in Isolate::pending_microtask_count().
LOG=Y
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/290633010
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21356 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Traditionally, we cross compile a snapshot iff the serializer is enabled.
This will change in the future.
Changes:
- CpuFeatures probing is done once per process, depending on whether we
cross compile.
- CpuFeatures are consolidated into the platform-independent assembler.h
as much as possible.
- FLAG_enable_<feature> will only be checked at probing time (already the
case for ARM).
- The serializer state is cached by the MacroAssembler.
- PlatformFeatureScope is no longer necessary.
- CPUFeature enum values no longer map to CPUID bit fields.
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/285233010
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21347 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In some places, we pretended that there can be multiple arguments, though in
practice there was only one. In other places (most importantly, PreParser), we
only handled one argument. (This means that we were not able to produce a
multi-argument error inside a lazy function anyway.)
This CL makes it clear that there is ever only one argument.
R=ulan@chromium.org
BUG=
Review URL: https://codereview.chromium.org/273653002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21324 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- W-sized values passed to Printf are now handled correctly by the
simulator. In AAPCS64, int32_t and int64_t are passed in the same
way, so this didn't affect non-simulator builds.
- Since Printf now records the type and size of each argument, it is
possible to mix argument types.
- It is now possible to print the stack pointer. There is only one
remaining restriction: The `csp` register cannot be printed unless
it is the current stack pointer. This is because it is modified by
BumpSystemStackPointer when the caller-saved registers are
preserved.
BUG=
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/268353005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21272 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Even although the Arm64 specification specifies that csp
only needs to be aligned to 16 bytes if it is dereferenced, some
implementations show poor performance.
Also makes the following change:
- Enable CPU support for arm64 to enable probing of cpu implementer and cpu part.
- Add ALWAYS_ALIGN_CSP CpuFeature for Arm64 and set it based on runtime probing of the cpu imp
- Rename PrepareForPush and PrepareForPop to PushPreamble and PopPostamble and move PopPostabl
Original Review URL: https://codereview.chromium.org/264773004R=ulan@chromium.org
Review URL: https://codereview.chromium.org/271543004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21221 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
r21177 added extra AssertStackConsistency() checks which
increased code size on debug and caused the assembler buffer
to be too large. Increased some of these buffers to
compensate.
Also, ProfileEntryHoolStub could use the wrong number of
instructions for kProfileEntryHookCallSize depending upon
whether debug code was being emitted or ALWAYS_ALIGN_CSP was
enabled. Fixed this by taking ALWAYS_ALIGN_CSP into account
and ensuring that no debug code is emitted during
MaybeCallEntryHook().
TBR=ulan@chromium.org
Review URL: https://codereview.chromium.org/263213008
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Removing it seems to be a clear win on mobile: producing symbol data makes cold
parsing 20-30% slower, and having symbol data doesn't make warm parsing any
faster.
Notes:
- V8 used to produce symbol data, but because of a bug, it was never used until
recently. (See fix https://codereview.chromium.org/172753002 which takes the
symbol data into use again.)
- On desktop, warm parsing is faster if we have symbol data, and producing it
during cold parsing doesn't make parsing substantially slower. However, this
doesn't seem to be the case on mobile.
- The preparse data (cached data) will now contain only the positions of the
lazy functions.
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/261273003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21146 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Due to overlapping names of natives and runtime functions, the wrong
context was used for Notifier.prototype.performChange. The leak test
has been augmented to properly cover the leaky case, and the test
now passes.
Also tightened up type checks in runtime.cc and removed Object.observe
functions from knownIssues in fuzz-natives-part2.js.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/264793015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21129 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch reverts r21062 which disabled Object.observe and the relevant tests.
It also adds enforcement for the following three invariants:
1) No observer may receive a change record describing changes to an object which is in different security origin (context have differing security tokens)
2) No observer may receive a change record whose context's security token is different from that of the object described by the change.
3) Object.getNotifier will return null if the caller and the provided object are in differing security origins
Further, it ensures that the global object can never be observed nor a notifier retrieved for it.
Tests are included.
R=verwaest@chromium.org, rossberg
LOG=Y
Review URL: https://codereview.chromium.org/265503002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21122 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r20919 (aa51355)
Original commit message:
This is a purely mechanical change, adding an Isolate* to the CodeStub
constructor and a corresponding field plus a getter. A few methods in
CodeStub and its subclasses can be simplified now, but this is done in
a separate CL.
The underlying reason apart from simplicity is that deep down in the
call chain we need to detect if the serializer is active or not. This
information will be part of the Isolate, not a global variable with
funky synchronization primitives around it (which is fundamentally
wrong and the underlying cause for race conditions and a catch-22
during initialization).
BUG=359977
LOG=y
R=plind44@gmail.com
Review URL: https://codereview.chromium.org/252383005
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a purely mechanical change, adding an Isolate* to the CodeStub
constructor and a corresponding field plus a getter. A few methods in
CodeStub and its subclasses can be simplified now, but this is done in
a separate CL.
The underlying reason apart from simplicity is that deep down in the
call chain we need to detect if the serializer is active or not. This
information will be part of the Isolate, not a global variable with
funky synchronization primitives around it (which is fundamentally
wrong and the underlying cause for race conditions and a catch-22
during initialization).
BUG=359977
LOG=y
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/246643014
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20919 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793, 2323
LOG=Y
R=adamk@chromium.orgTBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/238063009
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20857 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This implements MapIterator and SetIterator which matches
the same constructs in the ES6 spec. However, these 2
iterators are not exposed to user code yet. They are only
used internally to implement Map.prototype.forEach and
Set.prototype.forEach.
Each iterator has a reference to the OrderedHashTable where
it directly accesses the hash table's entries.
The OrderedHashTable has a reference to the newest iterator
and each iterator has a reference to the next and previous
iterator, effectively creating a double linked list.
When the OrderedHashTable is mutated (or replaced) all the
iterators are updated.
When the iterator iterates passed the end of the data table
it closes itself. Closed iterators no longer have a
reference to the OrderedHashTable and they are removed from
the double linked list. In the case of Map/Set forEach, we
manually call Close on the iterator in case an exception was
thrown so that the iterator never reached the end.
At this point the OrderedHashTable keeps all the non finished
iterators alive but since the only thing we currently expose
is forEach there are no unfinished iterators outside a forEach
call. Once we expose the iterators to user code we will need
to make the references from the OrderedHashTable to the
iterators weak and have some mechanism to close an iterator
when it is garbage collected.
BUG=1793,2323
LOG=Y
TBR=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/240323003
Patch from Erik Arvidsson <arv@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
