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
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
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
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
but wait, there's more... what does:
multi_dim[$a][$b][$c]
give?
It's representation hiding. I can change my layout from hashes to arrays
without the clients of my code having to know. :)
Seriously, the above argument might actually hold some merit when changing
a matrix to a sparse matrix
I could see something like:
method operator.( $self: $function ) {
if( $function eq inc ) { ++%self.funcount{$_[2]}; }
else { $self.inc( $function ) }
}
That would count how many times you called each function.
Sounds a lot like aspect-oriented programming. If what you want is
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
#$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
Too late. I'm going there... :)
Good for you. I was hoping transformations could make it :)
Why didn't you chime in support before, then? I feel like Aaron and I are
the only ones who are opinionated on this matter...
Here's something I was wondering. Say you wanted to write a pow() macro
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
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
An example of where variable capture is needed is:
macro println ($a) {
return EOF;
print $a;
print \n;
EOF
}
for my $b (1..100) {
println $b;
}
And, if we inline the sub, the only difference will be...?
Okay, a bad example, in that it could be better done in other
New syntax is 'qs', aka quote sub, which is similar to q, except that it
interpolates all of: ${..} {..} and %{..}
All subroutines which are interpolated, are interpolated as regular text,
with no bindings, so that they get lexically scoped in the code they are
returned as part of.
Then macros
Basically, one of the goals of Perl6 was to allow for you to implement any
perl construct, in perl. None of the operators were to use any special
features that could not be done by regular subroutines. And personally, I
don't see how we're going to be able to do all this lazy evaluation of
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
I searched the archives with Google (what, no internal search engine??),
and found the thread on perl6 macros, which I did read.
From what I saw, it mostly concentrated on using macros for speed. That
should be a minor argument, especially considering this is perl. :)
Common Lisp macros are
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
macro foo($a,$b) {
return( $c // $a+$b );
}
print foo(1,2), \n;
my $c=100;
print foo(1,2) \n;
Yeah, your example provided is correct. It's called variable
capture, and there's some work required by common lisp macros to
ensure that unwanted variable capture does not occur.
I don't
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 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
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
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-attach or uuencode it?
--Josh
At 23:17 on 03/25/2002 EST, Michel J Lambert
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
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
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
52 matches
Mail list logo