chromatic wrote:
On Sunday 24 February 2008 18:41:23 Bob Rogers wrote:
Granted, and it's tough to make a PMC truly read-only until after it's
completely initialized . . .
There's a similar problem for accessors and setters. Again, that's
solveable with more code or more cleverness.
So,
" -- immune from being changed at the bytecode level. An
object could be marked immutable, and then mutable again (but some
objects may not allow this, particularly singletons). Immutable objects
are not treated specially by garbage collection. (I don't think this is
useful to Parrot
On Sunday 24 February 2008 18:41:23 Bob Rogers wrote:
> Granted, and it's tough to make a PMC truly read-only until after it's
> completely initialized . . .
>
>There's a similar problem for accessors and setters. Again, that's
>solveable with more code or more cleverness.
>
> So, you're
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 17:22:19 -0800
On Sunday 24 February 2008 16:55:48 Bob Rogers wrote:
> Why do constant PMCs ever need to point to non-constant ones? In other
> words, why are those pointed-to PObjs not also constant?
The reason is pra
On Sunday 24 February 2008 16:55:48 Bob Rogers wrote:
>Some of our memory problems seem to be strange interactions between
>PObjs allocated out of constant pools, garbage collection, and
>freezing/thawing PBC (not to mention the interaction of HLLs).
>
> Amen! -- p
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 24 Feb 2008 01:55:20 -0800
Some of our memory problems seem to be strange interactions between
PObjs allocated out of constant pools, garbage collection, and
freezing/thawing PBC (not to mention the interaction of HLLs).
On Sunday 24 February 2008 07:33:30 Leopold Toetsch wrote:
> Am Sonntag, 24. Februar 2008 10:55 schrieb chromatic:
> > PMCs that *do* need a special mark() are troublesome; they may contain
> > pointers to non-constant PObjs that *do* need live marking, lest they get
> > swept away during the sec
Am Sonntag, 24. Februar 2008 10:55 schrieb chromatic:
> PMCs that *do* need a special mark() are troublesome; they may contain
> pointers to non-constant PObjs that *do* need live marking, lest they get
> swept away during the second half of GC. If these constant PObjs don't get
> marked, there's
Some of our memory problems seem to be strange interactions between PObjs
allocated out of constant pools, garbage collection, and freezing/thawing PBC
(not to mention the interaction of HLLs).
PObjs allocated out of constant pools persist in memory. They get marked
(sometimes, but not always
# New Ticket Created by François PERRAD
# Please include the string: [perl #49328]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49328 >
I've isolated one problem between PBC loading and garbage collection.
(reme
Hi all,
A Segmentation fault occurs in the languages/lua/t/tables_3.pir.
This test is a simple table creation (with 1000 items) :
a = {}
for i=1,1000 do a[i] = i*2 end
print(a[9])
This problem started with revision 11586.
In the previous Lua PMC implementation (r11478),
Sam Vilain wrote:
Hi all,
While I must start this post out by saying that I've never implemented
either STM or a garbage collector, during a discussion on #parrot (is
that channel logged?), a similarity between the two processes occurred
to me.
Not really. STM is a scheme to handle access t
Hi all,
While I must start this post out by saying that I've never implemented
either STM or a garbage collector, during a discussion on #parrot (is
that channel logged?), a similarity between the two processes occurred
to me.
Would this be an adequate expression of a generational Garbage
C
Nick Glencross <[EMAIL PROTECTED]> wrote:
> Ok, now I understand. This is inspecting the C runtime stack (I think).
> The Interpreter remembers the bottom address, and then when the time
> comes, a routine runs the depth of the stack.
Yes. Exactly.
> The values on the stack are then checked whet
Nick Glencross wrote:
I've learned alot about DOD since earlier (and watched telly). Not as
straightforward as I thought it would be to find if these traces should
be considered serious or not (I would say any logic based on unitialised
values will bite one day!).
Ok, now I understand. This is i
Nick Glencross wrote:
The DOD certainly has a few things flagged up, which I'm going to
quickly investigate to see if they are serious or not...
I've learned alot about DOD since earlier (and watched telly). Not as
straightforward as I thought it would be to find if these traces should
be consid
Leopold Toetsch wrote:
Cory Spencer <[EMAIL PROTECTED]> wrote:
I've come across another garbage collection/DOD issue that I'm trying to
solve (without much success) and would appreciate some tips/advice on how
to locate the source of the problem.
Running valgrind (on sup
Cory Spencer <[EMAIL PROTECTED]> wrote:
> I've come across another garbage collection/DOD issue that I'm trying to
> solve (without much success) and would appreciate some tips/advice on how
> to locate the source of the problem.
When I'm investigating GC bugs, th
I've come across another garbage collection/DOD issue that I'm trying to
solve (without much success) and would appreciate some tips/advice on how
to locate the source of the problem.
It appears (based on my tests) to cause strings to be marked as dead
objects before their time. It
Cory Spencer <[EMAIL PROTECTED]> wrote:
> ---354891615-125901741-966306=:18075
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> I've been writing a Lisp implementation on top of Parrot for the last
> several months (and I'm just about at the point where I'm ready to unleash
> it
ch on an x86 Linux
machine will produce a segmentation fault and on a Mac OS X 10.3 machine
produces a bus error. Running with the garbage collection disabled (ie.
with the -G flag) does not produce these errors.
If anyone could point me towards what is going wrong, I would MOST
appreciate it
Try again, please.
In addition to fixing the incomplete commit below,
I've committed the "build runtime library with parrot" ticket as well, so
you'll need to do a re-configure & build.
On Tue, Sep 28, 2004 at 02:49:45PM +0200, Leopold Toetsch wrote:
> Will Coleda <[EMAIL PROTECTED]> wrote:
>
I don't see my followup that I sent from a different account earlier today.
Try this again - you'll need a re-configure as there's a change to the root Makefile
that tcl now requires.
Thanks for checking into this.
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
oolong:~/research/pa
Will Coleda <[EMAIL PROTECTED]> wrote:
> oolong:~/research/parrot coke$ ./parrot languages/tcl/tcl.pbc
[EMAIL PROTECTED]:~/src/parrot-leo/languages/tcl]
$ make
make: *** No rule to make target `lib/commands/unset.imc', \
needed by `lib/tcllib.pbc'. Stop.
leo
in fact, look for dead
> objects (if you consider PMC and buffer headers objects.
... and frees dead objects. That's exactly a mark and sweep garbage
collector. DOD is the first phase of that garbage collection. It would
be rather useless, if we only detect garbage and not collect it.
It
André Pang <[EMAIL PROTECTED]> wrote:
> On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote:
>> 3) The copying collector isn't integrated yet. But that should be easy.
>> After finishing sweep and if there is some possible wastage in the
>> memory pools, these get compacted.
> I thought Parrot wasn'
Andrà Pang writes:
> On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote:
>
> >3) The copying collector isn't integrated yet. But that should be easy.
> >After finishing sweep and if there is some possible wastage in the
> >memory pools, these get compacted.
>
> I thought Parrot wasn't using copying
On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote:
3) The copying collector isn't integrated yet. But that should be easy.
After finishing sweep and if there is some possible wastage in the
memory pools, these get compacted.
I thought Parrot wasn't using copying collectors, since you're exposing
PM
At 9:48 PM +0200 8/20/04, Leopold Toetsch wrote:
0) Parrot's nomenclature DOD vs GC is a bit misleading. The "DOD"
subsystem is the stop-the-world mark & sweep collector that recycles
object headers. The "GC" is the copying collector for variable sized
string and other buffer memory.
The incrementa
can or updated immediately to reflect that change.
So allocating these dummy placeholders would be done basically in the
old generation only. The probably high count of multiple references in
the volatile root set is ignored for garbage collection. For freezing
the whole interpreter it would
[ Oops that one got the wrong address, resent ]
Original Message
To: perl6-internals-subscribe ...
Some remarks
0) Parrot's nomenclature DOD vs GC is a bit misleading. The "DOD"
subsystem is the stop-the-world mark & sweep collector that recycles
object headers. The "GC" is t
Leo~
On Fri, 20 Aug 2004 16:26:33 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> And yes, I'm really thinking of inserting these A* nodes. Freezing an
> object does need it. DOD of course not really.
How is space going to be made for these? DOD probably does not want
to allocate the dummy
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> Nice summary of the issues, but I have a few nits to pick
Thanks. I'll only look at DFS. It more cache-friendly.
> Thus I don't think that BFS works. Now lets consider DFS of both sets.
> A refs C,B; B refs D, E; C refs E; D refs G; E refs A
Leo~
Nice summary of the issues, but I have a few nits to pick
On Fri, 20 Aug 2004 10:29:28 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> a) The mark phase of the garbage collection creates the graph of *all*
> life (reachable) objects[1].
> b) Freezing a PMC creat
r is done independently and on demand, with the complication that
incremental's chain creation is done in the "background".
Well, here is an idea:
Prelims:
a) The mark phase of the garbage collection creates the graph of *all*
life (reachable) objects[1].
b) Freezing a PMC creates the
Richard Jones is the author of "Garbage Collection: algorithms for automatic
dynamic memory management"
http://www.amazon.com/exec/obidos/tg/detail/-/0471941484. A book that I
believe has been mentioned on the list before.
I do not believe anyone has mentioned his web
management, and the GC_IS_MALLOC code is already handling the
COW cases.
#2 is a bit more interesting and, if we do it right, means that
we'll end up with a pluggable garbage collection system and may
(possibly) be able to have type 3 threads share object arenas and
memory pools, which'd b
ing headers may be pointing to the same chunk of memory, so
freeing up one's not a sufficient reason to return the memory to the
free pool.
#2 is a bit more interesting and, if we do it right, means that
we'll end up with a pluggable garbage collection system and may
(possibly) be ab
ght, means that we'll
end up with a pluggable garbage collection system and may (possibly)
be able to have type 3 threads share object arenas and memory pools,
which'd be rather nice. Even if not, it leaves a good window for
experimentation in allocation and collection, which is
ation
issues when sharing data between interpreters. So, time for some work.
The task is twofold:
1) The garbage collection and memory allocation APIs needs to be
formalized and abstracted a bit. (We're likely most of the way there,
but it's been a while since I've looked and,
> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
TB> On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
>> > "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
>>
TB> As a part of that the weak reference concept, bolted recently into
TB> perl5, could be made more central in
On Thu, Feb 15, 2001 at 02:26:10PM -0500, Uri Guttman wrote:
> > "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
>
> TB> As a part of that the weak reference concept, bolted recently into
> TB> perl5, could be made more central in perl6.
>
> TB> Around 92.769% of the time circular refere
At 09:13 PM 2/15/2001 -0500, Ken Fox wrote:
>Hong Zhang wrote:
> > The memory barriers are always needed on SMP, whatever algorithm
> > we are using.
>
>I was just pointing out that barriers are an alternative to mutexes.
>Ref count certainly would use mutexes instead of barriers.
Not really they
e, i.e. append, then
> > what I originally said holds true. This behaviour is predictable and
> > dependable in the current perl implementation. Without the >> the file
> > will contain just "bar\n".
>
>That was not what I meant. Your code already assume the
Hong Zhang wrote:
> The memory barriers are always needed on SMP, whatever algorithm
> we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
> The memory barrier can be easily coded in assembly, or intrinsic
> There are several concurrent GC algorithms that don't use
> mutexes -- but they usually depend on read or write barriers
> which may be really hard for us to implement. Making them run
> well always requires help from the OS memory manager and that
> would hurt portability. (If we don't have OS
Alan Burlison wrote:
> I think you'll find that both GC *and* reference counting scheme will
> require the heay use of mutexes in a MT program.
There are several concurrent GC algorithms that don't use
mutexes -- but they usually depend on read or write barriers
which may be really hard for us to
Hong Zhang wrote:
> That was not what I meant. Your code already assume the existence of
> reference counting. It does not work well with any other kind of garbage
> collection. If you translate the same code into C without putting in
> the close(), the code will not work at all.
Wr
iour is predictable and
> dependable in the current perl implementation. Without the >> the file
> will contain just "bar\n".
That was not what I meant. Your code already assume the existence of
reference counting. It does not work well with any other kind of garbage
collection. I
Hong Zhang wrote:
> This code should NEVER work, period. People will just ask for trouble
> with this kind of code.
Actually I meant to have specified ">>" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl implemen
> {
> my $fh = IO::File->new("file");
> print $fh "foo\n";
> }
> {
> my $fh = IO::File->new("file");
> print $fh "bar\n";
> }
>
> At present "file" will contain "foo\nbar\n". Without DF it could just
> as well be "bar\nfoo\n". Make no mistake, this is a major change to t
Branden wrote:
> Just set autoflush, if you're lazy...
And say goodbye to performance...
> > The problem is
> > that you can not only count on $fh's DESTROY being called at the end of
> > the block, you often can't count on it ever happening.
>
> Anyway, the file would be flushed and closed...
> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
TB> As a part of that the weak reference concept, bolted recently into
TB> perl5, could be made more central in perl6.
TB> Around 92.769% of the time circular references are known to be
TB> circular by the code that creates them (like a
Damien Neil wrote:
> On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> > I think you just said all about why we shouldn't bother giving objects
> > deterministic finalization, and I agree with you. If we explicitly want
to
> > free resources (files, database connections), then we explicit
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> I think you just said all about why we shouldn't bother giving objects
> deterministic finalization, and I agree with you. If we explicitly want to
> free resources (files, database connections), then we explicitly call close.
> Otherwise,
Tim Bunce wrote:
> On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> > And don't forget that if we stick with refcounting, we should try to
find a
> > way to break circular references, too.
>
> As a part of that the weak reference concept, bolted recently into perl5,
> could be made more
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> Hong Zhang
> > > A deterministic finalization means we shouldn't need to force
> programmers
> > > to have good ideas. Make it easy, remember? :)
> >
> > I don't believe such an algorithm exists, unless you stick with reference
> > count.
Hong Zhang
> > A deterministic finalization means we shouldn't need to force
programmers
> > to have good ideas. Make it easy, remember? :)
>
> I don't believe such an algorithm exists, unless you stick with reference
> count.
>
Either doesn't exist, or is more expensive than refcounting. I guess
Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization. A much better approach
> is to have methods which allow holders of the object to control it,
> and a finalizer (DESTROY method) which cleans up only if necessary
> A deterministic finalization means we shouldn't need to force programmers
> to have good ideas. Make it easy, remember? :)
I don't believe such an algorithm exists, unless you stick with reference
count.
Hong
On Thu, Feb 15, 2001 at 12:11:27AM +, Simon Cozens wrote:
> > Using object lifetime to control state is almost never a good idea,
> > even if you have deterministic finalization.
>
> A deterministic finalization means we shouldn't need to force programmers
> to have good ideas. Make it easy,
On Wed, Feb 14, 2001 at 01:24:34PM -0800, Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization.
A deterministic finalization means we shouldn't need to force programmers
to have good ideas. Make it easy, remember?
On Wed, Feb 14, 2001 at 05:43:31PM -0300, Branden wrote:
> 4. Why should we bother destroying an object before GC does it?
>
> To free system resources, like open files or database connections. Probably
> the average program won't do it never, but programs that must open several
> files sequentia
[trimming distribution to -internals only]
On Wed, Feb 14, 2001 at 07:44:53PM +, Simon Cozens wrote:
> package NuclearReactor::CoolingRod;
>
> sub new {
> Reactor->decrease_core_temperature();
> bless {}, shift
> }
>
> sub DESTROY {
> Reactor->increase_core_temperature();
> }
A
call back from perl, the
binary, that everyone is done with the object, and it's about to go away.
DESTROY might be called around the same time its memory is being reclaimed,
but from a language perspective, all this memory dealing is non-existant.
DESTROY is a language thing, garbage collect
At 07:44 PM 2/14/2001 +, Simon Cozens wrote:
>On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > > DESTROY would get called twice, which is VERY BAD.
> >
> > *blink*
> > It is? Why?
> > I grant you it isn't the clearest way of programming, but "VERY BAD"?
>
>package Nuclear
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > DESTROY would get called twice, which is VERY BAD.
>
> *blink*
> It is? Why?
> I grant you it isn't the clearest way of programming, but "VERY BAD"?
package NuclearReactor::CoolingRod;
sub new {
Reactor->decrease_core_te
[[ reply goes to -internals ]]
OK. Let's clear it up all at once from start. Below is the lifecycle of an
object (in Perl). A reference is blessed, and an object is the result of
this blessing. During the object's life, several methods of it are called,
but independent of which are called, it co
[[ reply to this goes only to -internals ]]
Dan Sugalski wrote:
> *) People like it
Well, if people liking it is the only reason (either is the only on or
appears 3 times in a 5 item list, what is pretty much the same to me ;-)
[... the only reason] to add a feature to Perl, we'll probably end
At 07:51 PM 2/12/2001 -0500, Bryan C. Warnock wrote:
>On Monday 12 February 2001 16:54, Dan Sugalski wrote:
> > >Could you guys please use "destruction" or "cleanup" as the term for the
> > >end-of-scope processing (see e.g. C++). Finalization is used everywhere
> > >else to mean: called by GC be
On Monday 12 February 2001 16:54, Dan Sugalski wrote:
> >Could you guys please use "destruction" or "cleanup" as the term for the
> >end-of-scope processing (see e.g. C++). Finalization is used everywhere
> >else to mean: called by GC before the memory is released (see e.g
> >Java/C#).
>
> Corre
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >>On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >>
> >> > Perl needs some level of tracking for objects with finalization
At 09:49 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <[EMAIL PROTECTED]>
>wrote:
>
> >Actually I was thinking something like PMCs ($@%) being copy-GCed and
> >referred objects (new SomeClass) being refcounted. In this case above, every
> >operation would us
current entity is being refcounted). I'm not saying
>that this is necessarily a bad space/time tradeoff. But many people seem
>to think that using mark-and-sweep for garbage collection will be a
>performance boost. This may not be the case if objects still need to
>reference co
On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" <[EMAIL PROTECTED]>
wrote:
>Actually I was thinking something like PMCs ($@%) being copy-GCed and
>referred objects (new SomeClass) being refcounted. In this case above, every
>operation would use refcount's, since they're storing objects in PMCs. Wha
Buddha Buck wrote:
> At 01:45 PM 02-12-2001 -0300, Branden wrote:
> >Am I too wrong here?
>
> It's... complicated...
>
Agreed.
> Here's an example of where things could go wrong:
>
> sub foo {
> my $destroyme1 = new SomeClass;
> my $destroyme2 = new SomeClass;
> my @pr
At 01:45 PM 02-12-2001 -0300, Branden wrote:
>I think having both copying-GC and refcounting-GC is a good idea. I may be
>saying a stupid thing, since I'm not a GC expert, but I think objects that
>rely on having their destructors called the soonest possible for resource
>cleanup could use a refco
that this is necessarily a bad space/time tradeoff. But many people seem
> to think that using mark-and-sweep for garbage collection will be a
> performance boost. This may not be the case if objects still need to
> reference counted.
>
> >I do wish people would get garbage c
ace/time tradeoff. But many people seem
to think that using mark-and-sweep for garbage collection will be a
performance boost. This may not be the case if objects still need to
reference counted.
>I do wish people would get garbage collection and finalization split in
>their minds. They ar
On Sunday 11 February 2001 22:48, Jan Dubois wrote:
> Doing full GC in this fashion after failed API calls will probably wipe
> out any performance gain mark-and-sweep has over reference counting.
Well, after select failed API calls, not every call. And mark-and-sweep,
if that's the GC scheme u
e memory, but hoping that some
object will free a resource. You don't know which generation to collect;
it could be anywhere.
Doing full GC in this fashion after failed API calls will probably wipe
out any performance gain mark-and-sweep has over reference counting.
>> This scheme
wouldn't you still want Perl to panic, vice the XS code anyway?
>
> This scheme would only work if *all* resources including memory and
> garbage collection are handled by the OS (or at least by a virtual machine
> like JVM or .NET runtime). But this still doesn't solve
On Wed, 30 Aug 2000, Joshua N Pritikin wrote:
> On Wed, Aug 30, 2000 at 01:15:39PM -0400, [EMAIL PROTECTED] wrote:
> > I didn't realize until I read through parts of this exactly how much time a
> > refcounting GC scheme took. Between that and perl 5's penchant for
> > flattening arrays and has
On Wed, Aug 30, 2000 at 01:15:39PM -0400, [EMAIL PROTECTED] wrote:
> I didn't realize until I read through parts of this exactly how much time a
> refcounting GC scheme took. Between that and perl 5's penchant for
> flattening arrays and hashes (which creates a lot of garbage itself for
> biggi
At 11:10 AM 8/30/00 -0500, Jarkko Hietaniemi wrote:
>Something for the reference shelf:
>
> Garbage Collection
> Algorithms for Automatic Dynamic Memory Management
> Richard Jones & Raphael Lins
> John Wiley and Sons, 1996
> IS
t; Reference Counting (several variants)
> JH> Mark-Sweep (ditto)
> JH> Mark-Compact (ditto)
> JH> Copying (various strategies)
> JH> Generational Garbage Collection (you know the drill)
> JH> Incremental an
tto)
JH> Copying (various strategies)
JH> Generational Garbage Collection (you know the drill)
JH> Incremental and Concurrent Garbage Collection (...)
JH> Garbage Collection for C
JH> Garbage Collection for C++
JH> Cache-Conscious Garbage Collection
JH>
Something for the reference shelf:
Garbage Collection
Algorithms for Automatic Dynamic Memory Management
Richard Jones & Raphael Lins
John Wiley and Sons, 1996
ISBN-0-471-94148-4
Still haven't had time to delve into it but from a quick browse
88 matches
Mail list logo
