Support deferred library prefix syntax

Support deferred library prefix syntax

First step towards deferred library support:
- Parse the “deferred as” import clause.
- Implement p.loadLibrary() which returns a future that
  completes when the library is loaded.
- Treat type annotations of deferred types as malformed.
- Throw NoSuchMethodError when calling functions from
  unloaded libraries.
- Libraries are still read synchronously, but items in the
  library won’t be visible through the deferred prefix until
  the future returned by loadLibrary() completes.

Committed: https://code.google.com/p/dart/source/detail?r=34481

[hausner, 2014-03-24 22:21:47]

Please take an early look. Still need to run tests and adjust status files.

Siva, can you please look at the change of moving LibraryPrefix from the VM
isolate to the object store?

[hausner, 2014-03-24 23:57:59]

After running tests, I realize that this change is not finished yet. I have to
figure out how to allow new deferred.X(), i.e. how to deal with the
instantiation of a type that is malformed because it comes from a deferred
library.

[Ivan Posva, 2014-03-25 02:38:40]

I have a couple of questions about why libraries are treated as loaded/deferred.
Let's discuss in person tomorrow.

-Ivan

[hausner, 2014-03-25 23:21:59]

Now with tests and test expectations updated. Also adds distinction between
deferred types used to allocate objects and deferred types used for everything
else.

[Ivan Posva, 2014-03-27 07:38:48]

-Ivan

https://codereview.chromium.org/208323015/diff/20001/runtime/lib/lib_prefix.dart
File runtime/lib/lib_prefix.dart (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/lib/lib_prefix.d...
runtime/lib/lib_prefix.dart:14: var completer = new Completer<bool>();
indentation

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc#new...
runtime/vm/object.cc:2453: if (code.is_optimized()) {
What if we have optimized code that needs to be entirely cleared such as on load
of libraries?

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc#new...
runtime/vm/object.cc:9196: if (is_loaded()) {
What is the value of loaded for an eagerly loaded prefix? If it is marked as
loaded as I would expect, then the above check for deferred_load is not needed.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h
File runtime/vm/object.h (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:2612: bool IsDeferred() const {
The deferred state is not part of the library. It should exclusively be
associated with the prefix.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:4094: bool is_deferred_load() const { return
raw_ptr()->is_deferred_load_; }
Maybe just  is_deferred?

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:4099: // prefix was not yet loaded. These code objects will
be thrown
thrown away -> invalidated

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:4106: void NukeDependentCode() const;
InvalidateDependentCode

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/symbols.h
File runtime/vm/symbols.h (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/symbols.h#new...
runtime/vm/symbols.h:70: V(_LibraryPrefix, "_LibraryPrefix")                    
          \
alignment

[hausner, 2014-03-27 20:45:39]

Thank you.

https://codereview.chromium.org/208323015/diff/20001/runtime/lib/lib_prefix.dart
File runtime/lib/lib_prefix.dart (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/lib/lib_prefix.d...
runtime/lib/lib_prefix.dart:14: var completer = new Completer<bool>();
On 2014/03/27 07:38:48, Ivan Posva wrote:
> indentation

Oops. Tabs.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc#new...
runtime/vm/object.cc:2453: if (code.is_optimized()) {
On 2014/03/27 07:38:48, Ivan Posva wrote:
> What if we have optimized code that needs to be entirely cleared such as on
load
> of libraries?
I think we spoke about this before i implemented it. You pointed out that if the
optimized code is in the list, then the unoptimized code is in the list as well
and we'll get rid of it in a separate iteration. The optimized code is thrown
away when we switch to unoptimized code. So I think both versions of the code
are nuked.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc#new...
runtime/vm/object.cc:9196: if (is_loaded()) {
On 2014/03/27 07:38:48, Ivan Posva wrote:
> What is the value of loaded for an eagerly loaded prefix? If it is marked as
> loaded as I would expect, then the above check for deferred_load is not
needed.
That is true. I'll change this to an assert to ensure the invariant.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h
File runtime/vm/object.h (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:2612: bool IsDeferred() const {
On 2014/03/27 07:38:48, Ivan Posva wrote:
> The deferred state is not part of the library. It should exclusively be
> associated with the prefix.
When I started this change I thought we'd need to be able to distinguish whether
a library is referenced by a deferred prefix or not. Maybe not necessary. It's
not used yet, so I'll remove it.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:4094: bool is_deferred_load() const { return
raw_ptr()->is_deferred_load_; }
On 2014/03/27 07:38:48, Ivan Posva wrote:
> Maybe just  is_deferred?
I think in the places where is_deferred_load() is used it looks better with the
_load. I can remove it if you feel strongly about it.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:4099: // prefix was not yet loaded. These code objects will
be thrown
On 2014/03/27 07:38:48, Ivan Posva wrote:
> thrown away -> invalidated

Done.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.h#newc...
runtime/vm/object.h:4106: void NukeDependentCode() const;
On 2014/03/27 07:38:48, Ivan Posva wrote:
> InvalidateDependentCode

Nukular-free zone? Done.

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/symbols.h
File runtime/vm/symbols.h (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/symbols.h#new...
runtime/vm/symbols.h:70: V(_LibraryPrefix, "_LibraryPrefix")                    
          \
On 2014/03/27 07:38:48, Ivan Posva wrote:
> alignment

Done.

[hausner, 2014-03-27 21:21:01]

Committed patchset #3 manually as r34481 (presubmit successful).

[Ivan Posva, 2014-03-27 21:41:18]

LGTM -ip

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/208323015/diff/20001/runtime/vm/object.cc#new...
runtime/vm/object.cc:2453: if (code.is_optimized()) {
On 2014/03/27 20:45:39, hausner wrote:
> On 2014/03/27 07:38:48, Ivan Posva wrote:
> > What if we have optimized code that needs to be entirely cleared such as on
> load
> > of libraries?
> I think we spoke about this before i implemented it. You pointed out that if
the
> optimized code is in the list, then the unoptimized code is in the list as
well
> and we'll get rid of it in a separate iteration. The optimized code is thrown
> away when we switch to unoptimized code. So I think both versions of the code
> are nuked.

I worry about the ordering of code removal a bit. What is the behaviour of
SwitchToUnoptimizedCode if we have already removed the unoptimized code?