We need to block interrupts while evaluating pragmas to prevert reentrant class finalization.
Original revision is in patchset 0.
Change-Id: I872cec4eaf4ca85567c9657c458ed39c8b2e30de
Cq-Include-Trybots: luci.dart.try:vm-kernel-win-release-x64-try, vm-kernel-optcounter-threshold-linux-release-x64-try, vm-kernel-precomp-linux-debug-x64-try, vm-kernel-precomp-linux-release-simarm-try, vm-kernel-precomp-linux-release-simarm64-try, vm-kernel-precomp-linux-release-x64-try, vm-kernel-precomp-win-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/73160
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This allows us to avoid going into runtime even if strong mode is
enabled: type checking is handled in the []= operator itself and
_setIndexed does not need to check types and thus can be intrinsified.
This CL also removes inline type checking done in ia32 version,
not other platform had it.
# Performance Impact
Mostly noticable on Dart v2 AOT configuration where AOT compiler
did not inline []=:
Richards +26.27%
Meteor +33.63%
BuildTableInterpolation +68.98%
DeltaBlueClosures +46.43%
StarryStrings +22.08%
NavierStokes +94.81%
JsonParseCustomReviver +45.22%
DeltaBlue +56.44%
BuildTableBufferWithCodes +84.40%
JsonParseDefaultReviver +46.13%
BuildTableBuffer +125.8%
BuildTableIdiomatic +125.8%
StringBuffer +127.3%
StringIdiomatic +127.2%
JsonObjectRoundTrip +95.42%
JsonStringifyFinancialOnce +125.7%
JsonRoundTrip +96.01%
Bug:
Change-Id: Ie6d33ac55b5a0c0909ca06e0c88a60d8e0d2604e
Reviewed-on: https://dart-review.googlesource.com/26800
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Array Bounds Check Generalization pass attempts to hoist CheckArrayBound
instructions out of loops by generalizing them: for example in the loop
like
for (var i = 0; i < L; i++) {
// a[i]
CheckArrayBound(i, a.length)
LoadIndexed(a, i)
}
we hoist CheckArrayBound(i, a.length) by turning it into
CheckArrayBound(L - 1, a.length):
CheckArrayBound(L - 1, a.length)
for (var i = 0; i < L; i++) {
// a[i]
LoadIndexed(a, i)
}
However this leads to deoptimizations if the loop never executes: e.g. if
L = 0 then L - 1 is -1 which does not pass generalized bounds check.
We prevent repeated deoptimizations by disabling this optimization if any
of the generalized bounds checks deoptimizes. However this does not work
as intended because we only check this flag on an outermost function, so
if function with a problematic bounds check get inlined into a lot of places
it ends up causing a lot of deoptimizations in different places.
This is why cec963f028 caused performance issues
in dartdoc: _GrowableList._grow is now called with length == 0 whenever we
add an element to an empty list. This causes deoptimization in a lot of different
functions in dartdoc because _GrowableList._grow ends up inlined into a lot
of different places.
Fixes https://github.com/dart-lang/sdk/issues/30090
This CL will be reverted once a better solution for the underlying problem is in place (tracked by https://github.com/dart-lang/sdk/issues/30102)
BUG=
R=askesc@google.com, erikcorry@google.com
Review-Url: https://codereview.chromium.org/2971303002 .
I collected statistics for the sizes and capacities of growable arrays which are promoted to old-space or survive an old-space gc when running dart2js and Fasta. For these applications, the vast majority of arrays stay empty. More than half of the total object size of promoted backing arrays is backing for empty growable arrays.
Furthermore, since the overhead for an array is 3 words (header, type parameters and length), and object sizes are rounded up to an even number of words, we waste one word for all even-sized arrays.
This CL changes the growth strategy so that empty growable arrays are created with a shared, zero-sized array as backing, avoiding the allocation of a backing array if no elements are added. When the array needs to grow, it starts out at 3 and grows to double size plus one each time: 7, 15, 31, ...
A few places in the VM code need to handle these shared, zero-sized arrays specially. In particular, the Array::MakeArray function needs to allocate a new, empty array if its result is to be returned to Dart code.
Benchmarks suggest that the change improves memory usage by a few percent overall and does not significantly affect run time.
BUG=
R=erikcorry@google.com
Review-Url: https://codereview.chromium.org/2949803002 .
Fix observatory tests broken by running dartfmt due to line and column changes.
Temporarily reverted formatting for evaluate_activation_test.dart as dartfmt doesn't yet handle multitests.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2759973004 .
I've omitted files where the formatter output is significantly uglier
than the original code and I'll send those files in a separate CL
with options for how to make the code look reasonable while still
taking advantage of the formatter.
BUG=
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2751423005 .
This should help least-upper-bound computations to not think of EfficientLength
as completely separate from Iterable even though they are always used together.
It doesn't solve all problems with the least-upper-bound computation,
but at least some of the more often occuring ones.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2467113003 .
It's still not a good solution for detecting an Iterable with an efficient
length. It's not inherited by, e.g., a DelegatingIterable wrapper or similar
generic Iterable transformers.
Keep this as an internal optimization for quickly detecting the most common
efficient-length Iterable classes (List, Set, Queue, Map.keys/values), but
don't make it public.
A *real* solution would be adding a hasEfficientLength getter to Iterable, or
adding an efficientLength getter that may return null if it's not efficient.
This would something that a wrapper can attach to.
R=sgjesse@google.com
Review URL: https://codereview.chromium.org//1154263003
A previous change made these omit elements to keep the toString length down.
That could break code that expects the original behavior.
This still avoids using IterableMixinWorkaround.
Add static toString methods on ListBase, SetBase, IterableBase so that users can
get the same behavior as our toString methods, and with the same cycle detection
safety.
Unify all collection toString methods in two methods:
- IterableBase.iterableToShortString
- IterableBase.iterableToFullString
R=floitsch@google.com
Review URL: https://codereview.chromium.org//297053002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@36616 260f80e4-7a28-3924-810f-c04153c831b5
Implement proper semantics if a name has been referenced in a
block and later a variable with that same name is declared.
Fix library code that was wrong.
Add new language test, delete a couple of tests that are
outdated, file co19 bug 649.
Dart2js and dart2dart are not yet implementing these compile-time
errors.
R=iposva@google.com
Review URL: https://codereview.chromium.org//51533003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@29770 260f80e4-7a28-3924-810f-c04153c831b5
Samir Jindel