the copying collector runs, it could see a dead buffer and want to copy
it. So we'd better make sure that buffer's not pointing to garbage memory
or it'll be coping random stuff from who-knows where and likely GPF. :)
Mike Lambert
Second:
intlist is not the only culprit. ./classes/key.c and ./key.c have a
similar problem.
Mike Lambert
ugh, if nested structures inside the interpreter are all buffers,
> destroying them would neatlessly fit into the framework.
Yes, it would. But a lot of the interpreters structures have data fields,
and those don't work too well as buffer data. They could work as part of a
sized buffer header, I s
rs
have to be PMC/buffers. Just as we have an make_interpreter to create an
interpreter, we can have an unmake_interpreter that destroys the
interpreter. I don't think we want interpreters appearing and
disapppearing with references...they should be explicitly created and
destroyed. But that's a discussion for another thread. My point is that
all things don't need to be traced, and some stuff can be handled
manually, as long as the perl programmer doesn't see it directly.
Hope this helps answer your questions,
Mike Lambert
ction is failing.)
> I didn't look further into memory usage or such, though top seems to
> show ~double the footprint of CVS.
I think Dan would disallow such a patch for this reason alone. We're
already taking a 2x hit (peak) by using a copying collector. No need to
make it worse. :)
Mike Lambert
ately, is it possible to allocate this jump
table in the system heap (malloc et al), and store only a pointer to it on
the stack?
Mike Lambert
ould be removed from the
> tinderbox.
Yes, I had noticed that. And that struct me as strange, particularly
because that machine had worked before, but isn't working now. I'll remove
it from the list of machines it connects to.
Mike Lambert
type on top of stack!
# '
# expected: '678910
# 1112131415
# '
The first was a GPF, the second was just incorrect output.
I'm not sure if this is progress or not, but I believe it might adversely
affect other platforms. I don't have time to look into the issue now, but
I'll try to do so tomorrow.
Mike Lambert
e still buggy
> > with respect to supporting different encodings. I don't know if
> > printf("%s") is any better than fwrite in terms of at least vaguely
> > paying attention to your locale or whatever. If so, don't apply it.
> >
> > (all tests pass)
Applied, thanks,
Mike Lambert
/perl6/P6C/TestCompiler.pm, since
> it hijacks lib/Parrot/Test.pm to get its functionality. I'll probably
> apply this after the code opens up again, but if someone beats me to it,
> please be sure to update the affected file above.
Applied, thanks,
Mike Lambert
k 1
# ok 2
# ok 3
# ok 4
# ok 5
# ok 6
# ok 7
# ok 8
# ok 9
# ok 10
# '
No idea on where the missing "ok 10" went.
If people would like the p6/imcc/pasm/pbc files,
I can provide them. Just let me know.
Mike Lambert
idea on how to go about fixing the rx ones? They're failing on
imc->pasm, with msgs like "NO Op rx_pushmark_ic (rx_pushmark<1>)"
Mike Lambert
Index: config/gen/makefiles/imcc.in
===
RCS file: /cvs/public/parrot/co
nt them to act. As such, the above argument could be
correct or incorrect depending upon exactly how they are defined. :)
Mike Lambert
hat a static interface doesn't change
behavior on us, etc.
Currently however, neither a nor b are implemented, and so the t/src/*
test have no direct dependancy upon libparrot.a/lib and libparrot.so/dll,
and so can probably be removed. If it helps make 0.0.8 build on more
platforms, it might b
lt of unimplemented
external-ness, in which case, applying Steve's fixes should make this
problem go away.
Mike Lambert
re any fundamental reason why we *cannot* just enter a generated
imcparser.c and imcparser.h into CVS and save users the step of building
them on these platforms? It's just an additional parrot depenendancy which
doesn't need to be there, and may come in handy when trying to build on a
lot of the more arcane platforms.
Mike Lambert
ds. I wanted to get a simple interface
implemented for using COW, such that it would be easy to understand, and
then later optimize it for actual usage scenarios. I imagine that
unmake_COW could be extended to take 'pre' and 'post' byte arguments, and
would pad the resulting s
imagine we could either:
a) make them act identically, like this patch does
b) just have people who want external data to unset selfpoolptr.
Thoughts?
Mike Lambert
llected. I agree with the resources.c patch to
fix external, but I'm not sure about this one.
Mike Lambert
apply this once Parrot 009 starts up again. Although at some point,
we should go 100% in converting the IO in core.ops to use parrot io, or
convert the tests/programs over to using io.ops. (Not sure which way we
want to go.)
Mike Lambert
pm, since
it hijacks lib/Parrot/Test.pm to get its functionality. I'll probably
apply this after the code opens up again, but if someone beats me to it,
please be sure to update the affected file above.
Thanks,
Mike Lambert
)
> The following patch changes the main makefile to use ar and ranlib, just
> as perl5 has successfully done for years.
Applied, thanks.
Mike Lambert
er -shared to work properly. The Makefile was built using cygwin perl
(that's why its using cygwin GCC), so perhaps cygwin perl's
$Config{lddlflags} is incorrect? Any ideas on how to resolve this?
Thanks,
Mike Lambert
till a need for determinstic destruction, even in light of the
alternative approaches mentioned above?
Thanks,
Mike Lambert
CVS checkout on win32, and is using cygwin or
msvc, they can do:
Configure.pl && cd languages\perl6 && make && make test
And it should proceed to properly pass all of the compiler tests, aside
from 8_5 and 8_6, which are a bug with the perl6 compiler somewhere
(verified by sean and leo).
Mike Lambert
in32 folk out there want to try this patch and see if it
resolves any issues for you?
Thanks,
Mike Lambert
Index: config/gen/makefiles.pl
===
RCS file: /cvs/public/parrot/config/gen/makefiles.pl,v
retrieving revision 1.2
d
> On Wed, Aug 21, 2002 at 04:17:30AM -0400, Mike Lambert wrote:
> > Just to complete this thread, I have committed the current version of my
> > COW code, as I promised earlier this week.
>
> Did you try running tests with GC_DEBUG on? I get numerous failures.
> Here&#x
trings, then the second sweep performed would eliminate
the wasted memory copy.
Not quite as fast in eliminating the memory usage as the above solution,
but since we are guaranteed of collections happening throughout the
lifetime of any program that does something with strings, I think it's an
okay tradeoff. Were there any other reasons for implementing the above
linked list technique that I missed?
Thanks,
Mike Lambert
on there was to only copy as much data as was needed when we
uncowify a buffer. I believe changing strlen to bufused is the proper fix,
and have committed said change.
Thanks,
Mike Lambert
or things that need to free resources.
Other than the above, I'm not sure what other methods could be used to
force destruction. And I'm not sure if a decree has been made about what
Perl6 will do.
Mike Lambert
I'd love to see the other ideas you had mentioned in your previous emails
that hadn't yet made it to grey, as some of them didn't sound entirely
illegal. You said that parroy grey was a fun project to play around
with performance numbers, and I'd hate to be the reason you stopped having
fun. :)
Thanks,
Mike Lambert
Tom Hughes wrote:
> Index: basicvar.pasm
> ===
...
> Index: instructions.pasm
> ===
...
Fixes the bug, and wumpus plays yet again.
Applied, thanks.
Mike Lambert
ational count.
So in conclusion, generational systems can be done using at most a byte or
a short, and it's even possible to do them with nothing at all. So until
the need arises, I don't think the generations count would be worth it.
Especially since I plan to try and prove the need for a header pool
pointer at some point. :)
Mike Lambert
AD wumpus", and
watch it die on "Not a string!". It could be that basic is using keys in
weird ways, or it could be that the key patch is borked...I haven't looked
into it enough to determine the true cause here.
Thanks,
Mike Lambert
> This adds logical shift right opcodes. They are essential for bit shifting
> negative values without sign extension getting in the way.
Applied, thanks.
Mike Lambert
27;s C target.
Secondly, can you please turn off strip-trailing-whitespace in your
editor? Your patches are reflecting the stripped spaces, which makes it
hard to discern intentional changes from accidental ones.
Thanks,
Mike Lambert
create lots of strings of varying lifetimes,
so it's unreasonable to expect any better performance on it.
So, now that the major objections to the previous patch have been
addressed, does anyone have any reasons against this patch going in?
Thanks,
Mike Lambert
Index: core.ops
for their pointer pickiness.
Applied, thanks.
> On IRIX, though, I get these, where probably NO_STACK_ENTRY_TYPE is
> meant instead.
Applied as well.
Mike Lambert
> fixed before I was able to submit a patch.
Looking at the patch, it seems rather GCC-specific. The checking for
"no-X" versus "X" in the warnings flags seems to be rather non-portable to
compilers like MSVC.
Unfortunately, I don't believe this is easily fixable.
Mike Lambert
s with asserts,
and includes parrot.h. Then the main() function could assert on all of the
necessary conditions. Configure would compile and run this program to
ensure correctness.
Thoughts? Anyone want to take a crack at it?
Mike Lambert
mory due to sharing, it also makes
when-to-collect logic break, and break our balance of collection
frequency and new-block-size, leading to an apparant memory usage
increase. I can't really think of any other cause.
Personally, I find that COW logic makes things a bit more complex, and
some
make it drop even further by fixing this memory
leak.
The fact that both COW's require roughly 3x *more* memory is quite
surprising. If you (or anyone else) feels like attempting to figure out
where our memory is going, I would greatly appreciate it. I'm stumped over
here, and am getting frustrated. (That's why I'm writing this email and
going to sleep ;)
Thanks,
Mike Lambert
?
Overall, tho, the patch looks extemely complete. Tracing support,
disassemble.pl support, debug.c support, etc. You even reduced macro
usage. Rather impressive. :)
Thanks,
Mike Lambert
Applied, thanks.
Mike Lambert
> This is a config test for the direction of stack growth that makes
> the direction a compile time constant.
>
> --
> Jason
Applied, thanks.
> Moved the static prototype to dod.c
>
> Jason
be able to
alleviate this in the long run.
Anyone feeling adventuresome and want to attempt to speed this up? It
should be an easy introduction to the GC code in general. Just start out
in trace_system_stack, and work your way down.
Mike Lambert
hile I get a 17% speedup on
life, I get a 5% loss on hanoi. Since you only posted life, it's a
bit hard to see if the drop on hanoi is just my fault, or the fault of
COW in general.
(More benchmarks will appear in my soon-to-be-sent COW patch email.)
Thanks,
Mike Lambert
, I'd be interested in seeing a
patch. I can work on integrating a lot of your non-forbidden code into the
current codebase.
Thanks for spending the time to generate these numbers...they're a nice
eyeopener on what can be done without the current restrictions. Hopefully
they'll allow us to reconsider each restriction in the context of
the speed of our GC.
Mike Lambert
at a few of the early buffer creations do not
>return the same buffer (provides early warning of GC mischief)
Oooh, nice! :)
The rest of the things you listed, which I didn't comment on are, imo,
perfectly fine.
In conclusion, I don't have any objections to this patch, although it
would be nice if "XXX Unification" markers were included in places that
needed to be addressed later.
Mike Lambert
n test_main.c,
above all possible functions.
I think 1 is easiest, but 3 does have the advantage of allowing the user
to do GC stuff outside of the parrot execution loop, like allocating
global variables (like argv, but app-specific), etc. Of course, it also
imposees additional coding overhead on the embedding programmer.
Mike Lambert
other that got lost in the noise of the above issues
Anyone more well-versed in these departments than I care to take a look at
the potential problems? Just change GC_DEBUG in parrot.h, and you can be
on your way. :)
Thanks,
Mike Lambert
ies
that this buffer contains pointers to other data structures, and should be
traced. If this is unset, the buffer doesn't get added onto the free list.
Since adding it to the free list requires adjusting next_for_GC, it's
already going to reference memory there. Checking the flag would merely
prevent traversing the memory again in the 'process' portion.
Thanks for the quick reply,
Mike Lambert
Mike Lambert wrote:
> One idea, which is most closely in line with the current semantics, is to
> add a pool pointer to every header. I've found a few times in the past
> where such a pointer would have come in handy. This would allow us to call
> the pool's mark() function
ick it on the DOD list so that it
can be properly traced later. This then requires that each buffer contain
a next_for_GC pointer, so it can be added to the to-do list. Alternately,
we can use pool-specific memory to handle the various pointers that are
required for DODbut the point remains that this further increases the
memory footprint of buffers, and I wanted to verify that it was okay.
Comments and/or suggestions, please?
Thanks,
Mike Lambert
, whereas pointers are shallow). Of
course, one could argue that the previous one didn't work at all. :)
Thoughts?
Mike Lambert
Sean O'Rourke wrote:
> Date: Fri, 2 Aug 2002 08:20:58 -0700 (PDT)
> From: Sean O'Rourke <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [
Applied, thanks.
Mike Lambert
Jarkko Hietaniemi wrote:
> Date: Fri, 02 Aug 2002 15:03:21 GMT
> From: Jarkko Hietaniemi <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [perl #15943] [PATCH] UNICOS/mk vs dynaloading continues
> Resen
Applied, thanks.
Mike Lambert
Simon Glover wrote:
> Date: Fri, 02 Aug 2002 21:40:51 GMT
> From: Simon Glover <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [perl #15953] [PATCH] More GC tests
> Resent-Date: 2 Aug 2002 21:40:52 -00
Applied, thanks.
Mike Lambert
Simon Glover wrote:
> Date: Fri, 02 Aug 2002 21:39:13 GMT
> From: Simon Glover <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [perl #15952] [PATCH] Minor doc fix in core.ops
> Resent-Date: 2 Aug 2002
Fixed, thanks.
Mike Lambert
Simon Glover wrote:
> Date: Fri, 02 Aug 2002 21:19:29 GMT
> From: Simon Glover <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [perl #15951] [BUG] header_allocs_since_last_collect never
> updated
>
Applied, thanks.
Mike Lambert
Simon Glover wrote:
> Date: Fri, 02 Aug 2002 21:00:19 GMT
> From: Simon Glover <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [perl #15949] [PATCH] Silence warning in hash clone
> Resent-Date: 2
Applied, thanks.
Mr. Nobody wrote:
> Date: Fri, 02 Aug 2002 20:57:57 GMT
> From: Mr. Nobody <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [perl #15948] [PATCH] Configure broken on windows 9x
> Resent-Date: 2 Aug 2002 20:57:57 -
> Resent-From: [EMAIL PRO
Applied with some modification, thanks.
Mike Lambert
Richard Cameron wrote:
> Date: Wed, 31 Jul 2002 22:24:55 +0100
> From: Richard Cameron <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [perl #15845] [BUG] GC segfault
>
>
> On
> Patch below kills a couple of warnings that cropped up because
> alloc_more_objects was renamed to alloc_objects in the code but
> not the headers. Also updates the comments.
>
> Simon
Applied, thanks.
Mike Lambert
> Fixes a few typos and tidies up capitalization in dod.dev
>
> Simon
Applied, thanks.
Mike Lambert
;), but I'm not really sure of
any cleaner ways to do it. If you have any suggestions, please feel
free to mention them.
Anyways, I've committed fixes for both of these issues.
Thanks again.
Mike Lambert
at
insights into "the way things (should) work".
Of course, the possibility exists that I am completely missing something,
and this truly is a simple question. :)
Thanks,
Mike Lambert
he main changes that I see are:
- the elimination of the keyed versions for all the mathematical vtable
methods
- the addition get_keyed_ref method
- the addition of mathematical keyed *ops* that use get_keyed_ref to "do
their thing" ?
- perhaps some method for storing the keyed_ref result
. To really determine
their worth, we need real-world programs, and figure out how often would
they be using longjmp, and external code, to determine how often the
bookkeeping is wasted. But that brings me back around to the point in my
previous email, about the mythical "real world program". :)
Mike Lambert
. Unfortunately, until
we have a wide test suite of programs, or start implementing adaptive
adjustment of GC parameters, I have a feeling we're just going to travel
around in circles.
Mike Lambert
> This patch is rather questionable, and thus I did not commit it
> directly. However, it illustrates a point I wanted to make.
Doh! Hopefully my previous post will make a bit more sense now. :)
Mike Lambert
Index: arr
r own get_pmc_keyed ?
Thoughts, comments?
Mike Lambert
ve been addressed,
> with the one exception of refactoring code bloat. I feel this is a small change
> in implementation, and shouldn't impact design. I hope Dan will (pending time)
> consider it, and I'll be happy to hash it out with him on IRC to make sure
> both parties understand exactly what is being said and that I don't continue
> to miss things ;)
Hopefully I've helped to explain some of the things you said you were
unsure about. Of course, since I'm not Dan, you might very well hear
something completely different when he gets back from TPC. :)
Mike Lambert
> * win32 can flush it's file buffers (FlushFileBuffers())
> * SetFilePointer knows about whence, win32 constants (values, not names) are the
>same as in linux.
Applied, thanks.
Mike Lambert
know that there are faster solutions to the problem of child collection,
but Dan doesn't want to use them due to the problems that occur when we
start using exceptions (and longjmp, etc). Perhaps, if the above
performance hit is due to trace_system_stack, it might give reason to
reconsider the chosen solution?
Thanks,
Mike Lambert
Applied, thanks.
If someone wants to mark this ticket as resolved, I'd appreciate it.
Mike Lambert
Scott Walters wrote:
> Date: Mon, 22 Jul 2002 08:49:33 GMT
> From: Scott Walters <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Sub
be any overlap at all, so set_keyed_integer could safely
be named set_keyed.
Can we safely remove "set ", due to the relative inefficiency in
constructing dummy PMCs to call it? Wouldn't it be more efficient to split
the call into two "set PP*",and "setP*P" calls?
Thanks,
Mike Lambert
Josef Höök wrote:
> I've added an if case in genclass so it will print
> "return whoami;" for "name" function so that no one need to grep parrot
> source for an hour or two trying to figure out why it segfaults when
> registering pmc class in init_world... (
0.987
gc_waves_sizeable_headers.pbc 1.000 0.855
Overall:
old 1.000
new 0.925
Details of what were done to accomplish this can be found in my email to
the cvs-parrot list. It was pretty much 4 or 5 distinct things that each
gave a couple percentage points' improvement.
Thanks,
Mike Lambert
changes to get the tests passing on all platforms, again. And then try it
with JUST the stackwalking code to avoid neonate problems.
Thanks,
Mike Lambert
ate between 1^30 and 1^30+1^0,
since 30 - 0 > 23.
Am I missing something here?
Thanks,
Mike Lambert
and then set the new value.
This pattern is currently utilized in the string PMC methods, but not with
the number-related methods.
So in conconclusion, while I don't have any reservations about your
patch, I do have a preference that it be done differently. :)
Mike Lambert
into valid collectable memory (making it
slower), we still have the issue of buflen being set to MAX_INT or
something, and killing the system. :|
The same caveats apply to pmc headers which happen to have
PMC_buffer_ptr_FLAG set.
How should we get around this particular problem, or is it spelling the
doom of this particular solution?
Thanks,
Mike Lambert
rom my
vantage point, documentation is bad only if someone attempts to learn a
particular area of the code and has trouble because of the lack of, or
inadequacy of, the documentation for that task.
Have you attempted to learn every aspect of parrot, such that you
can verifiably say that all of parrot&#
for the
OS/platforms which need it differently? resources.c? .c? Maybe
in resources.c with each .c calling the generic one in
resources.c (since win32, generic, darwin, etc are all likely to share the
same logic.)
Mike Lambert
Dan Sugalski wrote:
> Date: Fri, 12 Jul 2002 13:05:54 -0400
> Fr
the simple ones fine,
PMC->PMC conversions are essentially multi-dispatch, and imo, should be
treated as such. This might only matter with strong typing, but it might
also help with the differently-organized mathematical libraries: assuming
no binary operators are written, one only needs to write conversions, to
allow them to interoperate, if slowly.
Thoughts? Am I taking it too far?
Mike Lambert
er rampup that should allow for more
iterations, while still testing the same thing.
Mike Lambert
aren't done,
this will demonstrate poor performance due to the old headers not getting
marked as unused, and it needing to allocate more memory blocks.
I think it is *because* they measure how fast parrot is at copying string
that these are good tests. GCs which avoid copying will perform better on
these.
Mike Lambert
uite efficient. It also
makes me realize that a slower rampup here would probably be a better
test.
I guess it also raises some suspicion about the other test results. Ah
well, we need a fix for our GC problems anyway...
Mike Lambert
PS: I'm currently operating under the assumption that these ki
ough my comments
still stand about looking for an adaptive pool sizing system).
Thanks for bearing with me on this,
Mike Lambert
ing to help compare every aspect of our GCs? Real-world
programs are too hard to come by. :) Results of the above test suite on my
machine comparing my local GC work and the current parrot GC are coming
soon...
Enjoy!
Mike Lambert
PS: If you get bouncing emails from me because my email server is down, I
unction is nenoate, everything we
construct into this base pmc should be contiguously neonate, if that
makes sense.
Granted, it's a little bit expensive to do the tracing, but you shouldn't
need to trace too deep at all, and its time is proportional to the size of
the nested data structure you
uire modification.
I think these guidelines make it easy for non-GC-programmers to writ
GC-dafe code, since they do not need to be aware of what allocates memory,
and what does not.
What do people think of this approach?
Mike Lambert
others? Thoughts on why we should/shouldn't implement this kind of
thing in parrot, below the buffer level?
Thanks,
Mike Lambert
PS: In case you're confused...yes, I was replying to myself. :)
might point at.
Now you have immobile memory that's efficient to allocate, good at
avoiding memory fragmentation, and good for you to do with what you
please.
Once we figure out how hashes are implemented well, we should probably
write up some guidelines on when to use what kinds of headers, et.c
Thoughts?
Mike Lambert
y aligned ones)
As long as the C stack is guaranteed to be contiguous, this should be
portable. I'm not sure if that is guaranteed by ANSI C, however.
Has this already been considered and explicitly rejected?
Thanks,
Mike Lambert
of
the required amount was copied.
We could 'fix' this up by including the true buffer length in the buffer
footer, so that we ignore the header's buflen during the collection
process.
But I think the strstart is a better idea regardless. It's what perl5 did
anyway, isn't it?
Mike Lambert
> At 12:06 AM -0400 5/19/02, Mike Lambert wrote:
> >Is there a plan to make a freed method for when pmc header gets put
back
> >onto the free list? (This would require we call this method on all
pmc's
> >before moving anything to the freelist, in case of dependancies b
s the cost over the
entire system, but ends up being slower in terms of total time used. Your
approach would involve lots of computation in lots of little functions
over parrot's execution, whereas Dan's would involve a full trace
(equivalent to a DOD) to be performed every now and again.
But that's just hypothetical posturing because I don't have any real
benchmarks, of course.
Mike Lambert
y be a good time to suggest it. :)
Thoughts or comments? Thanks,
Mike Lambert
her major
dis/advantages they'd like to contribute about the above approaches?
FWIW, I feel confident enough about my understanding of Dan's idea to
implement that, should we choose it. Melvin's idea would require that
much more work on the multitude of functions, and so I can't imagine it
being as easy to implement. :)
Mike Lambert
1 - 100 of 130 matches
Mail list logo
