- 07 Sep, 2020 1 commit
-
-
Marcel Laverdet authored
The BigInt constructor has quadratic complexity while parsing strings, and the input is unbounded. Interrupts should be checked during this operation to ensure the embedder has control over runaway execution. since the implicit cast from string may now throw. BigInt: :CompareToString and BigInt::EqualToString now return Maybe<..> Change-Id: Iccb85fafac4df69075a34d1de647cb4f0184cb12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2392629Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#69720}
-
- 26 Aug, 2020 1 commit
-
-
Clemens Backes authored
The fuzzers were calling the compiled function without passing explicit arguments. Thus all arguments were converted from the "undefined" value, which typically results in a zero value, as expected. For BigInt though, it's not allowed to pass "undefined". We have to pass a proper BigInt. This CL implements this by passing explicit parameter values for all parameters. This effectively unlocks testing BigInt parameters in all fuzzers, thus may increase coverage and find new bugs. R=ahaas@chromium.org Bug: chromium:1120355 Change-Id: I4e451d2418eb73d460fa937d1cf95a1ab6c99cf5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377945 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69570}
-
- 20 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Squash a couple of remaining places where compilation finalization was allocating new-space objects. Bug: chromium:1011762 Change-Id: Ie0462eed422016f860146724a06dd2f1963bd88e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110019 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66807}
-
- 02 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and make the OffThreadIsolate allocate "real" Handles. Rather than using the main-thread Isolate's handle scopes, these off-thread Handles are backed by a Zone, which is tied to the lifetime of the nearest OffThreadHandleScope. Eventually, we'll likely want to merge the implementation of OffThreadHandleScope and HandleScope, but currently the latter is too tightly coupled to the main thread to do so. Bug: chromium:1011762 Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66516}
-
- 04 Feb, 2020 1 commit
-
-
Leszek Swirski authored
This CL templatizes some methods in BigInt on the Isolate type, to allow BigInts to be allocated off-thread from a BigInt literal. A necessary side-effect is exporting the Isolate class in its entirety, to allow it to be used as a specializing type for ' HandleFor' in unittests. Bug: chromium:1011762 Change-Id: I768f9e4d46a4532d6818d9a67c13801bc5952e5d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036079 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66105}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 28 Oct, 2019 1 commit
-
-
Seth Brenith authored
This change begins making use of the fact that Torque now knows about the relationship between classes and instance types, to replace a few repetitive lists: - Instance type checkers (single and range), defined in src/objects/instance-type.h - Verification dispatch in src/diagnostics/objects-debug.cc - Printer dispatch in src/diagnostics/objects-printer.cc - Postmortem object type detection in tools/debug_helper/get-object-properties.cc Torque is updated to generate four macro lists for the instance types, representing all of the classes separated in two dimensions: classes that correspond to a single instance type versus those that have a range, and classes that are fully defined in Torque (with fields and methods inside '{}') versus those that are only declared. The latter distinction is useful because fully-defined classes are guaranteed to correspond to real C++ classes, whereas only-declared classes are not. A few other changes were required to make the lists above work: - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does and avoid conflicts with the new macro-generated IsFiller method. This is the part I'm most worried about: I think the new name is an improvement for clarity and consistency, but I could imagine someone typing IsFiller out of habit and introducing a bug. If we'd prefer to keep the name IsFiller, my other idea is to rename FreeSpace to VariableSizeFiller and Filler to FixedSizeFiller. - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE. - Normalized the dispatched behavior for BigIntBase and HeapNumber. - Added a few new object printers. Bug: v8:7793 Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#64597}
-
- 11 Oct, 2019 1 commit
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
-
- 11 Sep, 2019 1 commit
-
-
Victor Gomes authored
From verwaest@ work on the Json's parser, we know that removing the allocation type argument when creating objects using the factory class increases performance. This will also allow us to optimise these functions in a latter CL. Change-Id: If78f62a63fe41453f4def8bea77b6eddc2ab7f36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792168Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@google.com> Cr-Commit-Position: refs/heads/master@{#63670}
-
- 05 Aug, 2019 1 commit
-
-
Clemens Hammacher authored
Instead of exposing a {kNext} constant to be used to construct the next bitfield, expose a templatized {Next} type alias. This ensures that the storage type is the same for all bitfields created this way. It's also shorter. Apart from the expected changes in the code base, the AST node classes are changed to expose a {NextBitField} templated type alias instead of a {kNextBitFieldIndex} constant. They thus follow the same pattern as {BitField} itself. R=jkummerow@chromium.org, mstarzinger@chromium.org, verwaest@chromium.org Bug: v8:9396 Change-Id: I70a1b0bd71cde694ec53444de0ca55e4cf0a3836 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728615Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63068}
-
- 29 Jul, 2019 3 commits
-
-
Clemens Hammacher authored
This is a reland of 658ff200 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} Bug: v8:9396, v8:7629 Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62959}
-
Clemens Hammacher authored
This reverts commit 658ff200. Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} TBR=yangguo@chromium.org,clemensh@chromium.org Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396, v8:7629 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62958}
-
Clemens Hammacher authored
We have hundreds of classes that derive from {BitField} without adding any functionality. This CL switches all such occurrences to 'using' declarations instead. Before: class MyBitField : public BitField<int, 6, 4, MyEnum> {}; After: using MyBitField = BitField<int, 6, 4, MyEnum>; This might reduce compilation time by reducing the number of existing classes. The old pattern is forbidden now by making {BitField} final. R=yangguo@chromium.org Bug: v8:9396, v8:7629 Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62956}
-
- 12 Jul, 2019 1 commit
-
-
Nico Hartmann authored
The code generated for ChangeUint64ToBigInt in the EffectControlLinearizer did not initialize the optional padding field of newly allocated BigInts. This padding field is present on 64 bit builds without pointer compression enabled. This CL fixes this by 0-filling the padding field if present. Bug: v8:9407 Change-Id: I511e163e676dc966a3eb6dfb92b5065e36329225 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695464Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62683}
-
- 07 Jun, 2019 1 commit
-
-
Nico Hartmann authored
Implements the addition of BigInts as a Torque builtin, which performs necessary checks and then calls into C++. The core logic of MutableBigInt::AbsoluteAdd, MutableBigInt::AbsoluteSub and MutableBigInt::AbsoluteCompare is now used by both the runtime and the Torque generated builtin for best performance. Bug: v8:9213 Change-Id: I5f6af4dd226f11e6287bd04272ccae6ee5c26498 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1640211Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@google.com> Cr-Commit-Position: refs/heads/master@{#62049}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 2 commits
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
Yang Guo authored
TBR=bmeurer@chromium.org,leszeks@chromium.org Bug: v8:9247 Change-Id: I8d14d0192ea8c705f8274e8e61a162531826edb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624220Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#61769}
-
- 21 May, 2019 1 commit
-
-
Sigurd Schneider authored
Change-Id: I377e96fca2dff89a986b43f092ef7684d164cd9d Bug: v8:9264 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617679 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61695}
-
- 04 Apr, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: I1b9f3c0c805709c6570785ec9f1045f21c9d03e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541048Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60638}
-
- 29 Mar, 2019 1 commit
-
-
Clemens Hammacher authored
Even though both are allowed in the style guide, it recommends to use 'using', as its syntax is more consistent with the rest of C++. This CL turns all typedefs in src/objects to 'using' declarations. R=mstarzinger@chromium.org Bug: v8:8834 Change-Id: Iec455b40e9256ee3aae867a42c0e949a338d417c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545893Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60531}
-
- 19 Mar, 2019 1 commit
-
-
Igor Sheludko authored
When pointer compression is enabled the [u]intptr_t and double fields are only kTaggedSize aligned so in order to avoid undefined behavior in C++ code we have to access these values in an unaligned pointer friendly way although both x64 and arm64 architectures (where pointer compression is supported) allow unaligned access. These changes will be removed once v8:8875 is fixed and all the kSystemPointerSize fields are properly aligned. Bug: v8:7703 Change-Id: I4df477cbdeab806303bb4f675d52b61c06342c8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1528996 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#60321}
-
- 12 Mar, 2019 1 commit
-
-
Hannes Payer authored
Bug: v8:8945 Change-Id: I14ca4b29f1b12ff95e718d431f65d88ab1238c53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511478Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#60177}
-
- 13 Feb, 2019 1 commit
-
-
Toon Verwaest authored
We should just always get an Object in rather than both Object and Object* where the former is dealt with through operator->. Change-Id: I2d2542f37a357d4c410cc5f07c8e3563e66660b7 Reviewed-on: https://chromium-review.googlesource.com/c/1470104Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59553}
-
- 24 Jan, 2019 1 commit
-
-
Frank Tang authored
Bug: v8:8704 Change-Id: Ib0548a6aa9f4b148d412de5632c1652f529371fa Reviewed-on: https://chromium-review.googlesource.com/c/1424021 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#59050}
-
- 09 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The incremental migration required several pairs of functionally equivalent macros. This patch consolidates everything onto the respective new version and drops the obsolete versions. Bug: v8:3770 Change-Id: I4fb05ff223e8250c83a13f46840810b0893f410b Reviewed-on: https://chromium-review.googlesource.com/c/1398223Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58659}
-
- 08 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The two names refer to the same thing by now, so this patch is entirely mechanical. Bug: v8:3770 Change-Id: Ia360c06c89af6b3da27fd21bbcaeb2bdaa28ce22 Reviewed-on: https://chromium-review.googlesource.com/c/1397705Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58615}
-
- 26 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Tbr: ahaas@chromium.org,leszeks@chromium.org,verwaest@chromium.org Bug: v8:3770 Change-Id: Ia6530fbb70dac05e9972283781c3550d8b50e1eb Reviewed-on: https://chromium-review.googlesource.com/c/1390116 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58470}
-
- 20 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Merging the temporary HeapObjectPtr back into HeapObject. Bug: v8:3770 Change-Id: I5bcd23ca2f5ba862cf5b52955dca143e531c637b Reviewed-on: https://chromium-review.googlesource.com/c/1386492 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58410}
-
- 19 Dec, 2018 1 commit
-
-
Igor Sheludko authored
Also added != 0 for readability in checks like: if (FIELD_SIZE(kFooOffset) != 0) {...} Bug: v8:8477, v8:8562 Change-Id: Ibc305103475e6ec029e89e7ad095ec0a1fa30189 Reviewed-on: https://chromium-review.googlesource.com/c/1382743 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#58360}
-
- 03 Dec, 2018 1 commit
-
-
Igor Sheludko authored
broken by: [cleanup] Fix kPointerSize usages in src/objects/bigint.* Bug: v8:8477, v8:8238 Change-Id: If1961ae42e1969d4ee807ea052a9c4cf4f072d0f Reviewed-on: https://chromium-review.googlesource.com/c/1357046 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#57997}
-
- 30 Nov, 2018 2 commits
-
-
Jakob Kummerow authored
Taking kSystemPointerSize into account when determining the maximum allowed BigInt size accidentally made the limit platform-specific. This patch chooses a platform-independent constant (1<<30) instead. Bug: chromium:909614 Change-Id: I4717969bc56e6dd5f1eed70b7e60e621989d0719 Reviewed-on: https://chromium-review.googlesource.com/c/1355625 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#57983}
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I6ad84a663926fffc9e1acc590c13780c39461274 Reviewed-on: https://chromium-review.googlesource.com/c/1351248 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#57952}
-
- 28 Nov, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:8477, v8:8238 Change-Id: Ice11af2becb3b88a884c9231ed9610210efcc4d6 Reviewed-on: https://chromium-review.googlesource.com/c/1352292Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57916}
-
- 16 Nov, 2018 1 commit
-
-
Georg Neis authored
GC needs to be able to read a bigint's length while the main thread may change the length and the sign (bigints are intentionally mutable as long as they haven't escaped to user code). Since both values are stored in the same bitfield, we need to make these accesses atomic. Also change right-trimming to not insert a filler when the object is in large object space (it makes no sense there). Bug: v8:8440 Change-Id: I72a1b6f1eda54566d3cfad554dda1a98ddd61975 Reviewed-on: https://chromium-review.googlesource.com/c/1337737 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#57576}
-
- 20 Sep, 2018 1 commit
-
-
Yang Guo authored
We now clearly differentiate between: - unseeded hash for 32-bit integers - unseeded hash for 64-bit integers - seeded hash for 32-bit integers - seeded hash for strings R=bmeurer@chromium.org Bug: chromium:680662 Change-Id: I7459958c4158ee3501c962943dff8f33258bb5ce Reviewed-on: https://chromium-review.googlesource.com/1235973 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56068}
-
- 29 Aug, 2018 1 commit
-
-
Jakob Kummerow authored
On 32-bit platforms, String::kMaxLength is such that not all BigInts can be converted to Strings. NoSideEffectsToString, however, used to assume that this conversion always succeeds. This patch adds a check for the failure case, and returns "<a very large BigInt>" instead of crashing. This change is practically unobservable, because actually formatting such a huge BigInt to String would take "forever", which is also why there is no regression test. Bug: chromium:876628 Change-Id: I1eacdc1cce753ac5d9ca66e61e479043ab576e07 Reviewed-on: https://chromium-review.googlesource.com/1194004Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#55491}
-
- 12 Jul, 2018 1 commit
-
-
Marja Hölttä authored
api.h: MAKE_TO_LOCAL funcs need the types to be available. scope.h, func-name-inferrer.h, bigint.h, module.h: These were using inline headers -> de-inlined. BUG=v8:7754,v8:7490 Change-Id: Id072f537682fb867cd68d79ca95b06628780d01f Reviewed-on: https://chromium-review.googlesource.com/1131175 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54414}
-
- 02 Jul, 2018 1 commit
-
-
Anna Henningsen authored
Provide a more complete BigInt API. Bug: v8:7712 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ic8562d616f3125deabdf8b52c7019b191bef0e07 Reviewed-on: https://chromium-review.googlesource.com/1101198 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#54122}
-
- 20 Jun, 2018 1 commit
-
-
Leszek Swirski authored
Bug: v8:7786 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: If9904fe8feb9b4e157d42d6e84f1aa263abcc8b7 Reviewed-on: https://chromium-review.googlesource.com/1106160 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#53882}
-