Skip to content

Make -cdartkp -mdebug faster #32603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
mkustermann opened this issue Mar 20, 2018 · 2 comments
Closed

Make -cdartkp -mdebug faster #32603

mkustermann opened this issue Mar 20, 2018 · 2 comments
Assignees
@mkustermann
Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.

Comments

@mkustermann
Copy link
Member

Not only were the debug-kernel-precompilation test runs already slow, we have even made them slower in the last 3 months by over 40%.

/cc @athomas @mraleph @ErikCorryGoogle
@mkustermann mkustermann added the area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends. label Mar 20, 2018
@mkustermann
Copy link
Member Author

Since this is also hurting everyone doing AOT work on the VM, I'll try to make some simple optimizations.

@mkustermann mkustermann self-assigned this Mar 20, 2018
@mkustermann
Copy link
Member Author

Have uploaded cl/47222 for review.

@athomas athomas mentioned this issue Mar 21, 2018
Closed
4 tasks
dart-bot pushed a commit that referenced this issue Mar 21, 2018
@mkustermann
[VM] Optimize performance of dart_boostrap in debug-kernel-strong mode.
31dd668 
Since the kernel reading helpers have been extended to not only work
with a kernel blob in C heap, but also work based on a [TypedData]
buffer in the VM heap, access to the [TypedData] buffer is on the hot
path now.

This hot path is slowing things down considerably, in particular due
to NoSafepoingScope's.

This CL removes a critical NoSafepoingScope when accessing the
[TypedData] in read-only mode.  It also allows passing in the [Thread]
directly, to avoid TLS lookups.

Issue #32603

Change-Id: I91955bea5cd4eddbbd21c5d3bc6813504c2cece9
Reviewed-on: https://dart-review.googlesource.com/47222
Commit-Queue: Martin Kustermann <[email protected]>
Reviewed-by: Vyacheslav Egorov <[email protected]>
dart-bot pushed a commit that referenced this issue Apr 6, 2018
@mkustermann
[VM] Introduction of type testing stubs - Part 4
2c52480 
In order to avoid generating type testing stubs for too many types in
the system - and thereby potentially cause an increase in code size -
this change introduces a smarter way to decide for which types we should
generate optimized type testing stubs.

The precompiler creates a [TypeUsageInfo] which we use to collect
information.  More specifically:

   a) We collect the destination types for all type checks we emit
      (we do this inside AssertAssignableInstr::EmitNativeCode).

      -> These are types we might want to generate optimized type testing
         stubs for.

   b) We collect type argument vectors used in instance creations (we do
      this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
      of used type argument vectors for each class.

After the precompiler has finished compiling normal code we scan the set
of destination types collected in a) for uninstantiated types (or more
specifically, type parameter types).

We then propagate the type argument vectors used on object allocation sites,
which were collected in b), in order to find out what kind of types are flowing
into those type parameters.

This allows us to extend the set of types which we test against, by
adding the types that flow into type parameters.

We use this final augmented set of destination types as a "filter" when
making the decision whether to generate an optimized type testing stub
for a given type.

Issue #32603

Measured impact on flutter HEAD-HEAD-HEAD with TTS Part 1 - 4 applied (2018-04-03):

      * stock build benchmark: around 4% improvement
      * gallery app.so size: -2.68%  (13987348 -> 13612928)
      * gallery memory: no sigificant changes:
         - SubtypeTestCache: - 10kb
         - ObjectPool: + 6 kb
         - Type: no change (probably due to wasted alignment slot before)
         - TypeParameter: + 4 kb (can get rid of the field here later)
      * gallery AOT compile-time: measured +1.3%, inside flakiness range

Change-Id: I12a398d18f970ba2db741913bb47b0f36ae38d58
Reviewed-on: https://dart-review.googlesource.com/48640
Commit-Queue: Martin Kustermann <[email protected]>
Reviewed-by: Régis Crelier <[email protected]>
dart-bot pushed a commit that referenced this issue Apr 9, 2018
@mkustermann
Reland "[VM] Introduction of type testing stubs - Part 1-4"
8054409 
Relands 165c583

    [VM] Introduction of type testing stubs - Part 1

    This CL:

      * Adds a field to [RawAbstractType] which will always hold a pointer
        to the entrypoint of a type testing stub

      * Makes this new field be initialized to a default stub whenever a
        instances are created (e.g. via Type::New(), snapshot reader, ...)

      * Makes the clustered snapshotter write a reference to the
        corresponding [RawInstructions] object when writing the field and do
        the reverse when reading it.

      * Makes us call the type testing stub for performing assert-assignable
        checks.

    To reduce unnecessary loads on callsites, we store the entrypoint of the
    type testing stubs directly in the type objects.  This means that the
    caller of type testing stubs can simply branch there without populating
    a code object first.  This also means that the type testing stubs
    themselves have no access to a pool and we therefore also don't hold on
    to the [Code] object, only the [Instruction] object is necessary.

    The type testing stubs do not setup a frame themselves and also have no
    safepoint.  In the case when the type testing stubs could not determine
    a positive answer they will tail-call a general-purpose stub.

    The general-purpose stub sets up a stub frame, tries to consult a
    [SubtypeTestCache] and bails out to runtime if this was unsuccessful.

    This CL is just the the first, for ease of reviewing.  The actual
    type-specialized type testing stubs will be generated in later CLs.

    Reviewed-on: https://dart-review.googlesource.com/44787

Relands f226c22

    [VM] Introduction of type testing stubs - Part 2

    This CL starts building type testing stubs specialzed for [Type] objects
    we test against.

    More specifically, it adds support for:

      * Handling obvious fast cases on the call sites (while still having a
        call to stub for negative case)

      * Handling type tests against type parameters, by loading the value
        of the type parameter on the call sites and invoking it's type testing stub.

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subtype-checks.

        ==> e.g. String/List<dynamic>

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the type arguments.

        ==> e.g. Widget<State>, where we know [Widget] is only extended and not
                 implemented.

      * Specialzed type testing stubs for certain non-instantiated types where we
        can do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the instantiated type arguments and
        cid based comparisons for type parameters.  (Note that this fast-case migth
        result in some false-negatives!)

        ==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
                 extended and not implemented.

       This optimizes cases where the caller uses `new HashMap<A, B>()` and only
       uses `A` and `B` as key/values (and not subclasses of it).  The false-negative
       can occur when subtypes of A or B are used.  In such cases we fall back to the
       [SubtypeTestCache]-based imlementation.

    Reviewed-on: https://dart-review.googlesource.com/44788

Relands 25f98bc

    [VM] Introduction of type testing stubs - Part 3

    The changes include:

      * Make AssertAssignableInstr no longer have a call-summary, which
        helps methods with several parameter checks by not having to
        re-load/re-initialize type arguments registers

      * Lazily create SubtypeTestCaches: We already go to runtime to warm up
        the caches, so we now also create the caches on the first runtime
        call and patch the pool entries.

      * No longer load the destination name into a register: We only need
        the name when we throw an exception, so it is not on the hot path.
        Instead we let the runtime look at the call site, decoding a pool
        index from the instructions stream.  The destination name will be
        available in the pool, at a consecutive index to the subtype cache.

      * Remove the fall-through to N=1 case for probing subtypeing tests,
        since those will always be handled by the optimized stubs.

      * Do not generate optimized stubs for FutureOr<T> (so far it just
        falled-through to TTS).  We can make optimzed version of that later,
        but it requires special subtyping rules.

      * Local code quality improvement in the type-testing-stubs: Avoid
        extra jump at last case of cid-class-range checks.

    There are still a number of optimization opportunities we can do in
    future changes.

    Reviewed-on: https://dart-review.googlesource.com/46984

Relands 2c52480

    [VM] Introduction of type testing stubs - Part 4

    In order to avoid generating type testing stubs for too many types in
    the system - and thereby potentially cause an increase in code size -
    this change introduces a smarter way to decide for which types we should
    generate optimized type testing stubs.

    The precompiler creates a [TypeUsageInfo] which we use to collect
    information.  More specifically:

       a) We collect the destination types for all type checks we emit
          (we do this inside AssertAssignableInstr::EmitNativeCode).

          -> These are types we might want to generate optimized type testing
             stubs for.

       b) We collect type argument vectors used in instance creations (we do
          this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
          of used type argument vectors for each class.

    After the precompiler has finished compiling normal code we scan the set
    of destination types collected in a) for uninstantiated types (or more
    specifically, type parameter types).

    We then propagate the type argument vectors used on object allocation sites,
    which were collected in b), in order to find out what kind of types are flowing
    into those type parameters.

    This allows us to extend the set of types which we test against, by
    adding the types that flow into type parameters.

    We use this final augmented set of destination types as a "filter" when
    making the decision whether to generate an optimized type testing stub
    for a given type.

    Reviewed-on: https://dart-review.googlesource.com/48640

Issue #32603

Change-Id: I44a1d5d4b27454ae026aef2a301aada3dd399ea0
Reviewed-on: https://dart-review.googlesource.com/49861
Commit-Queue: Martin Kustermann <[email protected]>
Reviewed-by: Vyacheslav Egorov <[email protected]>
dart-bot pushed a commit that referenced this issue Apr 10, 2018
@mkustermann
Reland "[VM] Introduction of type testing stubs - Part 1-4"
34763bc 
Relands 165c583

    [VM] Introduction of type testing stubs - Part 1

    This CL:

      * Adds a field to [RawAbstractType] which will always hold a pointer
        to the entrypoint of a type testing stub

      * Makes this new field be initialized to a default stub whenever a
        instances are created (e.g. via Type::New(), snapshot reader, ...)

      * Makes the clustered snapshotter write a reference to the
        corresponding [RawInstructions] object when writing the field and do
        the reverse when reading it.

      * Makes us call the type testing stub for performing assert-assignable
        checks.

    To reduce unnecessary loads on callsites, we store the entrypoint of the
    type testing stubs directly in the type objects.  This means that the
    caller of type testing stubs can simply branch there without populating
    a code object first.  This also means that the type testing stubs
    themselves have no access to a pool and we therefore also don't hold on
    to the [Code] object, only the [Instruction] object is necessary.

    The type testing stubs do not setup a frame themselves and also have no
    safepoint.  In the case when the type testing stubs could not determine
    a positive answer they will tail-call a general-purpose stub.

    The general-purpose stub sets up a stub frame, tries to consult a
    [SubtypeTestCache] and bails out to runtime if this was unsuccessful.

    This CL is just the the first, for ease of reviewing.  The actual
    type-specialized type testing stubs will be generated in later CLs.

    Reviewed-on: https://dart-review.googlesource.com/44787

Relands f226c22

    [VM] Introduction of type testing stubs - Part 2

    This CL starts building type testing stubs specialzed for [Type] objects
    we test against.

    More specifically, it adds support for:

      * Handling obvious fast cases on the call sites (while still having a
        call to stub for negative case)

      * Handling type tests against type parameters, by loading the value
        of the type parameter on the call sites and invoking it's type testing stub.

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subtype-checks.

        ==> e.g. String/List<dynamic>

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the type arguments.

        ==> e.g. Widget<State>, where we know [Widget] is only extended and not
                 implemented.

      * Specialzed type testing stubs for certain non-instantiated types where we
        can do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the instantiated type arguments and
        cid based comparisons for type parameters.  (Note that this fast-case migth
        result in some false-negatives!)

        ==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
                 extended and not implemented.

       This optimizes cases where the caller uses `new HashMap<A, B>()` and only
       uses `A` and `B` as key/values (and not subclasses of it).  The false-negative
       can occur when subtypes of A or B are used.  In such cases we fall back to the
       [SubtypeTestCache]-based imlementation.

    Reviewed-on: https://dart-review.googlesource.com/44788

Relands 25f98bc

    [VM] Introduction of type testing stubs - Part 3

    The changes include:

      * Make AssertAssignableInstr no longer have a call-summary, which
        helps methods with several parameter checks by not having to
        re-load/re-initialize type arguments registers

      * Lazily create SubtypeTestCaches: We already go to runtime to warm up
        the caches, so we now also create the caches on the first runtime
        call and patch the pool entries.

      * No longer load the destination name into a register: We only need
        the name when we throw an exception, so it is not on the hot path.
        Instead we let the runtime look at the call site, decoding a pool
        index from the instructions stream.  The destination name will be
        available in the pool, at a consecutive index to the subtype cache.

      * Remove the fall-through to N=1 case for probing subtypeing tests,
        since those will always be handled by the optimized stubs.

      * Do not generate optimized stubs for FutureOr<T> (so far it just
        falled-through to TTS).  We can make optimzed version of that later,
        but it requires special subtyping rules.

      * Local code quality improvement in the type-testing-stubs: Avoid
        extra jump at last case of cid-class-range checks.

    There are still a number of optimization opportunities we can do in
    future changes.

    Reviewed-on: https://dart-review.googlesource.com/46984

Relands 2c52480

    [VM] Introduction of type testing stubs - Part 4

    In order to avoid generating type testing stubs for too many types in
    the system - and thereby potentially cause an increase in code size -
    this change introduces a smarter way to decide for which types we should
    generate optimized type testing stubs.

    The precompiler creates a [TypeUsageInfo] which we use to collect
    information.  More specifically:

       a) We collect the destination types for all type checks we emit
          (we do this inside AssertAssignableInstr::EmitNativeCode).

          -> These are types we might want to generate optimized type testing
             stubs for.

       b) We collect type argument vectors used in instance creations (we do
          this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
          of used type argument vectors for each class.

    After the precompiler has finished compiling normal code we scan the set
    of destination types collected in a) for uninstantiated types (or more
    specifically, type parameter types).

    We then propagate the type argument vectors used on object allocation sites,
    which were collected in b), in order to find out what kind of types are flowing
    into those type parameters.

    This allows us to extend the set of types which we test against, by
    adding the types that flow into type parameters.

    We use this final augmented set of destination types as a "filter" when
    making the decision whether to generate an optimized type testing stub
    for a given type.

    Reviewed-on: https://dart-review.googlesource.com/48640

Issue #32603

Change-Id: I6d33d4ca3d5187a1eb1664078c003061855f0160
Reviewed-on: https://dart-review.googlesource.com/50482
Reviewed-by: Vyacheslav Egorov <[email protected]>
Commit-Queue: Martin Kustermann <[email protected]>
dart-bot pushed a commit that referenced this issue Apr 13, 2018
@mkustermann
Reland "[VM] Introduction of type testing stubs - Part 1-4"
3b414a2 
Relands 165c583

    [VM] Introduction of type testing stubs - Part 1

    This CL:

      * Adds a field to [RawAbstractType] which will always hold a pointer
        to the entrypoint of a type testing stub

      * Makes this new field be initialized to a default stub whenever a
        instances are created (e.g. via Type::New(), snapshot reader, ...)

      * Makes the clustered snapshotter write a reference to the
        corresponding [RawInstructions] object when writing the field and do
        the reverse when reading it.

      * Makes us call the type testing stub for performing assert-assignable
        checks.

    To reduce unnecessary loads on callsites, we store the entrypoint of the
    type testing stubs directly in the type objects.  This means that the
    caller of type testing stubs can simply branch there without populating
    a code object first.  This also means that the type testing stubs
    themselves have no access to a pool and we therefore also don't hold on
    to the [Code] object, only the [Instruction] object is necessary.

    The type testing stubs do not setup a frame themselves and also have no
    safepoint.  In the case when the type testing stubs could not determine
    a positive answer they will tail-call a general-purpose stub.

    The general-purpose stub sets up a stub frame, tries to consult a
    [SubtypeTestCache] and bails out to runtime if this was unsuccessful.

    This CL is just the the first, for ease of reviewing.  The actual
    type-specialized type testing stubs will be generated in later CLs.

    Reviewed-on: https://dart-review.googlesource.com/44787

Relands f226c22

    [VM] Introduction of type testing stubs - Part 2

    This CL starts building type testing stubs specialzed for [Type] objects
    we test against.

    More specifically, it adds support for:

      * Handling obvious fast cases on the call sites (while still having a
        call to stub for negative case)

      * Handling type tests against type parameters, by loading the value
        of the type parameter on the call sites and invoking it's type testing stub.

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subtype-checks.

        ==> e.g. String/List<dynamic>

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the type arguments.

        ==> e.g. Widget<State>, where we know [Widget] is only extended and not
                 implemented.

      * Specialzed type testing stubs for certain non-instantiated types where we
        can do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the instantiated type arguments and
        cid based comparisons for type parameters.  (Note that this fast-case migth
        result in some false-negatives!)

        ==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
                 extended and not implemented.

       This optimizes cases where the caller uses `new HashMap<A, B>()` and only
       uses `A` and `B` as key/values (and not subclasses of it).  The false-negative
       can occur when subtypes of A or B are used.  In such cases we fall back to the
       [SubtypeTestCache]-based imlementation.

    Reviewed-on: https://dart-review.googlesource.com/44788

Relands 25f98bc

    [VM] Introduction of type testing stubs - Part 3

    The changes include:

      * Make AssertAssignableInstr no longer have a call-summary, which
        helps methods with several parameter checks by not having to
        re-load/re-initialize type arguments registers

      * Lazily create SubtypeTestCaches: We already go to runtime to warm up
        the caches, so we now also create the caches on the first runtime
        call and patch the pool entries.

      * No longer load the destination name into a register: We only need
        the name when we throw an exception, so it is not on the hot path.
        Instead we let the runtime look at the call site, decoding a pool
        index from the instructions stream.  The destination name will be
        available in the pool, at a consecutive index to the subtype cache.

      * Remove the fall-through to N=1 case for probing subtypeing tests,
        since those will always be handled by the optimized stubs.

      * Do not generate optimized stubs for FutureOr<T> (so far it just
        falled-through to TTS).  We can make optimzed version of that later,
        but it requires special subtyping rules.

      * Local code quality improvement in the type-testing-stubs: Avoid
        extra jump at last case of cid-class-range checks.

    There are still a number of optimization opportunities we can do in
    future changes.

    Reviewed-on: https://dart-review.googlesource.com/46984

Relands 2c52480

    [VM] Introduction of type testing stubs - Part 4

    In order to avoid generating type testing stubs for too many types in
    the system - and thereby potentially cause an increase in code size -
    this change introduces a smarter way to decide for which types we should
    generate optimized type testing stubs.

    The precompiler creates a [TypeUsageInfo] which we use to collect
    information.  More specifically:

       a) We collect the destination types for all type checks we emit
          (we do this inside AssertAssignableInstr::EmitNativeCode).

          -> These are types we might want to generate optimized type testing
             stubs for.

       b) We collect type argument vectors used in instance creations (we do
          this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
          of used type argument vectors for each class.

    After the precompiler has finished compiling normal code we scan the set
    of destination types collected in a) for uninstantiated types (or more
    specifically, type parameter types).

    We then propagate the type argument vectors used on object allocation sites,
    which were collected in b), in order to find out what kind of types are flowing
    into those type parameters.

    This allows us to extend the set of types which we test against, by
    adding the types that flow into type parameters.

    We use this final augmented set of destination types as a "filter" when
    making the decision whether to generate an optimized type testing stub
    for a given type.

    Reviewed-on: https://dart-review.googlesource.com/48640

Issue #32603

Closes #32852

Change-Id: Ib79fbe7f043aa88f32bddad62d7656c638914b44
Reviewed-on: https://dart-review.googlesource.com/50944
Commit-Queue: Martin Kustermann <[email protected]>
Reviewed-by: Régis Crelier <[email protected]>
dart-bot pushed a commit that referenced this issue May 22, 2019
@mkustermann
[vm/compiler] Speed up the compiler part which deals with kernel read…
b316210 
…ing up in DEBUG mode

This reduces our AOT compiler's time - gen_snapshot -  by half in DEBUG mode.

Issue #32603

Change-Id: I235afc40acba32036d4127c31c93f3b22f522314
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/103441
Commit-Queue: Martin Kustermann <[email protected]>
Reviewed-by: Alexander Aprelev <[email protected]>
tekknolagi pushed a commit to tekknolagi/dart-assembler that referenced this issue Nov 3, 2020
@mkustermann
Reland "[VM] Introduction of type testing stubs - Part 1-4"
146f981 
Relands 165c583

    [VM] Introduction of type testing stubs - Part 1

    This CL:

      * Adds a field to [RawAbstractType] which will always hold a pointer
        to the entrypoint of a type testing stub

      * Makes this new field be initialized to a default stub whenever a
        instances are created (e.g. via Type::New(), snapshot reader, ...)

      * Makes the clustered snapshotter write a reference to the
        corresponding [RawInstructions] object when writing the field and do
        the reverse when reading it.

      * Makes us call the type testing stub for performing assert-assignable
        checks.

    To reduce unnecessary loads on callsites, we store the entrypoint of the
    type testing stubs directly in the type objects.  This means that the
    caller of type testing stubs can simply branch there without populating
    a code object first.  This also means that the type testing stubs
    themselves have no access to a pool and we therefore also don't hold on
    to the [Code] object, only the [Instruction] object is necessary.

    The type testing stubs do not setup a frame themselves and also have no
    safepoint.  In the case when the type testing stubs could not determine
    a positive answer they will tail-call a general-purpose stub.

    The general-purpose stub sets up a stub frame, tries to consult a
    [SubtypeTestCache] and bails out to runtime if this was unsuccessful.

    This CL is just the the first, for ease of reviewing.  The actual
    type-specialized type testing stubs will be generated in later CLs.

    Reviewed-on: https://dart-review.googlesource.com/44787

Relands f226c22

    [VM] Introduction of type testing stubs - Part 2

    This CL starts building type testing stubs specialzed for [Type] objects
    we test against.

    More specifically, it adds support for:

      * Handling obvious fast cases on the call sites (while still having a
        call to stub for negative case)

      * Handling type tests against type parameters, by loading the value
        of the type parameter on the call sites and invoking it's type testing stub.

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subtype-checks.

        ==> e.g. String/List<dynamic>

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the type arguments.

        ==> e.g. Widget<State>, where we know [Widget] is only extended and not
                 implemented.

      * Specialzed type testing stubs for certain non-instantiated types where we
        can do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the instantiated type arguments and
        cid based comparisons for type parameters.  (Note that this fast-case migth
        result in some false-negatives!)

        ==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
                 extended and not implemented.

       This optimizes cases where the caller uses `new HashMap<A, B>()` and only
       uses `A` and `B` as key/values (and not subclasses of it).  The false-negative
       can occur when subtypes of A or B are used.  In such cases we fall back to the
       [SubtypeTestCache]-based imlementation.

    Reviewed-on: https://dart-review.googlesource.com/44788

Relands 25f98bc

    [VM] Introduction of type testing stubs - Part 3

    The changes include:

      * Make AssertAssignableInstr no longer have a call-summary, which
        helps methods with several parameter checks by not having to
        re-load/re-initialize type arguments registers

      * Lazily create SubtypeTestCaches: We already go to runtime to warm up
        the caches, so we now also create the caches on the first runtime
        call and patch the pool entries.

      * No longer load the destination name into a register: We only need
        the name when we throw an exception, so it is not on the hot path.
        Instead we let the runtime look at the call site, decoding a pool
        index from the instructions stream.  The destination name will be
        available in the pool, at a consecutive index to the subtype cache.

      * Remove the fall-through to N=1 case for probing subtypeing tests,
        since those will always be handled by the optimized stubs.

      * Do not generate optimized stubs for FutureOr<T> (so far it just
        falled-through to TTS).  We can make optimzed version of that later,
        but it requires special subtyping rules.

      * Local code quality improvement in the type-testing-stubs: Avoid
        extra jump at last case of cid-class-range checks.

    There are still a number of optimization opportunities we can do in
    future changes.

    Reviewed-on: https://dart-review.googlesource.com/46984

Relands 2c52480

    [VM] Introduction of type testing stubs - Part 4

    In order to avoid generating type testing stubs for too many types in
    the system - and thereby potentially cause an increase in code size -
    this change introduces a smarter way to decide for which types we should
    generate optimized type testing stubs.

    The precompiler creates a [TypeUsageInfo] which we use to collect
    information.  More specifically:

       a) We collect the destination types for all type checks we emit
          (we do this inside AssertAssignableInstr::EmitNativeCode).

          -> These are types we might want to generate optimized type testing
             stubs for.

       b) We collect type argument vectors used in instance creations (we do
          this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
          of used type argument vectors for each class.

    After the precompiler has finished compiling normal code we scan the set
    of destination types collected in a) for uninstantiated types (or more
    specifically, type parameter types).

    We then propagate the type argument vectors used on object allocation sites,
    which were collected in b), in order to find out what kind of types are flowing
    into those type parameters.

    This allows us to extend the set of types which we test against, by
    adding the types that flow into type parameters.

    We use this final augmented set of destination types as a "filter" when
    making the decision whether to generate an optimized type testing stub
    for a given type.

    Reviewed-on: https://dart-review.googlesource.com/48640

Issue dart-lang#32603

Change-Id: I44a1d5d4b27454ae026aef2a301aada3dd399ea0
Reviewed-on: https://dart-review.googlesource.com/49861
Commit-Queue: Martin Kustermann <[email protected]>
Reviewed-by: Vyacheslav Egorov <[email protected]>
tekknolagi pushed a commit to tekknolagi/dart-assembler that referenced this issue Nov 3, 2020
@mkustermann
Reland "[VM] Introduction of type testing stubs - Part 1-4"
125aa81 
Relands 165c583

    [VM] Introduction of type testing stubs - Part 1

    This CL:

      * Adds a field to [RawAbstractType] which will always hold a pointer
        to the entrypoint of a type testing stub

      * Makes this new field be initialized to a default stub whenever a
        instances are created (e.g. via Type::New(), snapshot reader, ...)

      * Makes the clustered snapshotter write a reference to the
        corresponding [RawInstructions] object when writing the field and do
        the reverse when reading it.

      * Makes us call the type testing stub for performing assert-assignable
        checks.

    To reduce unnecessary loads on callsites, we store the entrypoint of the
    type testing stubs directly in the type objects.  This means that the
    caller of type testing stubs can simply branch there without populating
    a code object first.  This also means that the type testing stubs
    themselves have no access to a pool and we therefore also don't hold on
    to the [Code] object, only the [Instruction] object is necessary.

    The type testing stubs do not setup a frame themselves and also have no
    safepoint.  In the case when the type testing stubs could not determine
    a positive answer they will tail-call a general-purpose stub.

    The general-purpose stub sets up a stub frame, tries to consult a
    [SubtypeTestCache] and bails out to runtime if this was unsuccessful.

    This CL is just the the first, for ease of reviewing.  The actual
    type-specialized type testing stubs will be generated in later CLs.

    Reviewed-on: https://dart-review.googlesource.com/44787

Relands f226c22

    [VM] Introduction of type testing stubs - Part 2

    This CL starts building type testing stubs specialzed for [Type] objects
    we test against.

    More specifically, it adds support for:

      * Handling obvious fast cases on the call sites (while still having a
        call to stub for negative case)

      * Handling type tests against type parameters, by loading the value
        of the type parameter on the call sites and invoking it's type testing stub.

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subtype-checks.

        ==> e.g. String/List<dynamic>

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the type arguments.

        ==> e.g. Widget<State>, where we know [Widget] is only extended and not
                 implemented.

      * Specialzed type testing stubs for certain non-instantiated types where we
        can do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the instantiated type arguments and
        cid based comparisons for type parameters.  (Note that this fast-case migth
        result in some false-negatives!)

        ==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
                 extended and not implemented.

       This optimizes cases where the caller uses `new HashMap<A, B>()` and only
       uses `A` and `B` as key/values (and not subclasses of it).  The false-negative
       can occur when subtypes of A or B are used.  In such cases we fall back to the
       [SubtypeTestCache]-based imlementation.

    Reviewed-on: https://dart-review.googlesource.com/44788

Relands 25f98bc

    [VM] Introduction of type testing stubs - Part 3

    The changes include:

      * Make AssertAssignableInstr no longer have a call-summary, which
        helps methods with several parameter checks by not having to
        re-load/re-initialize type arguments registers

      * Lazily create SubtypeTestCaches: We already go to runtime to warm up
        the caches, so we now also create the caches on the first runtime
        call and patch the pool entries.

      * No longer load the destination name into a register: We only need
        the name when we throw an exception, so it is not on the hot path.
        Instead we let the runtime look at the call site, decoding a pool
        index from the instructions stream.  The destination name will be
        available in the pool, at a consecutive index to the subtype cache.

      * Remove the fall-through to N=1 case for probing subtypeing tests,
        since those will always be handled by the optimized stubs.

      * Do not generate optimized stubs for FutureOr<T> (so far it just
        falled-through to TTS).  We can make optimzed version of that later,
        but it requires special subtyping rules.

      * Local code quality improvement in the type-testing-stubs: Avoid
        extra jump at last case of cid-class-range checks.

    There are still a number of optimization opportunities we can do in
    future changes.

    Reviewed-on: https://dart-review.googlesource.com/46984

Relands 2c52480

    [VM] Introduction of type testing stubs - Part 4

    In order to avoid generating type testing stubs for too many types in
    the system - and thereby potentially cause an increase in code size -
    this change introduces a smarter way to decide for which types we should
    generate optimized type testing stubs.

    The precompiler creates a [TypeUsageInfo] which we use to collect
    information.  More specifically:

       a) We collect the destination types for all type checks we emit
          (we do this inside AssertAssignableInstr::EmitNativeCode).

          -> These are types we might want to generate optimized type testing
             stubs for.

       b) We collect type argument vectors used in instance creations (we do
          this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
          of used type argument vectors for each class.

    After the precompiler has finished compiling normal code we scan the set
    of destination types collected in a) for uninstantiated types (or more
    specifically, type parameter types).

    We then propagate the type argument vectors used on object allocation sites,
    which were collected in b), in order to find out what kind of types are flowing
    into those type parameters.

    This allows us to extend the set of types which we test against, by
    adding the types that flow into type parameters.

    We use this final augmented set of destination types as a "filter" when
    making the decision whether to generate an optimized type testing stub
    for a given type.

    Reviewed-on: https://dart-review.googlesource.com/48640

Issue dart-lang#32603

Change-Id: I6d33d4ca3d5187a1eb1664078c003061855f0160
Reviewed-on: https://dart-review.googlesource.com/50482
Reviewed-by: Vyacheslav Egorov <[email protected]>
Commit-Queue: Martin Kustermann <[email protected]>
tekknolagi pushed a commit to tekknolagi/dart-assembler that referenced this issue Nov 3, 2020
@mkustermann
Reland "[VM] Introduction of type testing stubs - Part 1-4"
77ad150 
Relands 165c583

    [VM] Introduction of type testing stubs - Part 1

    This CL:

      * Adds a field to [RawAbstractType] which will always hold a pointer
        to the entrypoint of a type testing stub

      * Makes this new field be initialized to a default stub whenever a
        instances are created (e.g. via Type::New(), snapshot reader, ...)

      * Makes the clustered snapshotter write a reference to the
        corresponding [RawInstructions] object when writing the field and do
        the reverse when reading it.

      * Makes us call the type testing stub for performing assert-assignable
        checks.

    To reduce unnecessary loads on callsites, we store the entrypoint of the
    type testing stubs directly in the type objects.  This means that the
    caller of type testing stubs can simply branch there without populating
    a code object first.  This also means that the type testing stubs
    themselves have no access to a pool and we therefore also don't hold on
    to the [Code] object, only the [Instruction] object is necessary.

    The type testing stubs do not setup a frame themselves and also have no
    safepoint.  In the case when the type testing stubs could not determine
    a positive answer they will tail-call a general-purpose stub.

    The general-purpose stub sets up a stub frame, tries to consult a
    [SubtypeTestCache] and bails out to runtime if this was unsuccessful.

    This CL is just the the first, for ease of reviewing.  The actual
    type-specialized type testing stubs will be generated in later CLs.

    Reviewed-on: https://dart-review.googlesource.com/44787

Relands f226c22

    [VM] Introduction of type testing stubs - Part 2

    This CL starts building type testing stubs specialzed for [Type] objects
    we test against.

    More specifically, it adds support for:

      * Handling obvious fast cases on the call sites (while still having a
        call to stub for negative case)

      * Handling type tests against type parameters, by loading the value
        of the type parameter on the call sites and invoking it's type testing stub.

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subtype-checks.

        ==> e.g. String/List<dynamic>

      * Specialzed type testing stubs for instantiated types where we can
        do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the type arguments.

        ==> e.g. Widget<State>, where we know [Widget] is only extended and not
                 implemented.

      * Specialzed type testing stubs for certain non-instantiated types where we
        can do [CidRange]-based subclass-checks for the class and
        [CidRange]-based subtype-checks for the instantiated type arguments and
        cid based comparisons for type parameters.  (Note that this fast-case migth
        result in some false-negatives!)

        ==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only
                 extended and not implemented.

       This optimizes cases where the caller uses `new HashMap<A, B>()` and only
       uses `A` and `B` as key/values (and not subclasses of it).  The false-negative
       can occur when subtypes of A or B are used.  In such cases we fall back to the
       [SubtypeTestCache]-based imlementation.

    Reviewed-on: https://dart-review.googlesource.com/44788

Relands 25f98bc

    [VM] Introduction of type testing stubs - Part 3

    The changes include:

      * Make AssertAssignableInstr no longer have a call-summary, which
        helps methods with several parameter checks by not having to
        re-load/re-initialize type arguments registers

      * Lazily create SubtypeTestCaches: We already go to runtime to warm up
        the caches, so we now also create the caches on the first runtime
        call and patch the pool entries.

      * No longer load the destination name into a register: We only need
        the name when we throw an exception, so it is not on the hot path.
        Instead we let the runtime look at the call site, decoding a pool
        index from the instructions stream.  The destination name will be
        available in the pool, at a consecutive index to the subtype cache.

      * Remove the fall-through to N=1 case for probing subtypeing tests,
        since those will always be handled by the optimized stubs.

      * Do not generate optimized stubs for FutureOr<T> (so far it just
        falled-through to TTS).  We can make optimzed version of that later,
        but it requires special subtyping rules.

      * Local code quality improvement in the type-testing-stubs: Avoid
        extra jump at last case of cid-class-range checks.

    There are still a number of optimization opportunities we can do in
    future changes.

    Reviewed-on: https://dart-review.googlesource.com/46984

Relands 2c52480

    [VM] Introduction of type testing stubs - Part 4

    In order to avoid generating type testing stubs for too many types in
    the system - and thereby potentially cause an increase in code size -
    this change introduces a smarter way to decide for which types we should
    generate optimized type testing stubs.

    The precompiler creates a [TypeUsageInfo] which we use to collect
    information.  More specifically:

       a) We collect the destination types for all type checks we emit
          (we do this inside AssertAssignableInstr::EmitNativeCode).

          -> These are types we might want to generate optimized type testing
             stubs for.

       b) We collect type argument vectors used in instance creations (we do
          this inside AllocateObjectInstr::EmitNativeCode) and keep a set of
          of used type argument vectors for each class.

    After the precompiler has finished compiling normal code we scan the set
    of destination types collected in a) for uninstantiated types (or more
    specifically, type parameter types).

    We then propagate the type argument vectors used on object allocation sites,
    which were collected in b), in order to find out what kind of types are flowing
    into those type parameters.

    This allows us to extend the set of types which we test against, by
    adding the types that flow into type parameters.

    We use this final augmented set of destination types as a "filter" when
    making the decision whether to generate an optimized type testing stub
    for a given type.

    Reviewed-on: https://dart-review.googlesource.com/48640

Issue dart-lang#32603

Closes dart-lang#32852

Change-Id: Ib79fbe7f043aa88f32bddad62d7656c638914b44
Reviewed-on: https://dart-review.googlesource.com/50944
Commit-Queue: Martin Kustermann <[email protected]>
Reviewed-by: Régis Crelier <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mkustermann mkustermann

Labels
area-vm Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mkustermann