Adds MarkAsReadOnly and MarkAsReadWrite to ReadOnlySpace. The latter
is only usable with ReadOnlySpace::WritableScope to avoid the space
being left writable). MarkAsReadOnly updates the high water mark and
makes several previously mutating methods into no-ops.
Moves some writes to immutable objects out of the bootstrapper to
setup-heap-internal so they don't write to a read-only page.
Also avoid writing hashes to strings that already have the value set as
that invariably means writing to the "0" and "1" constant strings in
RO_SPACE.
Before serialization, it makes RO_SPACE writable again so that any
padding can be cleared before writing it.
Bug: v8:7464
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I22edc20dba7dde8943991a8fcaf87244af4490a3
Reviewed-on: https://chromium-review.googlesource.com/1014128
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52943}
This moves the link from a {WasmInstanceObject} to its corresponding
{WasmModuleObject} into the right place and also makes it strong. This
ensures that an instance always keeps the underlying module alive and
hence removes the situation of an "orphaned instance".
R=clemensh@chromium.org
Change-Id: Id59f6a49740af8ef0248679c3d2c696bb9776944
Reviewed-on: https://chromium-review.googlesource.com/1041691
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52942}
Now that wasm-linkage.h is split off, we can easily implement
{MoveToReturnRegister} in platform independent code.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I072a0ee48d58ed29e0df489016f838915c3f2cb2
Reviewed-on: https://chromium-review.googlesource.com/1041690
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52939}
This CL changes how TypedArray.p.sort is implemented in Torque, mainly
to address the binary memory size of the builtin.
With this CL the memory comes down from 53611 to 4215 (as reported
by --print-builtin-size on a x64.release build).
With the following performance impact
on the relevant benchmarks:
Benchmark Original (JS) Torque (initial) This CL
IntTypes 83.9 263.7 202.3
BigIntTypes 32.1 54.6 47.2
FloatTypes 99.3 138.7 109.3
This is achieved by pushing the Load/Store dispatch based on
the elements kind into separate builtins that are executed
for each load/store. This results in only one version of the
sorting algorithm instead of one version per elements kind.
R=jgruber@chromium.org
Bug: chromium:837282
Change-Id: I7fe2da3cbfd01531d070128126a0d56d3dd6bdcc
Reviewed-on: https://chromium-review.googlesource.com/1033744
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52937}
With the exception of the InterpreterEntryTrampoline, all builtins are
now isolate-independent and can be embedded into the binary.
This CL updates the corresponding list and also contains a few smallish
tweaks to support having these builtins off the heap:
* wasm: copy the off-heap builtin, not its trampoline.
* Code::contains: support off-heap builtins.
* JSFunction::is_compiled: compare builtin index instead of identity
(this is relevant during mksnapshot when we transition from the
on-heap builtin to its off-heap representation + the trampoline).
* Remove old DCHECKs.
* A few tweaks in macro-assembler ports that have snuck in recently.
Bug: v8:6666
Change-Id: Iabf5b47ade3826a4da35b6b75a4e61614f0158b0
Reviewed-on: https://chromium-review.googlesource.com/1032777
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52935}
Add an include of stdlib.h for the abort function. Compilation fails
on FreeBSD without it. See Node.js issue:
https://github.com/nodejs/node-v8/issues/56
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I67ac21fdc9bc1072d5aaf4f7180dcf4000a938c9
Reviewed-on: https://chromium-review.googlesource.com/1039705
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michaël Zasso <mic.besace@gmail.com>
Cr-Commit-Position: refs/heads/master@{#52934}
If there is more then one agent accepts current pause, we should resume
only when last agent is disabled.
R=dgozman@chromium.org
Bug: chromium:834056
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I2904b3f4ab76117511e16450dd575ebf3e20a068
Reviewed-on: https://chromium-review.googlesource.com/1041207
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52931}
SetPermissions causes memory that was previously reserved but uncommitted to be
committed. This could put us over the committed memory limit for the process,
causing SetPermissions to fail. In this case, we should report this as an out of
memory error rather than a crash.
Bug: chromium:838880
Change-Id: I2785aa9f5608fa04196fee2b280e0c6df2f56ca8
Reviewed-on: https://chromium-review.googlesource.com/1040657
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52928}
The tracker needs to maintain the byte length as there is no order guarantee
when sweeping pages and the byte length may be a HeapNumber that is stored on a
different page.
The abstraction for ArrayBuffers is left untouched. We distinguish between the
following cases:
1. Regular AB (backing_store and bye_length should be used)
2. AB allocated using kReservation but not part of wasm
3. AB allocated using kReservation and part of wasm
In practice, 2. does not exist, but we still maintain "allocation_base" and
"allocation_length" which fall back to backing_store and byte_length in this
case. The problematic part is that they look like innocent getters on the
object but actually refer to different data structures or on-heap objects.
Since 2. does not exist, and 3. looks up the bounds in its own tracker, it is
fine for ArrayBufferTracker to pass backing_store and tracked byte_length.
Bug: v8:7701
Change-Id: Ib89d5fe94fce5cef8e5d8343a5415a3b9ad0deba
Reviewed-on: https://chromium-review.googlesource.com/1039385
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52923}
This is a reland of ad221d144a
Original change's description:
> [wasm] Always enable guard regions on 64-bit platforms
>
> This change makes full 8 GiB guard regions always enabled on 64-bit
> platforms.
>
> Additionally, since all Wasm memory allocation paths have some form of
> guard regions, this removes and simplifies most of the logic around
> whether to enable guard regions.
>
> This is a reland of https://crrev.com/c/985142.
>
> Bug: v8:7619
> Change-Id: I8bf1f86d6f89fd0bb2144431c7628f15a6b00ba0
> Reviewed-on: https://chromium-review.googlesource.com/996466
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52412}
Bug: v8:7619
Change-Id: I0f311305472ca2305ad2fa9163560ff54c1422c2
Reviewed-on: https://chromium-review.googlesource.com/999872
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52921}
These DCHECKs involve reading and comparing two variables that may be modified
on a separate thread. Thus, there is no way to ensure these comparisons happen
atomically. This leads to runtime failures that are otherwise benign.
The other option would be to take the memory tracker mutex, but this seems
unnecessary given that two atomic counters is sufficient and these checks are
only used during debug builds.
Bug: chromium:838043
Change-Id: I1b87698c46c550bd2d58bfef956b5a07cb2ec52c
Reviewed-on: https://chromium-review.googlesource.com/1038886
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52920}
This reverts commit 2df5e7a7b6.
Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
Original change's description:
> [parser] Slice the source string where possible
>
> When internalizing string literals (for quoted strings or property names),
> try to create a sliced string of the source string rather than allocating
> a copy of the bytes.
>
> This will not work for string literals that contain escapes (e.g. unicode
> escapes), and currently does not support two-byte strings.
>
> Bug: chromium:818642
> Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
> Reviewed-on: https://chromium-review.googlesource.com/1010282
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52898}
TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1039885
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52919}
test-serialize/SerializationMemoryStats does not actually create a new
Isolate from scratch. Instead, it deserializes from the snapshot and
we can simply piggy-back off existing output to measure
deserialization time.
Bug: v8:6666,v8:7693
Change-Id: I8f709ea834ff7f5e46f7ebfa9b0c35d96095bf26
Reviewed-on: https://chromium-review.googlesource.com/1039585
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52918}
The first element of a given iterable argument can be a hole. Thus,
normalize the first element so that we can correctly format the
exception message with "undefined" for a hole element, instead of "NaN".
Bug: v8:7715
Change-Id: I62edd09e361ebeebab642bb82db29b73a2c7b193
Reviewed-on: https://chromium-review.googlesource.com/1038951
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52917}
Original CL: https://crrev.com/c/1018468
During code generation, we generate self-references (i.e. references to
the Code object currently being generated) as references to a temporary
handle. When the final Code object has been allocated, the handle's
location is fixed up and RelocInfo iteration fixes up all references
embedded in the generated code.
This adds support for this mechanism to the builtins constants table
builder. CodeObject() is now a new handle pointing to a dedicated
self-reference marker in order to distinguish between self-references
and references to undefined. In Factory::NewCode, we patch up
the constants table.
TBR=yangguo@chromium.org,mlippautz@chromium.org
Bug: v8:6666
Change-Id: I3fa422c57de99c9851dc7a86394a8387c7c2b397
Reviewed-on: https://chromium-review.googlesource.com/1039366
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52916}
We incorrectly used a TurboFan typer check for {0,10,undefined} on the
radix argument on Number.parseInt, which was internally widened to the
checking whether radix is in range 0-10 or undefined. This CL introduces
two separate checks.
Bug: chromium:838766
Change-Id: I5ebfc1c82bad5b9794b4f844e79e4df01f541a83
Reviewed-on: https://chromium-review.googlesource.com/1039197
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52914}
This fixes a bug where we didn't run before/after hooks for await when
the debugger is not active, as reported downstream in
https://github.com/nodejs/node/issues/20274
Change-Id: I1948d1884c591418d87ffd1d0ccb2bebf4e908f1
Reviewed-on: https://chromium-review.googlesource.com/1039386
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52909}
If we add new properties by assigning JSFunction values, properties
array was not changed into a dictionary map.
Bug: v8:7461
Change-Id: Ie16f974502d0ba362e3650a409c27cdc5856a373
Reviewed-on: https://chromium-review.googlesource.com/1028110
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52907}
In order to keep track of where the return address is stored in each block, the
UnwindingInfoWriter needs to know if a block exits the current function.
However, we would only mark returns and tail-calls as exists, while we also have
kArchDebugAbort, kArchThrowTerminator and kArchDeoptimize. This would lead to
assertions when generating the snapshot in debug mode with
`v8_perf_prof_unwinding_info = true`.
Bug: v8:7660
Change-Id: Iee2ab222251f6922dd21442e12cbb6b56534bf54
Reviewed-on: https://chromium-review.googlesource.com/1019504
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#52906}
This is a leftover of the time where the memory size was stored as
64 bit value. Now it is stored as 32 bit value, so no need to truncate.
R=ahaas@chromium.org
Change-Id: I44a1505ebd564aee53e4c9a7168738fcb855264b
Reviewed-on: https://chromium-review.googlesource.com/1034883
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52905}
This CL also adds types to a user and three builtins that make use
of CreateArrayIterator.
R=petermarshall@chromium.org
Bug: v8:7570
Change-Id: I96b647a9a57e825db717b40ecec2340b0a3d367d
Reviewed-on: https://chromium-review.googlesource.com/1032779
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52904}
In b49206ded9 I changed thread_data_table_ and thread_data_table_mutex_ from
static members to regular class member variables. To do this, I only deleted
the `static` keyword and left the declarations where they were. This was a
little odd in that all of the dynamic class members are declared together in
one place, but now these two new members weren't next to the rest. Making it
a little bit weirder is the fact that these two new members actually ended up
being the first members of the class, since the exsiting dynamic members were
declared later.
This change merely moves these two members down to the end of the dynamic
member variable list, where they probably should have gone.
Bug: chromium:837477
Change-Id: If993935cc56c8026bb7331493ed657c42ba06ac7
Reviewed-on: https://chromium-review.googlesource.com/1036478
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52902}
On s390, size_t is defined to be long unsigned int, while Address is unsigned
int. Therefore, GCC is complaining conflicting types for parameter 'T'
('long unsigned int' and 'unsigned int') for the Min function.
R=ofrobots@google.com, hpayer@chromium.org, mstarzinger@chromium.org, mlippautz@chromium.org
Change-Id: Ib04edebad24da694ccd06ff572ee50d3db7f87ff
Reviewed-on: https://chromium-review.googlesource.com/1035542
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#52900}
When internalizing string literals (for quoted strings or property names),
try to create a sliced string of the source string rather than allocating
a copy of the bytes.
This will not work for string literals that contain escapes (e.g. unicode
escapes), and currently does not support two-byte strings.
Bug: chromium:818642
Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
Reviewed-on: https://chromium-review.googlesource.com/1010282
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52898}
