| commit | 51649b702d39b7bc9b8b425d99c1b326583592de | [log] [tgz] |
|---|---|---|
| author | Tess Strickland <sstrickl@google.com> | Tue Aug 10 13:56:33 2021 |
| committer | commit-bot@chromium.org <commit-bot@chromium.org> | Tue Aug 10 13:56:33 2021 |
| tree | bcd0723027bdd3c6ca1700adb4812e138f5500f4 | |
| parent | c040c050d6bf044a7e3d9b805bab15823c47c8b9 [diff] |
[vm] Allow optimized type testing stubs to be partial. Previously, the code in the TypeCheck runtime entry assumed that if a lazily specialized type testing stub (TTS) returned a false negative in JIT mode, that it should always be regenerated and that regeneration would always result in different code. In AOT mode, false negatives instead always cause the stub to go to runtime, even if that false negative had been seen before, because the assumption is that false negatives shouldn't happen when the whole class hierarchy is known at compile time. However, even in the current implementation of optimized TTSes, there are cases where this assumption is false. For example, the code generated by BuildOptimizedSubclassRangeCheckWithTypeArguments allows for provided type arguments to be type parameters. When this happens, the type parameter is instantiated at runtime using the instantiator or function type arguments, and the instantiated type parameter must be identical to the result retrieved from the type arguments of the instance. That means that if the instantiated type parameter is not the same type, but a supertype, of the result, then a false negative is generated. This CL changes TypeCheck's handling of false negatives from lazily specialized TTSes as follows: in JIT, if the regenerated stub is the same as the old stub, or in AOT, a false negative causes the same fall back to SubtypeTestCaches as unoptimized stubs. This way, further checks with the same false negative will be caught via the STC before going to runtime, assuming the STC hasn't already filled up with false negatives. Currently, we only generate false negatives for reasons that will not change when respecialization occurs due to additions to the hierarchy, so we do not need to clear affected STCs during respecialization. However, the previous approach to resetting STCs on reload (in CallSiteResetter::ResetCaches) is insufficient, since there may be caches containing reloaded types in non-reloaded code (like the TTS invoker stub created by the TTS testing framework). Instead, clear all caches on reload using the same ObjectVisitor as deoptimizing type testing stubs. Since we now have to check instruction equality to determine whether to add to the STC, we now only replace the existing stub if the instructions are different. This makes it easier to test whether a TTS invocation on a false positive caused respecialization or not. This CL also reworks the testing framework for type testing stubs, 1) creating a test case object that stores the particulars of a given invocation, including expectations, and 2) moving most checks and access to appropriate data structures into a state object that handles setup and performing invocations given test cases. TEST=vm/cc/TTS_Partial Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-tsan-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try Change-Id: I139608c5a0f2442a85a1cf39d1c04104db7a5593 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208653 Commit-Queue: Tess Strickland <sstrickl@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com> Reviewed-by: Alexander Markov <alexmarkov@google.com>
Dart is:
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app.
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.