Re: Garbage collector vs variable lifetime
Re: Garbage collector vs variable lifetime
- Subject: Re: Garbage collector vs variable lifetime
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 07 Jun 2008 17:23:15 -0700
On Jun 7, 2008, at 3:51 PM, Hamish Allan wrote:
Sorry to reply to myself, but I just remembered that pointers in
registers are also in the root set! That said, I don't think it
changes the substance of my proposal: that stack variables (i.e.
variables semantically placed on the stack by the programmer) should
remain in the root set until they are out of scope (i.e. semantically
no longer in the current stack frame).
That leads to significantly slower code. If you have some C based
performance test suite available, compile it at the different
optimization levels and see how the numbers change. You can even turn
on/off specific optimizations and see the impact.
In particular, a common optimization is to use registers to store
local variables and/or arguments. This would no longer be viable if
the compiler couldn't recycle locals when they fall out of scope. Or
it would be exceedingly expensive as the compiler would have to
generate code to save and restore registers across call sites.
Consider:
{
int foo;
... calculate on foo ...
int bar = getirdone(foo);
while(1) {
func(bar);
func2(bar);
... etc ...
}
}
Without being able to recycle the space used by foo and bar, the
compiler will generate code the pays the price of that space being
consumed for all of the while loop, which could be the vast majority
of the run time of the application.
As well, if foo / bar fall in a register, then those registers would
have to be preserved for all of the while loop, too, either by not
being available to the bulk of the program (which raises some serious
codegen issues) or being moved out/in the registers every time one of
the funcs in the while loop is called or returns.
One of the tenets of GCC is that *it controls the layout of the stack
always* and this is done quite explicitly because of performance.
b.bum
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden