VM: Add infrastructure to support deferred generation of unoptimized code.

VM: Add infrastructure to support deferred generation of unoptimized code.

Add deferred deoptimization instructions for return address, pc marker and
object pool pointer. This enables generating unoptimized code lazily
on deoptimization.

This CL does not change the way unoptimized code is generated or collected
yet, but just provides the mechanisms needed. This can be used to allow
code GC for the unoptimized code of optimized functions.

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

[Florian Schneider, 2015-04-02 10:07:32]

fschneider@google.com changed reviewers:
+ iposva@google.com, vegorov@google.com

[Ivan Posva, 2015-04-02 17:14:00]

LGTM -ip

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

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/compiler.cc#...
runtime/vm/compiler.cc:1072: if (!original_code.IsNull() &&
This logic here is really hard to follow. Please explain what the intent is here
in a comment.

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/deferred_obj...
File runtime/vm/deferred_objects.cc (right):

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/deferred_obj...
runtime/vm/deferred_objects.cc:195: Code::Handle(deopt_context->zone(),
function.unoptimized_code());
Please add "Compiler::EnsureUnoptimizedCode(deopt_context->thread(), function);"
unless you really want to rely on the side effect of the other deferred
operations having ensured the availability of unoptimized code.

[srdjan, 2015-04-02 17:43:39]

srdjan@google.com changed reviewers:
+ srdjan@google.com

[srdjan, 2015-04-02 17:43:40]

DBC

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

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/compiler.cc#...
runtime/vm/compiler.cc:1061: Code& original_code = Code::ZoneHandle();
pass thread->zone() to it.

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/deferred_obj...
File runtime/vm/deferred_objects.cc (right):

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/deferred_obj...
runtime/vm/deferred_objects.cc:16: DECLARE_FLAG(bool, trace_deoptimization);
Reorder alphabetically.

[Florian Schneider, 2015-04-07 09:07:57]

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

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/compiler.cc#...
runtime/vm/compiler.cc:1061: Code& original_code = Code::ZoneHandle();
On 2015/04/02 17:43:40, srdjan wrote:
> pass thread->zone() to it.

Done.

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/compiler.cc#...
runtime/vm/compiler.cc:1072: if (!original_code.IsNull() &&
On 2015/04/02 17:14:00, Ivan Posva wrote:
> This logic here is really hard to follow. Please explain what the intent is
here
> in a comment.

Done.

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/deferred_obj...
File runtime/vm/deferred_objects.cc (right):

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/deferred_obj...
runtime/vm/deferred_objects.cc:16: DECLARE_FLAG(bool, trace_deoptimization);
On 2015/04/02 17:43:40, srdjan wrote:
> Reorder alphabetically.

Done.

https://codereview.chromium.org/1052563003/diff/20001/runtime/vm/deferred_obj...
runtime/vm/deferred_objects.cc:195: Code::Handle(deopt_context->zone(),
function.unoptimized_code());
On 2015/04/02 17:14:00, Ivan Posva wrote:
> Please add "Compiler::EnsureUnoptimizedCode(deopt_context->thread(),
function);"
> unless you really want to rely on the side effect of the other deferred
> operations having ensured the availability of unoptimized code.

Good point. Done.

[Florian Schneider, 2015-04-07 12:35:18]

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

[rmacnak, 2015-04-09 18:43:34]

rmacnak@google.com changed reviewers:
+ rmacnak@google.com

[rmacnak, 2015-04-09 18:43:35]

This breaks live editing. Optimized code should always have a strong reference
to its corresponding unoptimized code (1) because the unoptimized code
associated with the function (2) may change as a result of editing, and a
deoptimized frame needs to continue in 1 not 2.

It might also break deferred loading if the embedder finishes loading while the
stack has an optimized frame with a deferred prefix, as 2 will also be out of
sync with 1.

[Vyacheslav Egorov (Google), 2015-04-09 19:45:12]

I was under an impression that live editing is not implemented. Am I wrong? One
can't break something that is not implemented.

[rmacnak, 2015-04-09 20:30:17]

On 2015/04/09 19:45:12, Vyacheslav Egorov (Google) wrote:
> I was under an impression that live editing is not implemented. Am I wrong?
One
> can't break something that is not implemented.

A subset that only deals with methods is implemented on my machine, but not
checked in.

[Ivan Posva, 2015-04-09 20:35:17]

On 2015/04/09 20:30:17, rmacnak wrote:
> On 2015/04/09 19:45:12, Vyacheslav Egorov (Google) wrote:
> > I was under an impression that live editing is not implemented. Am I wrong?
> One
> > can't break something that is not implemented.
> 
> A subset that only deals with methods is implemented on my machine, but not
> checked in.

Ryan,

Please let's focus on the thing that is actually checked in and working in
production: Deferred loading of code. If there is a problem then we need to find
a solution. Why do you think we need to have the code around for the case BEFORE
the loading has been resolved?

Thanks,
-Ivan