Introduce a lazy-compile stub for functions.

Introduce a lazy-compile stub for functions.

The function's code pointer is either a lazy-compile stub
or the compiled code. The function is compiled on invocation.

There is no need to check for null when invoking a function. This means
one check less when invoking functions via a stub. For this I added a  LazyCompile
stub.

Additional cleanup in Stackmap and PcDescriptors (remove unused code pointer,
and changed smi-lengh into a raw integer).

R=zra@google.com

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

[Florian Schneider, 2014-03-19 17:17:15]

+cc srdjan, iposva

This is one more step on the way to redoing closure calls. I'll do the same for
method calls, so that we never have to check the function's code pointer for
null again.

[Florian Schneider, 2014-03-21 10:41:30]

On 2014/03/19 17:17:15, Florian Schneider wrote:
> +cc srdjan, iposva
> 
> This is one more step on the way to redoing closure calls. I'll do the same
for
> method calls, so that we never have to check the function's code pointer for
> null again.

Ping?

[zra, 2014-03-21 14:44:31]

https://codereview.chromium.org/203523011/diff/40001/runtime/vm/raw_object.cc
File runtime/vm/raw_object.cc (right):

https://codereview.chromium.org/203523011/diff/40001/runtime/vm/raw_object.cc...
runtime/vm/raw_object.cc:376: (fn.CurrentCode() == fn.unoptimized_code()) &&
I think you also need to modify this logic, otherwise closures will never be
collected.

[Florian Schneider, 2014-03-21 15:13:58]

https://codereview.chromium.org/203523011/diff/40001/runtime/vm/raw_object.cc
File runtime/vm/raw_object.cc (right):

https://codereview.chromium.org/203523011/diff/40001/runtime/vm/raw_object.cc...
runtime/vm/raw_object.cc:376: (fn.CurrentCode() == fn.unoptimized_code()) &&
On 2014/03/21 14:44:31, zra wrote:
> I think you also need to modify this logic, otherwise closures will never be
> collected.

Yes, thanks. This also means that collection of closures is untested.

[Florian Schneider, 2014-03-31 11:10:56]

Any more comments?

[zra, 2014-03-31 20:49:03]

lgtm with questions.

Sorry for the long delay. Hadn't seen the updated change.

What is the performance impact?

Before this change there was no difference between GC of closures and GC of
other functions. Now that there is a difference, I agree that we should have a
test for that. Would you like to write it, or would you prefer that I take a
crack at it?

[Florian Schneider, 2014-04-01 15:06:17]

On 2014/03/31 20:49:03, zra wrote:
> lgtm with questions.
> 
> Sorry for the long delay. Hadn't seen the updated change.
> 
> What is the performance impact?
> 
> Before this change there was no difference between GC of closures and GC of
> other functions. Now that there is a difference, I agree that we should have a
> test for that. Would you like to write it, or would you prefer that I take a
> crack at it?

The current version of the patch actually handles all functions (instance
methods, static methods and closures).

Closure calls are faster with my CL. I'm investigating a ia32 specific negative
effect which is not fully understood yet.

[Florian Schneider, 2014-04-02 12:38:09]

Committed patchset #6 manually as r34643 (presubmit successful).