[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]method calls and extra indirection

From: Llewellyn Pritchard
Subject: Re: [DotGNU]method calls and extra indirection
Date: Fri, 2 Apr 2004 19:10:56 +0200

I have noticed something, maybe I am missing something, here goes.

As per the notes of Gomi Kapoor <address@hidden>:
"But one potential problem with the above implementation is, it is not
possible to declare any local variables in the ``part'' files. All of
them have to be in the main file and it becomes a bit difficult to
manage in such a situation. Similar is the case if we need to have
helper functions in the part files."

Now lets take the implemetation (eg):

 /* Call a native method that has no return value */
 FFI_CALL(CVM_ARG_PTR2(void *), CVM_ARG_PTR(void *), 0, nativeArgs);
 pc = thread->pc;

Now my question is, why/what prevents you from declaring locals here (this
specific example is a bit stupid)? I dont see this in any of the CASES.



----- Original Message ----- 
From: "Rhys Weatherley" <address@hidden>
To: "Gomi Kapoor" <address@hidden>; "pnet" <address@hidden>
Sent: Friday, April 02, 2004 9:28 AM
Subject: Re: [DotGNU]method calls and extra indirection

On Friday 02 April 2004 01:23 am, Gomi Kapoor wrote:

> I am using the current release 0.6.4
> I read the pnet/engine/HACKING file and then tried to
> look for the same in the code.

I'll try to remember to fix that, as it is out of date.  You should always
check the code as well, because sometimes I forget to update the HACKING
to reflect the current situation.  The instructions are very well documented
in the code.

> OK, so can we say there is an always an indirection
> overhead for every method call?

The "call" instruction takes a pointer to an ILMethod control block, which
turn contains the pointer to the start of the converted method code.  So
an indirection is always required.

However, you should not assume that just because an indirection is required
that it is therefore slow.  The vast majority of the method call overhead is
involved in setting up the new stack frame.  Fetching the method code
is a very small part of the total time needed.

If you wish to optimize method calls, you should look at the frame setup
overhead.  Eliminating the need to save even one field in "ILCallFrame"
impact performance much more than fancy back-patching schemes on the "call"



Developers mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]