On Wednesday 03 April 2002 01:05, Peter Gibbs wrote: > > > > or something else similar. > > My first thoughts on this are that we should go the whole way, and have > Parrot_allocate take a Buffer* and a requested size, and let it fill in the > bufstart and buflen parameters (as in the not-yet-implemented > Parrot_reallocate patch).
Yeah, I wasn't quite brave enough to suggest this. > > This would cause problems for anybody trying to use Parrot_allocate to > create temporary storage; however, that is a highly dangerous thing to do > anyway without taking the possible impact of GC into consideration. > The only place I can find a call to Parrot_allocate that does not place the > resulting pointer into a buffer is in the code for 'open' in io.ops. This > code is interesting anyway, because it will fail if the second allocate > attempt triggers a collection; Yes, this is something Dan and I discussed last weekend. We need to turn off the GC when doing a single allocation that involves multiple allocation requests, so that it's not collected halfway through, but what happens if we find ourselves *needing* to do GC to complete the request? (Actually out of resources?) Of course, as Dan pointed out, since we're using a compactor, if we're out of memory, we're SOL, because the GC will fail, too. (I think what we need to do is something akin to Perl 5's emergency memory pool.) We probably need to turn off GC before doing a multl-layer allocation request, but still leave an emergency back-door open to be able to do it off of an exceptional trigger. But then we're back to, how do you keep what you've done so far from being collected? I don't like the temporary DONT_COLLECT_ME_YET flag, because we're having to set and clear that flag on every allocation request, and the GC has yet another flag to test against. (Although it would be tested simultaneuously with the CONSTANT flag, I would think.) That's very much a wolf in ref-counting's clothing. The GC does have some fringe cases that can blow performance out of the water (as most do, but the current one makes it pretty easy to exercise such cases.) Dan's returning from his whirlwind speaking tour today, I think. We had talked a little about this; I'm not sure how much or little he wants to change (now that he's thought about it for a while). I'd say, let's fix the bug with the buflen not representing the actual allocation size (which it looks like Mike Lambert's roll-up patch does) so we have the option of shipping 0.0.5 out the door, and then we'll address the larger questions later. -- Bryan C. Warnock [EMAIL PROTECTED]
