Port faster callbacks invocation to x64.

Port faster callbacks invocation to x64.
    
It's a port of http://code.google.com/p/v8/source/detail?r=3209 to x64 platform.
That allows invocation of callbacks without going into runtime.

Committed: http://code.google.com/p/v8/source/detail?r=5141

[antonm, 2010-07-23 12:17:39]

Bill,

may you have a look?

I've tested it on Ubuntu (gcc), MacOS (gcc) and Win7 (vs).  Any other platforms
I should take care off?

src/ia32: mostly cosmetic changes.

I'm not quite happy with #ifdef _WIN64 in src/x64/stub-cache-x64.cc.  For
register allocation I considered to add methods like
name_arg_reg()/accessor_info_arg_reg() into ApiGetterStub, but that is only
applicable on x64.

I tried to move allocation of handle into stub Generate, but didn't manage to
cope with frames management (but my knowledge of this part is weak).

Any advice is most appreciated.

[William Hesse, 2010-07-27 13:10:11]

LGTM.  This is very complicated stuff.  More comments, both on this and on the
parallel ia32 platform, would be welcome.

http://codereview.chromium.org/2801008/diff/10001/11008
File src/x64/macro-assembler-x64.h (right):

http://codereview.chromium.org/2801008/diff/10001/11008#newcode735
src/x64/macro-assembler-x64.h:735: // Tail call a code stub (jump) and return
the code object called.  Try to
Put this declaration in the same place as on ia32, after TailCallStub().

http://codereview.chromium.org/2801008/diff/10001/11008#newcode779
src/x64/macro-assembler-x64.h:779: // ensuring that saved register, it is not
no_reg, is left unchanged.
I don't understand this sentence.  What if it is no_reg?  What if it is not
no_reg?  Does it save it?

http://codereview.chromium.org/2801008/diff/10001/11009
File src/x64/stub-cache-x64.cc (right):

http://codereview.chromium.org/2801008/diff/10001/11009#newcode2219
src/x64/stub-cache-x64.cc:2219: Register other = reg.is(scratch1) ? scratch2 :
scratch1;
What is the benefit of not just using scratch2 always?
OK, I see this is just what is done on ia32.  But maybe it
should be changed there too.

http://codereview.chromium.org/2801008/diff/10001/11009#newcode2259
src/x64/stub-cache-x64.cc:2259: // object.
Do we have guaranteed semantics about whether the callback is called exactly
once, even in the presence of GCs?

[antonm, 2010-07-27 14:55:14]

Bill,

thanks a lot for review.

Could you point out places which were especially difficult to understand?  I
would happily add comments, but cannot immediately see which places lack them
most.

http://codereview.chromium.org/2801008/diff/10001/11008
File src/x64/macro-assembler-x64.h (right):

http://codereview.chromium.org/2801008/diff/10001/11008#newcode735
src/x64/macro-assembler-x64.h:735: // Tail call a code stub (jump) and return
the code object called.  Try to
On 2010/07/27 13:10:11, William Hesse wrote:
> Put this declaration in the same place as on ia32, after TailCallStub().

Done.  Plus some more declarations.

http://codereview.chromium.org/2801008/diff/10001/11008#newcode779
src/x64/macro-assembler-x64.h:779: // ensuring that saved register, it is not
no_reg, is left unchanged.
On 2010/07/27 13:10:11, William Hesse wrote:
> I don't understand this sentence.  What if it is no_reg?  What if it is not
> no_reg?  Does it save it?

Yes.  It saves a register unless it's not no_reg.  But grepping through the code
shows we never invoke that with no_reg, so I think I'd drop this functionality,
it's trivial to add if needed.

http://codereview.chromium.org/2801008/diff/10001/11009
File src/x64/stub-cache-x64.cc (right):

http://codereview.chromium.org/2801008/diff/10001/11009#newcode2219
src/x64/stub-cache-x64.cc:2219: Register other = reg.is(scratch1) ? scratch2 :
scratch1;
On 2010/07/27 13:10:11, William Hesse wrote:
> What is the benefit of not just using scratch2 always?
> OK, I see this is just what is done on ia32.  But maybe it
> should be changed there too.

Good catch. Done.

http://codereview.chromium.org/2801008/diff/10001/11009#newcode2259
src/x64/stub-cache-x64.cc:2259: // object.
On 2010/07/27 13:10:11, William Hesse wrote:
> Do we have guaranteed semantics about whether the callback is called exactly
> once, even in the presence of GCs?

Sorry, I don't quite understand your question.  Yes, it's possible that
invocation of a callback leads to invocation of the same callback and triggers
GC as well.

However, if you're concerned with the comment above, it's about GC while
generating the code, not executing it.