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' whi
> > 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. Toda
> 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 nee
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 buf
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
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
