I won't insist on it. I only though that if we try to reduce the path from stub to callback, we should try to squeeze out as many instructions as possible. For example, allocating a handle in handle scope is hardly ways more costly than double indirect load. I agree alignment is an issue. It only occurred to me that we can use the same trick as for pointers of internal fields: if stored 'address' is properly aligned, it's a native function pointer and we go with it. If it's not, we've got a proxy and let's get an address in regular way. On platforms for which we're sure that 'normal' functions addresses are aligned, we don't have to have a conditional logic in stub compilation code. Otherwise we'll do that.
I would leave it for you and reviewers judgment if we'd like to see this schema in a real code though. yours, anton. On Fri, Jul 24, 2009 at 7:43 PM, <[email protected]> wrote: > > http://codereview.chromium.org/160041/diff/1001/1004 > File src/stub-cache.cc (right): > > http://codereview.chromium.org/160041/diff/1001/1004#newcode742 > Line 742: Address getter_address = > v8::ToCData<Address>(callback->getter()); > On 2009/07/24 13:45:38, Vitaly wrote: >> >> On 2009/07/23 21:12:58, antonm wrote: >> > maybe compile getter_address into stub as well? As you told me on > > ia32 it >> >> > should be probably safe as the address would be aligned, do you know > > if it's >> >> > still the case for ARM? And x64? > >> I think this essentially means moving a few instructions from here to > > the stub >> >> cache code. So I don't see how it makes a difference at this point. > > Anton pointed out in offline discussion that we store the address > indirectly using a Proxy object. Unfortunately, putting it in the stub > code directly besides requiring extra care with respect to alignment > doesn't make any difference according to my measurements. > > http://codereview.chromium.org/160041 > --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
