- 04 Aug, 2021 3 commits
-
-
Benedikt Meurer authored
For inline scripts that have a `// #sourceURL=foo.js` annotation, the V8 inspector (and by extension `Error.stack`) currently operates in terms of the `foo.js`, i.e. doesn't give any hint about the actual source, except for the line/column offsets reported upon scriptParsed. However in case of stack frames (i.e. as part of `Error.stack` or as part of the call frames reported via CDP), the line/column offsets are relative to the actual source instead of relative to the `foo.js` part, which - besides other things - makes post-processing of recorded stack traces tricky (sometimes impossible). This change adjusts the source positions reported for (inline) scripts with sourceURL annotations to be relative to the (inline) script instead of the surrounding document. Bug: chromium:1183990 Fixed: chromium:578269 Change-Id: I74f2b93c22ec43ca796b6b51faa9df5b99cf03f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069289 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#76097}
-
Jakob Gruber authored
The field is immutable after initialization and thus should be set non-atomically on the main thread, and read non-atomically on the background thread. But TSAN support for generated code turns all field accesses into relaxed atomic accesses, leading to this race detection. Silence it by making the read relaxed as well. Bug: chromium:1236302,v8:7790 Change-Id: I47979b2dbf61a65a9e92453324fe2b255fafd30d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070700 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#76080}
-
Mythri A authored
Add support to flush only baseline code. FLAG_flush_baseline_code controls if baseline code is flushed or not and FLAG_flush_bytecode controls if bytecode is flushed or not. With this CL it is possible to control if we want to flush only bytecode / only baseline code / both. This also lets us have different heuristics for bytecode and baseline code flushing. Bug: v8:11947 Change-Id: Ibdfb9d8be7e7d54196db7890541fa0b5d84f037e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060481Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#76075}
-
- 03 Aug, 2021 3 commits
-
-
Thibaud Michaud authored
Also introduce a separate error type for WebAssembly.Exception, since the properties should not be added to RuntimeError. R=jkummerow@chromium.org Bug: v8:11992 Change-Id: I8f4ae0da9a95184366e07dc43e58a5a9ff4382ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055304Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#76061}
-
Jakob Gruber authored
Based on a CL by mvstanton@. Bug: v8:7790,v8:12030,v8:12031,v8:12041 Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#76055}
-
Frank Tang authored
This is a temp fix to throw instead of DCHECK in debug build. The correct fix depends on the landing of https://github.com/unicode-org/icu/pull/1762 Once that land I will cherrypick into chrome to fix the function correctly. But the current (before this CL) behavior is not harmful in release build. It basically does not do the max nor min just return itself. Bug: chromium:1224869 Change-Id: Iebce2ab0a5ce047e83e8fce05db8290212e64509 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017300Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#76047}
-
- 02 Aug, 2021 3 commits
-
-
Frank Tang authored
ICU 69 moved content of nb resources to no and let nb fallback to no. This break our original design of checking locale availability. Hard wire to check on no if nb fail for now until we come out with a better fix. Bug: chromium:1215606 Change-Id: I831529d29590cc643ee0109fb2ce8948dac75613 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068010 Commit-Queue: Frank Tang <ftang@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#76044}
-
Camillo Bruni authored
- Add V8_WARN_UNUSED_RESULT to TryCopyAndConvertArrayToCppBuffer methods - Remove --force-slow-path implications in Object::IterationHasObservableEffects Bug: v8:11739 Change-Id: I20dcac1c460c6ee116ff372806cdf8764a99d9f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3063504Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#76037}
-
Jakob Kummerow authored
Regressed in crrev.com/152ecad8. Fixed: chromium:1234931 Change-Id: I8f2b603a914fccaeaeb3dcffa63070cf8fb6f0e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3064604 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76033}
-
- 30 Jul, 2021 2 commits
-
-
Jakob Kummerow authored
No changes to the algorithm, approximately 4x performance improvement thanks to reduced overhead. Bug: v8:11515 Change-Id: Id3f6c91bd650f6ae47ac8f169dc780420091998e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3046185 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#76022}
-
Paolo Severini authored
Rename CopyAndConvertArrayToCppBuffer as TryCopyAndConvertArrayToCppBuffer and implement type specialization for int32_t and double in order to speed up V8 bindings with sequences. This API is used by Blink code, for example see https://chromium-review.googlesource.com/c/chromium/src/+/3027405. Bug: v8:11739 Change-Id: I026a7f5e7833fb1afcc2ea9c296b66c7f733cbb1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3036407 Commit-Queue: Paolo Severini <paolosev@microsoft.com> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#76016}
-
- 29 Jul, 2021 4 commits
-
-
Mythri A authored
Introduce a flush_baseline_code flag to control if baseline code is flushed or not. Currently flush_baseline_code implies flush_bytecode as well. So if flush_baseline_code is enabled both bytecode and baseline code are flushed. If the flag is disabled we only flush bytecode and not baseline code. In a follow-up CL we will add support to control baseline and bytecode flushing independently i.e. we can flush only bytecode / only baseline code / both. Bug: v8:11947 Change-Id: I5a90ed38469de64ed1d736d1eaaeabc2985f0783 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059684 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#76003}
-
Thibaud Michaud authored
The JS API constructor was renamed to "WebAssembly.Tag" to match the spec: https://github.com/WebAssembly/exception-handling/issues/159 Rename "exception" to "tag" throughout the codebase for consistency with the JS API, and to match the spec terminology (e.g. "tag section"). R=clemensb@chromium.org,nicohartmann@chromium.org Bug: v8:11992 Change-Id: I63f9f3101abfeefd49117461bd59c594ca5dab70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053583Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75994}
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: Ib3ae55349024ebeab9ceaf9472a6de2b4d86ce55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056975Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#75993}
-
Marja Hölttä authored
This will change the behavior of %TypedArray%.prototype.fill. Bug: v8:11111 Change-Id: I66e7d3decf07663a6497c3c86374b3c77ab6a682 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056977Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#75988}
-
- 28 Jul, 2021 1 commit
-
-
Jakob Gruber authored
ComputeMinObjectSlack is called concurrently from background threads (when --concurrent-inlining) and must therefore be thread-safe. This CL adds a compiler-specific thread-safe variant of ComputeMinObjectSlack in addition to the plain old non-thread-safe one. Thread-safety is achieved through locking: on the bg thread, a shared lock when traversing transitions, and on the main thread, an additional exclusive critical section when overwriting prototype transitions. Tbr: leszeks@chromium.org Bug: v8:7790,v8:12010,chromium:1231901 Change-Id: If5af83df1ab896b22477921449fb5ba4c8d3e8a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045342 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#75949}
-
- 27 Jul, 2021 1 commit
-
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: I09e918a3f8c50e10691c8ab4718b7c4ae9184000 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055303 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#75946}
-
- 26 Jul, 2021 4 commits
-
-
Leszek Swirski authored
IsCompiledScope should check for BaselineData before BytecodeArray, since the former implies the latter. Bug: v8:11420 Change-Id: I6c659a5f97180b478fb3401f55a095b6d307b80f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3054117 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75924}
-
Leszek Swirski authored
This is a reland of e24fa913 It fixes the heap verification errors by going back to using MakeThin instead of manually creating a filler (that then makes the verifier think that this was array left-trimming). Original change's description: > [offthread] Template deserializer on Isolate > > Make the deserializer class templated on Isolate/LocalIsolate. This > allows the ObjectSerializer to be split into a main-thread and offthread > variant, with the latter taking a LocalIsolate. > > Eventually, we probably want to anyway split off the code-cache de/serializer > to a separate implementation (for various reasons), and this the only one that > wants off-thread finalization, and at this point the deserializer can revert > back to being un-templated, used only for bootstrapping. However, this is the > simplest way, for now, to enable off-thread deserialization. > > Bug: chromium:1075999 > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75834} Bug: chromium:1075999 Change-Id: I1d81fad2550a2a9f04dd0f9d8e66422d28faf378 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043960Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75918}
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: I7ff82d1699701dfa38af1da447f0b40a2a2c97b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053586Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#75914}
-
Mythri A authored
With baseline code flushing we also need to hold baseline data in IsCompiledScope. IsCompiledScope is used in places where we don't want bytecode / baseline code to be flushed. Change-Id: I692cdc5fc433dedeabcfc412d9f96d76148ddbe3 BUG: v8:12009 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3048172 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75903}
-
- 23 Jul, 2021 3 commits
-
-
Vicky Kontoura authored
This CL adds support for classes with methods. More specifically: - A new ValueSerializer is added and classes are serialized separetely from functions, although the common parts are handled in the same way and abstracted away. - The function prototype is serialized as an object and any missing information is set up again during deserialization. - FunctionFlagsToFunctionKinds() is updated to allow for more function kinds. - Context serialization is updated to support serializing BlockContexts and creating ScopeInfos of type CLASS_SCOPE. - Map serialization is updated to support properties with custom attributes. Bug: v8:11525, v8:11706 Change-Id: I16ca7cbc17b1811721081cda05124ce36073f9be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3006416 Commit-Queue: Vicky Kontoura <vkont@google.com> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#75893}
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: I41a318d3858e48035ae67e937420e2963a13d871 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035091 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#75878}
-
Dan Elphick authored
Replaces includes of v8.h with more fine-grained includes and moves the deoptimizer.h include to the places that actually need it. Bug: v8:11879 Change-Id: Ifc2e89caf455ddcf559fdb449d0fed7ad0d046d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045706Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75873}
-
- 22 Jul, 2021 3 commits
-
-
Camillo Bruni authored
* Avoid accessing thread_local_top directly and use getters: - scheduled_exception - pending_exception - pending_message * Rename pending_message_obj to pending_message Bug: chromium:1014421 Change-Id: I080b7d5919e180a943776c79ee9321235d58d3c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010278Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#75864}
-
Jakob Kummerow authored
...while on-heap objects are referring to it. This is accomplished by storing a reference to its associated WasmInstanceObject on every WasmTypeInfo object. Details: https://bit.ly/2UxD4hW Fixed: v8:11953 Change-Id: Ifb6f976142356021393d41c50717d210d525d521 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043959 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#75863}
-
Shu-yu Guo authored
RegExp match indices have shipped since M90 Bug: v8:9548 Change-Id: I8bf54ce1a50b5079aad71140f75c979a09aae5bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042842 Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75848}
-
- 21 Jul, 2021 3 commits
-
-
Seth Brenith authored
Since most Torque-defined extern classes use @generateCppClass, it makes more sense to instead annotate the small number that don't. This is part of the cleanup work that Nico recommended in [1]. Classes that still have to opt out: - Those that can be converted by https://crrev.com/c/3015666 - HeapObject: sort of special since it's the root of the inheritance hierarchy. Generated code would include two declarations that don't compile until HeapObject is defined: bool IsHeapObject_NonInline(HeapObject o); explicit TorqueGeneratedHeapObject( Address ptr, HeapObject::AllowInlineSmiStorage allow_smi); - SmallOrdered*: these classes use templates on the C++ side, which is not currently representable in Torque. - SwissNameDictionary: according to a comment, the Torque generation for this class is incorrect. I haven't investigated further. Drive-by fix: make the Torque formatter keep LF on Windows rather than writing CRLF. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I1fbb5290f0c645842b84c53816c09bb3398206a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3028721Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75841}
-
Nico Hartmann authored
This reverts commit e24fa913. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/18917/overview Original change's description: > [offthread] Template deserializer on Isolate > > Make the deserializer class templated on Isolate/LocalIsolate. This > allows the ObjectSerializer to be split into a main-thread and offthread > variant, with the latter taking a LocalIsolate. > > Eventually, we probably want to anyway split off the code-cache de/serializer > to a separate implementation (for various reasons), and this the only one that > wants off-thread finalization, and at this point the deserializer can revert > back to being un-templated, used only for bootstrapping. However, this is the > simplest way, for now, to enable off-thread deserialization. > > Bug: chromium:1075999 > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75834} Bug: chromium:1075999 Change-Id: Id699ebe0c17d3a61ec35b0f78417306175271647 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041675Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#75836}
-
Leszek Swirski authored
Make the deserializer class templated on Isolate/LocalIsolate. This allows the ObjectSerializer to be split into a main-thread and offthread variant, with the latter taking a LocalIsolate. Eventually, we probably want to anyway split off the code-cache de/serializer to a separate implementation (for various reasons), and this the only one that wants off-thread finalization, and at this point the deserializer can revert back to being un-templated, used only for bootstrapping. However, this is the simplest way, for now, to enable off-thread deserialization. Bug: chromium:1075999 Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75834}
-
- 20 Jul, 2021 5 commits
-
-
Igor Sheludko authored
... which will update both the CodeObjectSlot contents and the cached value of the code entry point when the pointed Code object is evacuated. This is done by introducing an OLD_TO_CODE remembered set which is populated with the recorded slots containing pointers to Code objects. CodeDataContainer is the only kind of holder that can contain Code pointers, so having a CodeObjectSlot is enough to compute the holder CodeDataContainer object and update the cached code entry point there. This CL fixes the data race in the previous implementation which were updating the code entry point during Code object migration. Bug: v8:11880 Change-Id: I44aa46af4bad7eb4eaa922b6876d5f2f836e0791 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035084 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75826}
-
Seth Brenith authored
Most Torque-defined extern classes already use @generateCppClass. As Nico pointed out in [1], it would be nice to convert the remaining classes and remove this option. This change converts most of those remaining classes. I know that the future of Torque-defined classes is a subject of some debate right now, but I think that it's worth doing a few mechanical changes to reduce the existing variety of options. Changes that don't exactly follow the usual pattern: 1. BigIntBase, MutableBigInt: we can define these without a body, and then Torque treats them as "really external" rather than "kind of external, but with some Torque-generated parts". 2. RegExpMatchInfo: moved its inline functions into a separate file, which the generated -tq.cc file requires. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I84c7958a295caa0bab847683c05022e18c921cad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027742Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75817}
-
Mythri A authored
This is a reland of ea55438a. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
-
Peter Kasting authored
Bug: chromium:1066980 Change-Id: I5c5e34b970a3b7a87abbec23110588518e99f6af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3036345 Auto-Submit: Peter Kasting <pkasting@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#75806}
-
Marja Hölttä authored
- Remove ResizableArrayBuffer / GrowableSharedArrayBuffer constructors, use options bags - Add AB.prototype.resizable and SAB.prototype.growable - Update receiver checks in (S?)AB.prototype methods Previous try: https://chromium-review.googlesource.com/c/v8/v8/+/3021174 Bug: v8:11111 Change-Id: Ib4e98aa987826fd01bfdcf7688310ec0665f33ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035770 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#75803}
-
- 19 Jul, 2021 5 commits
-
-
Seth Brenith authored
I've noticed a few places where class fields as defined in Torque have different names than the corresponding accessors in the C++ class. I think they should match. Most of this change is just mechanically updating the various places that use k##Field##Offset for those fields. Change-Id: I8ba52aed7f6a1cd6b2d71158f71150b66c2c0da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027263 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75796}
-
Jakob Gruber authored
This wraps up the transition away from kSerialized ref kinds. Since JSFunctionRef is a complex type, we don't attempt full consistency on the background thread. Instead, we serialize functions on the background in a partially-racy manner, in which consistency between different JSFunction fields is *not* guaranteed. Consistency is later verified through a new compilation dependency kind during finalization. Bug: v8:7790, v8:12004 Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75789}
-
Igor Sheludko authored
... for visiting slots containing pointers to Code objects when external code space mode is enabled. These slots will require different handling once the code space is moved out of the V8 heap cage. This CL also introduces IsValidCodeObject() predicate similar to IsValidHeapObject() for checking if given HeapObject is a valid Code object. Tbr: cbruni@chromium.org Bug: v8:11880 Change-Id: I430940f4503cebfd2a6d387e44349810991a93e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032085Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75787}
-
Mythri A authored
This is in preparation for baseline code flushing. After a deopt we choose to execute baseline or bytecode based on whether SharedFunctionInfo has any baseline code. With baseline code flushing, it is possible that baseline code is flushed after this point and before we start executing the unoptimized code (for ex: materializing objects). To handle such situations this CL updates the BaselineEnterAt* builtins to check for baseline code and restart either at baseline / bytecode. Bug: v8:11947 Change-Id: I2084e38196c882f802d1186ff8c9ab881a35b16b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3030711 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75783}
-
Marja Hölttä authored
This reverts commit 6207d61f. Reason for revert: Incorrect implementation of the flag-not-on case. Original change's description: > [rab/gsab] Update to the new spec > > - Remove ResizableArrayBuffer / GrowableSharedArrayBuffer constructors, > use options bags > - Add AB.prototype.resizable and SAB.prototype.growable > - Update receiver checks in (S?)AB.prototype methods > > Bug: v8:11111 > Change-Id: I4f8cb71a4c8e07483a3ffad83d98129da162b839 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3021174 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Commit-Queue: Marja Hölttä <marja@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75761} Bug: v8:11111, chromium:1230129, chromium:1230408 No-Try: True Tbr: mlippautz@chromium.org Change-Id: I25aa10cb3dc20fdaeb45e6169fc01eec9a89f72c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038061Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75778}
-