Skip to content

V
V8
Switch branch/tag
  1. 19 Jun, 2019 3 commits
  3. 18 Jun, 2019 35 commits
  5. 17 Jun, 2019 2 commits
    • Igor Sheludko's avatar
      Fix TSAN build broken by poor rebasing · a58bbd5e
      Igor Sheludko authored 
      ... in b9591a58
and then in 595813c6.

Tbr: verwaest@chromium.org
Change-Id: I0336cc5729532e23597aaab6966dfa602f84bc73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662575Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62229}
      a58bbd5e
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 2 · 15ea19db
      Seth Brenith authored 
      This change removes the special case in the Torque compiler for types
that descend from JSObject: they will no longer get implicit
"| Undefined" appended to their types for verification purposes. It
removes any additional custom verification steps in objects-debug that
are made redundant by that change.

In order to do so safely, I categorized all cases where we were
implicitly adding "| Undefined" to the field type, as follows:

1. Classes that aren't using the generated verifier function (we should
   probably revisit these, but for now we at least know they're safe):
   - JSGlobalObject
   - JSFinalizationGroup
   - JSFinalizationGroupCleanupIterator

2. Classes where the existing verifier is already at least as strict as
   what we would get after removing the implicit "| Undefined":
   - JSDate
   - JSPromise
   - JSRegExp
   - JSRegExpStringIterator
   - WasmMemoryObject
   - JSWeakRef
   - JSStringIterator
   - WasmExceptionObject
   - JSListFormat (fixed in part 1)
   - JSPluralRules (fixed in part 1)
   - JSRelativeTimeFormat (fixed in part 1)
   - JSSegmenter (fixed in part 1)
   - JSArrayBufferView (fixed in part 1)
   - JSTypedArray (fixed in part 1)

3. Classes where, to the best of my knowledge based on code inspection,
   we already initialize the object correctly to pass the new stricter
   generated verifier:
   - JSFunction
   - JSArrayIterator
   - JSMessageObject
   - JSBoundFunction
   - JSAsyncFromSyncIterator
   - WasmModuleObject
   - JSAsyncFunctionObject

4. Classes that needed some adjustment to their initialization order to
   avoid exposing uninitialized state to the GC:
   - JSArray (only in Factory::NewJSArray; Runtime_NewArray and
              CodeStubAssembler::AllocateJSArray already behave fine)
   - WasmTableObject
   - JSDateTimeFormat
   - JSNumberFormat
   - JSCollator
   - JSV8BreakIterator
   - JSLocale
   - JSSegmentIterator
   - JSModuleNamespace

5. Classes that had incorrect type definitions in Torque:
   - WasmGlobalObject (category 4 after correction)

6. Classes that weren't fully initialized due to bugs:
   - JSGeneratorObject
   - JSAsyncGeneratorObject

Bug: v8:9311
Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62228}
      15ea19db