Optimized nodeType dom binding by removing HandleScope and the preparation of ordinary c function c…

Optimized nodeType dom binding by removing HandleScope and the preparation of ordinary c function call.

In nodeType getter callback, it does not New objects, so it’s
safe to remove HandleScope().

And in ordinary C function, it create a new frame(push ebp/pop ebp)
to store arguments. But for some straightforward getter, like
nodeTypeAttributeGetter, By removing this preparation, it can improve
nodeType api performance by 30%.

BUG=v8:3667

[yaojie.yan, 2014-10-31 07:52:06]

Patchset #1 (id:1) has been deleted

[yaojie.yan, 2014-10-31 07:56:45]

yaojie.yan@intel.com changed reviewers:
+ danno@chromium.org, dcarney@chromium.org, verwaest@chromium.org

[yaojie.yan, 2014-10-31 08:03:43]

In the binding side, the jit hint can be set as below:
v8::Local<v8::Accessor> ac = instanceTemplate->SetAccessorEx(…)
if (!ac.IsEmpty()) ac->setOptimizeLevel(v8::Accessor::kOptimizeInline);

Could you help to review it? and thanks very much for any of your comments.

[dcarney, 2014-10-31 08:37:50]

> Could you help to review it? and thanks very much for any of your comments.

this is fundamentally okay, and indeed it's something i've thought about before,
but it creates an api that's easy to break.  If you forget to create a handle
scope in the callback if you happen to need one, very bad things can happen, and
they would be hard to track down.  We have an overall strategy for this type of
case, and it's to never leave javascript and perform the dom operations directly
there, instead of trying to optimize the cost of calling out to c.

[yaojie.yan, 2014-10-31 08:50:41]

On 2014/10/31 08:37:50, dcarney wrote:
> > Could you help to review it? and thanks very much for any of your comments.
> 
> this is fundamentally okay, and indeed it's something i've thought about
before,
> but it creates an api that's easy to break.  If you forget to create a handle
> scope in the callback if you happen to need one, very bad things can happen,
and
> they would be hard to track down. 
[Based on my current knowledge, it should work in this case, because the new
handler will be maintained by their parent's handerScope in most case, I will
verify this case.]
 We have an overall strategy for this type of
> case, and it's to never leave javascript and perform the dom operations
directly
> there, instead of trying to optimize the cost of calling out to c.
[Do you mean Blink-In-JavaScript by the overall strategy?]