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
mandates
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 made
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 number of
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 *do*,
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
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 put
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 classic
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 up in
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
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
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
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 with
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
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
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
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
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 into
#$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. Of
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
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
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 the problem is
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
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
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
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 not too attached
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 long
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 -
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
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
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
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
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
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
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
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
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
The introduction make quicktest made this missing .cvsignore more
apparent.
Mike Lambert
*.pasm
*.pbc
*.out
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 PROTECTED]
To: Michel J Lambert [EMAIL
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
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
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
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
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
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
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
45 matches
Mail list logo
