> I thought the point of the discussion was turning off the GC until such time
> that it was ready to go. I know what it *does* - what should it *do*?
>
> {Rest of the comments snipped.}
I don't know quite what you mean by what 'should it *do*'? *do*, as in
what it should do with my patch? Or *d
> compared to a current CVS version of:
> 5000 generations in 90.813806 seconds. 55.057708 generations/sec
> A total of 32768 bytes were allocated
> A total of 130932 DOD runs were made
> A total of 10930 collection runs were made
> Copying a total of 57801936 bytes
>
> so a 97% decrease in the nu
> The current design never shrinks the free header pools, and indeed there is
> probably little point in doing so, so nothing seems to be gained from
> including them in the collection process.
>
> Using my favourite 5000-generation life.pasm as an example:
> A total of 10930 collection runs were
> > So you're saying that the calls to get memory during interpreter
> > initialization are somehow guaranteed to not require more memory (and thus
> > a dod or collection run)? Currently, this guarantee is not expressed in
>
> I don't understand the "thus." Nothing states that requesting memory
Dan Sugalski wrote:
> That's because GC_DEBUG is fundamentally broken by design. It's doing
> things it shouldn't be doing--the system is such that it shouldn't
> ever trigger GC before the memory allocation system is set up.
>
> If this patch disables the GC only when GC_DEBUG is in place, I'll p
The attached patch disables GC at startup. If you turn on GC_DEBUG, you'll
see parrot crash at startup because dod runs and collection runs are being
performed before the interpreter is fully initialized, causing all sorts
of havoc.
This also means that if our default GC allocation values do not
> >One option might be a
> >threshold - if, after the DOD run, there is still less than N headers
> >available, allocate more even though we can satisfy the immediate
> >requirement. This would improve performance by reducing the number of DOD
> >runs, but at the cost of additional memory - a clas
> So, I think #2 is the way to go. We'll add a new flag,
> (BUFFER|PMC)_stay_of_execution_FLAG or something, that gets added to
> allocated PMCs and Buffers. It'll be treated the same way as the
> constant/immortal flag is treated for DOD purposes, with one
> difference--there'll be an op which sp
> >destination register. Why would we *ever* care what's in the destination
> >register, since it never gets it's vtable methods called.
>
> That's not true. The destination needs its set method called.
> Otherwise tying/overloading won't work right.
Fair enough. I still have the problem brought
> I agree we need an overall architectural solution. Setting and clearing
> bits manually is error-prone but fast, as you said. Its identical to
> the malloc()/free() situation which is one of the primary reasons we
> use garbage collection in the first place, so why reinvent the same
> situation
I think I know of two potential performance problems with the GC code.
They could be problems in my head, or real problems, as I haven't done any
profiling. We also don't have any real test cases. :)
The first example is the following code, which calls parrot_allocate to
create the string each
> >This message does remind me of how empty the TODO list is. Surely we
> >can think of many more things to be done?
>
> Speaking of..
>
> 1) Bugfix release please, we banged quite a few stack and GC bugs out.
> Don't we get any dessert?
Peter has already stated he'd like his parrot_realloca
> The concern is that both functions are still using the same arenas, which
> means the original problems still wouldn't be solved, and we'd still have to
> do all the workarounds around them. ;-)
Yeah, but I can't go ahead changing this stuff, especially if all the code
isn't converted over to
> Why add new functions instead of patching the current ones?
I didn't know if the original functions still had a purpose. Perhaps you
would want to Parrot_allocate for something non-bufferish? Thinking about
it, that seems evilly wrong, so I guess that is not a valid reason. Doing
this would ma
> 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).
Heh, I thought the exact same thing when I first saw
> I made two assumptions for my test implementation of COW strings:
Wow, you already have a COW implementation? Great to hear!
> 1) we need to be able to share substrings as well as complete strings
> 2) COW must survive garbage collection
> Without these two, I believe the overhead probably outw
> #$bar = \$foo;
> new P1, PerlRef
> stash_load P0, "foo" #Not needed if P0 unchanged
> set P1, P0 #Make P1 reference P0 (not 'foo')
> stash_store P1, "bar"
My original example was like that, but I wasn't sure if that was a proper
use of 'set', since 'set' normally copies one into the other
> Remember that the higher level (eg perl6) will expect to be able to find the
> PMC afterwards. For example:
>
> $foo = "abc";
> $bar = \$foo;
> print $$bar;
> $foo = 3;
> print $$bar;
This depends upon how variables and the registers interact. If, like a
real CPU, registers must be stored back
I'm stuck at a fork in terms of how to fix this particular GC problem.
First, I changed all the direct vtable changes to use morph(). Morph does
a: destroy(), vtable change, and an init(). This is required because some
PMCs require GC-related initiailization, such as PerlStrings, which need
to st
I'm sorry, this new weapon is going to give a quick advantage to the fools
side, but luckily, should help the fool-proofers in the long run.
Below patch should be safe to apply, as it does nothing. Turn on GC_DEBUG
if you want to see the hell that ensues. I'm working on a patch to fix the
issues
> "Dan Sugalski" <[EMAIL PROTECTED]> wrote
>
> > With the recent stack and GC patches, are we pretty much solid now?
> > If so, a 0.0.5 bugfix release may well be in order.
>
> The one outstanding issue that I know of is the mem_realloc problem in
> add_pmc_to_free and add_header_to_free. Since th
> I've applied portions of this patch. I omitted the parts which use the
> "byte" type, which isn't going to work on all platforms.
I've changed these to use 'char'. Hopefully that will be more portable.
Mike Lambert
Index: misc.c
===
> It won't go in cleanly any more:
How about the below patch?
Mike Lambert
Index: stacks.c
===
RCS file: /cvs/public/parrot/stacks.c,v
retrieving revision 1.26
diff -u -r1.26 stacks.c
--- stacks.c29 Mar 2002 20:14:42 -
The following was applied by Dan, but from what I can tell, seems to have
become unapplied since.
Mike Lambert
Bryan C. Warnock wrote:
> Date: Fri, 22 Mar 2002 01:47:02 -0500
> From: Bryan C. Warnock <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PATCH] stacks.c
>
> Defer allocation as
> So then the above line:
>
> ># + SELF->data = value->cache.struct_val;
>
> Should be
>
> ># + SELF->data = value->data;
>
> Correct?
Those look good. Thanks for the catch.
Steve: wrt to the immortal name choice, if you like, I can submit a patch
changing the name to immune...I'm no
I've been using clintp's pasm test script for much of my testing, which is
supposed to be an infix expression evaluator. I've been stress-testing
parrot and finding bugs by putting increasingly-large expressions into the
pasm file for it to evaluate.
Attached is a .pasm file which causes some str
> Wow, you've got a couple of major patches floating around that are
> getting ignored. I don't feel so bad now. :-)
Yeah, that's why I'm combining all the GC patches into one big patch, in
the hopes it'll make it more appliable.
The only things I've sent out and am awaiting feedback for are the
The attached patch fixes a bunch of bugs. They are:
>From before, rolled into this patch:
+ Creates a new flag, immortal, which is intended for GC use only, so it
shouldn't be set in the init() function. This is used to prevent the GC
from dod'ing the object.
+ PerlString now stores the string po
FWIW, I've already submitted a patch which fixes this bug. I'm also about
to submit a patch which fixes it in a slightly better way, along with a
few of other (mostly GC) bugs I've tracked down tonight with the help of
clint's wonderfully abusive code.
The original email was:
http:[EMAIL PROTECTE
Hm...so I'm guessing my patch is the 'quick hacks' you tried and found
worked?
I agree my solution is a bit hackish. But I'm not sure how else to keep
them. The only other solution I can think of is to make a 'GC linked
list', which we put items on to immediately after construction, and take
them
Oh, yay. Orange tinderboxen rule, only because I haven't seen that much
orange in quite awhile. :)
Anyways, I looked into the bug. There's actually a few problems...First,
is that perlstrings use the structval to store the buffer, and so it gets
missed by the GC. The patch below fixes perlstring
Attached patch fixes many of the warnings you see on MSVC level 4. The
ones listed below, this patch does *not* handle.
core.ops and rx.ops have some warnings about the use of MAKE_KEY, and the
non-use of the variables returned by MAKE_KEY. I believe Steve Fink's
patch fixes these.
io_win32.c
Attached are my revised files. pbc2c.pl uses Parrot::OpTrans::Compiled,
and this patch uses Parrot::OpTrans::CGoto. It also fixed the issues with
the last patch:
- removed inadvertant keyed commenting
- fixed #include name
- fixed pbc2c.pl
- should have unix line endings
Please let me know if th
> The patch is slightly broken, core_cg_ops.h in interpreter.c versus
> core_ops_cg.h everywhere else.
I tried to do a global change to make it use core_ops_cg.h, following
prederef's example. I must have missed this one. (Still runs, just gives a
warning.)
> It does take a while to build the co
good point about helping to maintain who's doing
what as the parrot development group of people grows larger. Isn't this
what bugs6.perl.org was supposed to be for?
Mike Lambert
Melvin Smith wrote:
> Date: Wed, 27 Mar 2002 03:08:18 -0500
> From: Melvin Smith <[EMAIL PROTE
The introduction "make quicktest" made this missing .cvsignore more
apparent.
Mike Lambert
*.pasm
*.pbc
*.out
Attached is a patch to implement computed-goto on gcc, taken from the
original post by Daniel Grunblatt:
http:[EMAIL PROTECTED]/msg06255.html
Changes since his original patch:
+ works with the current codebase
+ handles all jumps properly, and passes all tests (I'm not sure,
but I don't believe t
Hey,
After going through and hopefully learning the GC system yesterday, today
I went through looking for problems in the code that uses it (or doesn't
use it, as the case may be). Below are what I believe to be potential
problems in Parrot's memory use. I may very well be mistaken on many of
the
h Wilmes <[EMAIL PROTECTED]>
> To: Michel J Lambert <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCH] tabs->spaces fix
>
>
> Mike,
>
> that doesn't want to apply for me- i suspect that the patch got garbled in
> the mail. Can you MIME-a
Below is a fix for the use of tabs in test_main.c and resources.c.
Mike Lambert
Index: resources.c
===
RCS file: /cvs/public/parrot/resources.c,v
retrieving revision 1.33
diff -r1.33 resources.c
23,24c23,24
<
Below is a cleanup patch for a comment or two, some flags missing, that I
did while reading through it all in an attempt to figure it all out.
I was impressed with how straightforward all the code was, but there were
a few things that confused me. If you answer these, I can provide
documentation
> Could you also provide a patch (or at least comments in the code) that
> describe the limiations?
This satisfactory? (I didn't mention it in the README because that's
supposed to be simpler instructions sans caveats, imo)
Mike Lambert
Index: docs/running.pod
==
Below is a patch to fix the two warnings about const-ness I get in
string.c. This should also fix the tcc build on tinderbox. Hopefully this
spot-fix to the const-ness problems won't cause further const-ness
problems farther down the line.
Mike Lambert
Index: include/parrot/string.h
Times are:
make quicktest, after caching output: 23 seconds
make test: 175 seconds
make quicktest could screw up if:
- you ctrl-c it, or make test (although I haven't had problems with that
yet) during the compilation process at just the right time
- you do anything to invalidate existing .pbc fi
Ooops. I originally did the /**/, but thought that was way too easy to be
C code, and so changed them to //. :)
Below is a proper patch.
Mike Lambert
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1
We take in const params, and set them into non-const members of STRING:
string.c(51) : warning C4090: '=' : different 'const' qualifiers
string.c(55) : warning C4090: '=' : different 'const' qualifiers
Due to MAKE_KEY in set_keyed setting keys[0] on an uninitialized pointer.
But I hear this isn'
Heya,
I submitted a bunch of patches awhile back, all of which were committed
except for one, which dealt with adding a 'make quicktest'. Information on
it can be found here:
http:[EMAIL PROTECTED]/msg07834.html
It did provide for a significant speedup, from 170 seconds using 'make
test' to 24
> Yes. We will, for actual method and sub dispatch. Not for the other
> vtable methods, though.
I guess my big 'complaint' was against using vtables for the variety of
operators, due to the inherent asymmetry in them. I knew Perl6 is going to
have MMD, but I didn't know how deep that support is g
Heya,
I was curious if anyone has ever considered implementing multimethod
dispatch (MMD) directly into parrot. In my opinion, this would provide
several benefits over the current system. While (IMHO) MMD provides many
benefits over the current system in terms of extensibility and ease of
maintai
49 matches
Mail list logo
