At 5:11 PM -0500 11/16/02, Erik Lechak wrote:
Hello all,
I have been away for a while. I started writing my own version of parrot (or at least chunks of it) so I can get a feel for the current parrot internals. I have learned a lot and now realize why some things were done the way they were.
Cool, that's a good thing. The next question is "Did we screw up somewhere?" :)
I am on memory management now and my implementation is different from that of parrot. I would just like to outline it so that if there is any interest in the code I can provide it to you. I'm not suggesting that parrot implement this technique, but it may spur the creative thinking in someone with their fingers already in the cookie jar.Other than the problem that most people don't want what they actually need, a problem that seems to plague tunable memory management schemes, it seems a good idea. I'm pretty sure we don't want to be switching memory managers in the middle of an interpreter's run, though. It seems like that would lead to more complications than it'd be worth, though I could be very wrong there.
First of all it looks as though there is no one perfect memory management technique. There are a lot of papers and several different techniques. An individual technique may be close to optimum for a certain type of application, but may be poor in another. Even in the same program some chunks of memory may be highly dynamic, while others are fairly static. So I figure that there is no reason to treat all memory the same, I would like future advances to just plug in, I don't want to force a hard-coded memory management scheme on someone who knows exactly what they want.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
