On Mon, Dec 26, 2016 at 10:18:05PM +0100, demerphq wrote: > An obvious solution to this would be to refcount the stack. However > even if we assume this is possible (I am doubtful), it would probably > be slow. I seem to recall that MS did some studies with VB and > refcount manipulation of stack arguments can account for 25% of run > time, which is why dotNet is garbage collected. But in practice large chunks of pp code mortalise the values they push on the stack to make them last long enough to be usable for the next op, but without leaking. So we normally encounter the cost of manipulating the ref count anyway, with the added costs of checking/extending the mortals stack as well as the args stack, and pushing the SVs onto both stacks. So making the args stack ref counted would quite likely be a net performance gain (assuming we got rid of the now superfluous mortalisation), in addition to fixing all the bugs. The insanely difficult bit is that we currently have nearly 30K lines of code in the pp functions which all assume they can just do SP-- or SP -= n without worrying about what's on the stack. Or to croak with rubbish still in the stack, We would either have to review and modifiy *all* that code, or come up with a scheme whereby individual pp functions can be marked as "refcount ready" > My > understanding is it is rare to unheard of for real code to tickle > stack-not-refcounted bugs, it only happens when people do crazy stuff > that nobody would do in real code anyway. It's quite easy to tickle stack-not-refcounted issues. E.g. @a = (1,2,3); for (@a, 4) { @a = (); print $_; } which croaks with Use of freed value in iteration at ... or sub f { @a = (); print $_[0]; } @a = (1,2,3); f(@a); which prints nothing, but can easily print garbage if the freed SV happens to get reallocated. -- Any [programming] language that doesn't occasionally surprise the novice will pay for it by continually surprising the expert. -- Larry WallThread Previous | Thread Next