On Sun, May 19, 2002 at 10:43:20PM -0400, Mike Lambert wrote:
[...]
But if you'll notice down below in the body, it uses
string_compare. Due to transcoding issues, that can trigger a full GC,
which means you need to restore_invariants inside that loop. And that
invalidates your 'chain' which
On Mon, May 20, 2002 at 10:53:46PM +0200, Peter Gibbs wrote:
Steve Fink wrote:
Is there some way to make the default be that things will not get
moved around, and allow routines to volunteer to have their guts
scrambled if they know how to handle it?
A few random thoughts re buffers
Ok, I'll finish off the original conversion to indexed access that I
began once, before giving up in disgust. The problem is not just that
you have to use indices instead of pointers; it's also that you have
to constantly go back to the buffer header before you can get
anywhere. That needs
Something about the whole setup just feels wrong. GC shouldn't be this
intrusive. And it definitely shouldn't slow down the common case by
making the compiler defensively reload a buffer pointer every few
instructions (it'll be cached, but it fouls up reordering.)
Alright. Today I
On Sun, May 19, 2002 at 10:43:20PM -0400, Mike Lambert wrote:
I started to look into the GC crashes with the perlhash tests. I'm not
sure I found the exact problem, but I found a bunch of dangerous things
that were being done, and could possibly cause the GC problems.
restore_invariants is
Steve Fink wrote:
Is there some way to make the default be that things will not get
moved around, and allow routines to volunteer to have their guts
scrambled if they know how to handle it?
A few random thoughts re buffers that don't wander around on their own:
Create a new memory pool for