Help! Bugs! Crawling all over!
Steve Fink
haven't had much time available, and partly because there are
gc-related bugs lurking in the code that I regard as higher priority.
I tried tracking them down, but somewhere in the middle I realized
that I really ought to be trying to put together a 0.0.9 release
instead.
So, I just checked in something that breaks 'make test' for everyone:
GC_DEBUG is now on by default for tests. (But _only_ for tests -- the
parrot executable still has it off by default.) I reworked it so that
it is a property of the interpreter and can be enabled and disabled at
runtime via the --gc-debug flag to parrot, or by setting the
$PARROT_GC_DEBUG environment variable. In fact, it should be possible
to toggle it in the middle of a run, but I haven't tried it -- it
changes the parameters to the memory management system, so turning it
on halfway through a program might do strange stuff.
This slows parrot down by about 7% when debugging is turned off (on my
machine, for lifetest). So there is also a DISABLE_GC_DEBUG #define in
include/parrot/parrot.h that may be turned on for optimized builds.
For a -O3 compile on my system, I get a 1% slowdown over the previous
CVS version when running without the jit, and a 1% speedup when
running with the jit. Or, in other words, no measurable overhead.
(Which is unsurprising; it just means I didn't break anything.)
I currently get three test failures when running with GC_DEBUG on, but
not always the same three (depending on how I muck with unrelated
parts of the code.)
The slowdown when GC_DEBUG is turned on is... more than 7%. It isn't
too bad for most of the tests or mopstest, but for lifetest I get a
factor of 140x slowdown. Heh. It also turned out to be too annoyingly
slow for t/op/stacks.t test #7 and t/pmc/intlist.t tests #3 and #4. I
don't want to make the tests too onerous to run, so I put in a
not-so-pretty hack to disable GC_DEBUG for just those three tests,
when running under 'make test' or a variant. It's documented in the
makefile and in those tests.
Peter Gibbs
> I currently get three test failures when running with GC_DEBUG on, but
> not always the same three (depending on how I muck with unrelated
> parts of the code.)
On my system I get failures with op/string.t tests 96 and 97 and
pmc/pmc.t test 76 (aka 75)
The first two can be fixed by the patch below.
The last one looks like a fundamental problem in MultiArray.
The line
b->cell_buffer = new_buffer_header(interpreter);
in function new_marray is creating a new buffer header, overwriting
the new_bufferlike_header created earlier.
--
Peter Gibbs
EmKel Systems
Index: string.c
===================================================================
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.99
diff -r1.99 string.c
166c166,167
< a->flags &= ~(UINTVAL)BUFFER_constant_FLAG;
---
> a->flags &= ~(UINTVAL)(BUFFER_constant_FLAG | BUFFER_COW_FLAG
|
> BUFFER_external_FLAG);
Steve Fink
> Steve Fink wrote:
> > I currently get three test failures when running with GC_DEBUG on, but
> > not always the same three (depending on how I muck with unrelated
> > parts of the code.)
>
> On my system I get failures with op/string.t tests 96 and 97 and
> pmc/pmc.t test 76 (aka 75)
>
> The first two can be fixed by the patch below.
>
> The last one looks like a fundamental problem in MultiArray.
> The line
> b->cell_buffer = new_buffer_header(interpreter);
> in function new_marray is creating a new buffer header, overwriting
> the new_bufferlike_header created earlier.
Yes!! Thank you! I am now getting just the one error you're seeing
too.
Earlier I also saw an error in sprintf.t. In fact, I still have a
patch in my tree for it. The error was only triggered by gc, but
seemed to be wrong regardless. I'll have to look at it again; I could
have been fooling myself.
Patch applied, with much rejoicing.
Steve Fink
> The last one looks like a fundamental problem in MultiArray.
> The line
> b->cell_buffer = new_buffer_header(interpreter);
> in function new_marray is creating a new buffer header, overwriting
> the new_bufferlike_header created earlier.
I didn't really read enough of the code to know whether this is doing
at all the right thing or not, but here's a trial patch that makes the
test failure go away on my machine, at least. Josef, can you take a
look? Apply with patch -p0 < multiarray.patch in the parrot directory.
Steve Fink
Oops. That patch is missing one s/cell_buffer/buffer/. But the patch
is big enough that I won't spam the list with it again; if you apply
it, you'll need to fix the compile error first.
But really, I just like replying to myself.