Use the existing class-id check for dense ranges in more places.
Previously we would fall back to megamorphic lookup with >4 cids,
even though we can check cid ranges up to word-size efficiently.
Next step is to generalize the dense class id checks to multiple
word-sizes.
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/1847293002 .
index table
- Do not try to figure out if the passed in handle is a temporary scoped
handle, instead have all the callers create a ZoneHandle
Compilation of the ESS initialization code in GreenTea reduces from 2.56secs to .497 secs
R=fschneider@google.com
Review URL: https://codereview.chromium.org/1846063002 .
- No new fields or patching of existing fields can be done
- Only external methods that have not already executed (i.e code for it has been generated) can be patched
This change enables patching of JS Interop methods into a class and provides close to 5 sec drop in start up times for Green Tea app.
R=hausner@google.com, regis@google.com
Review URL: https://codereview.chromium.org/1850653003 .
With catch blocks appearing as additional function entry blocks,
there can be phis for the receiver (parameter 0).
This CL fixes the problem that the receiver type information
was lost in the presence of try-catch.
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/1841073003 .
Symptom of the problem:
Set your Linux workstation (or Mac or MIPS board) to the Europe/London timezone
and the corelib/date_time test will fail, claiming that 1/1/1970 was a Wednesday
(it was actually a Thursday, trust me, I was already born).
Problem:
The implementation of DateTime in the VM relies on Unix time_t, the number of
seconds since the Epoch (1/1/1970 UTC). When asked for the weekday of a given
time, our implementation limits itself to a 32-bit positive range of time_t.
If the time falls outside of this range, the implementation picks an equivalent
time in the valid range with the same weekday, also in leap year or not, etc...
The issue is that DateTime is using the underlying OS in an inconsistent manner.
Let's take the example above: 1/1/1970 in the Europe/London timezone.
First, the number of seconds since the Epoch in UTC is calculated, here 0.
Then, the timezone offset at the given time is calculated using the underlying
OS. In this case, an historical deviation is taken into account. Indeed, London
stayed on British Summer Time between 27 October 1968 and 31 October 1971. See
https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of_deviation for
details.
Our resulting time is therefore negative (one hour difference with UTC).
When asked about the weekday of this time, the implementation notices that the
time is not in the positive range and picks an "equivalent" time in the future.
It then asks the underlying OS about the timezone offset for this time, which
is 0 (usually no daylight saving time in January in London). Unfortunately,
this time is not really equivalent, because it ignores the original historical
deviation. The result is wrongly equivalent to 12/31/1969 23:00 in London, i.e.
a Wednesday, and not a Thursday as expected.
Solution:
We should use the underlying OS in a consistent way, by simply allowing the
value of time_t passed to the underlying OS to be negative, which is legal.
R=floitsch@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/1845483002 .
Previously we would compile in implementaitions of native calls for
IO functions that would never be used. This CL provides implementations
that throw a Dart exception if they're called by mistake. It also uses
a DART_IO_DISABLED preprocessor define to clean up the build files and
check that we're not including code we shouldn't.
R=iposva@google.com, johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1839463002 .
Reference Instructions only through Code::entry_point_ (or Function::entry_point_). Store the instructions size in its corresponding Code object.
precompiled dart2js x64 22163470 -> 21621102 (-2.45%)
R=fschneider@google.com
Review URL: https://codereview.chromium.org/1808553002 .
(With --complete-timeline, my iPod runs of memory processing the
timeline. With the ring recorder, the startup events have already been
bumped out by time I can connect to Observatory.)
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/1834383002 .
The SecureTransport API is a bit finicky about the return code
and length from SSL{Read,Write}Callback. I think I've got it
right now, but we'll have to keep an eye on it.
Also a small tweak to avoid an extra trip through the event loop
before putting a write event on the secure socket stream.
related #26104R=iposva@google.com
Review URL: https://codereview.chromium.org/1842703003 .
Florian Schneider