Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:08 PM +0100 1/24/04, Leopold Toetsch wrote:
>>Fianlizers and incremental DOD don't play together. The DOD must run to
>>end to be sure, that the objects isn't referenced any more.
> Finalizers and incremental DOD work just fine together. At some poin
At 3:08 PM +0100 1/24/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 5:56 PM +0100 1/23/04, Leopold Toetsch wrote:
Stopping all interpreters seems to be cheaper. The rwlock will sooner or
later stop all interpreters anyway (on first PMC access), so we can omit
the price for
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:56 PM +0100 1/23/04, Leopold Toetsch wrote:
>>Stopping all interpreters seems to be cheaper. The rwlock will sooner or
>>later stop all interpreters anyway (on first PMC access), so we can omit
>>the price for the rwlock and just hold the world(s).
>
On Friday, January 23, 2004, at 11:09 , Dan Sugalski wrote:
Ah, OK, I see. The problem comes in where we've got an object in the
transient root set (basically the processor stack and registers) that
gets anchored into the base root set (stash, pads, or whatever) after
the DOD has traced where i
At 5:56 PM +0100 1/23/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 12:04 AM -0500 1/20/04, Gordon Henriksen wrote:
C was not marked reachable (although it was) and was thus
erroneously collected, leaving a dangling pointer. This problem
applies equally to copying and mark-
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:04 AM -0500 1/20/04, Gordon Henriksen wrote:
>>C was not marked reachable (although it was) and was thus
>>erroneously collected, leaving a dangling pointer. This problem
>>applies equally to copying and mark-sweep collectors.
> Ah, OK, I see.
That
At 12:04 AM -0500 1/20/04, Gordon Henriksen wrote:
On Monday, January 19, 2004, at 06:37 , Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all readers should be blocked as well.
True of non-moving collectors, too. [...]
At 10:40 PM +0100 1/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The only tricky bit comes in with the examination of the root set of
other threads--accessing the hardware register contents of another
running thread may be... interesting. (Which, I suppose, argues for
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The only tricky bit comes in with the examination of the root set of
> other threads--accessing the hardware register contents of another
> running thread may be... interesting. (Which, I suppose, argues for
> some sort of volatile marking of the temp vari
At 4:59 PM -0800 1/19/04, Dave Whipp wrote:
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
=head2 Guarantees
Maybe this isn't strictly a threading thing, but are we going to make any
guarantees about event orderings? For example, will we guarantee that a
sequence of events send from one thread to anoth
[Note to everyone -- I'm digging through my mail so be prepared for a
potential set of responses to things that're already answered...]
At 6:37 PM -0500 1/19/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all reade
At 12:15 AM +0100 1/22/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ No Guarantees WRT data access }
... seems to indicate that even whole ops like add P,P,P are atomic.
Yep. They have to be, because they need to guarantee the integrity of
the pmc structures and the data
On Wed, Jan 21, 2004 at 01:14:46PM -0500, Dan Sugalski wrote:
> >... seems to indicate that even whole ops like add P,P,P are atomic.
>
> Yep. They have to be, because they need to guarantee the integrity of
> the pmc structures and the data hanging off them (which includes
> buffer and string s
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ No Guarantees WRT data access }
>>... seems to indicate that even whole ops like add P,P,P are atomic.
> Yep. They have to be, because they need to guarantee the integrity of
> the pmc structures and the data hanging off them (which includes
> buffer and
At 10:25 AM +0100 1/21/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
One more question:
=head2 Guarantees
... doesn't have anything about user data integrity. So when 2 threads
access a PerlNum, they could get a mixture of the typically 2 involved
words.
Potentially, yeah, th
21/01/2004 02:12:09, Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> This is false. The mark phase will still need to run over the entire
> process, else it cannot detect all references into the pool.
>
If by reference, you mean address, then that is true.
If when a reference is taken, the addres
Dan Sugalski <[EMAIL PROTECTED]> wrote:
One more question:
>=head2 Guarantees
... doesn't have anything about user data integrity. So when 2 threads
access a PerlNum, they could get a mixture of the typically 2 involved
words.
But:
>=item All shared PMCs must have a threadsafe vtable
> The fi
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I believe that parrot already has the concept of memory pools in it's
> memory management. The idea is that by allocating similarly sized objects
The problem is not in the fixed sized header pools, its with the
*memory* pool used e.g for string memor
20/01/2004 13:29:35, Gordon Henriksen <[EMAIL PROTECTED]> wrote:
>On Monday, January 19, 2004, at 07:58 , [EMAIL PROTECTED]
>wrote:
>
>> Is there any likelyhood that memory allocation will be hidden behind
>> macros at two levels:
>> - ALLOCPOOL() for allocating large chunks of memory (ppols) t
On Tuesday, January 20, 2004, at 07:56 , [EMAIL PROTECTED]
wrote:
I believe that parrot already has the concept of memory pools in it's
memory management. The idea is that by allocating similarly sized
objects from separate (large) allocations, you can reduce the
fragmentation of chunks and re
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 5:16 PM +0100 1/20/04, Leopold Toetsch wrote:
>>What about temporary PMCs (or strings)?
> Those won't get marked as shared unless we're unconditionally marking
> things as shared. (Though we may just give 'em a mutex anyway)
This needs either one check
At 5:16 PM +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
=item Interpreter pools will share allocation pools
All the interpreters in an interpreter pool will share header and
memory allocation pools.
What about temporary PMCs (or strings)?
Those won't get marked
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>=item Interpreter pools will share allocation pools
> All the interpreters in an interpreter pool will share header and
> memory allocation pools.
What about temporary PMCs (or strings)? Evaluating a non-trivial
expression can have lot of these. Each new
At 4:24 PM +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
The term "process id" is really misleading.
Nope. It's the process ID. Nothing misleading there, unless you've
done threading work under linux, since for a w
At 16:24 +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
The term "process id" is really misleading.
Nope. It's the process ID. Nothing misleading there, unless you've
done threading work under linux, since for a whi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
>>The term "process id" is really misleading.
> Nope. It's the process ID. Nothing misleading there, unless you've
> done threading work under linux, since for a while it gave each
> thread a separate PID.
At 1:46 PM +0100 1/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
=item SHARED THREAD
A thread that's part of a group of threads sharing a common
interpreter environment.
I presume that this "group of threads" is one thread pool or
interpreter pool. Could you expand the d
On Monday, January 19, 2004, at 07:58 , [EMAIL PROTECTED]
wrote:
Is there any likelyhood that memory allocation will be hidden behind
macros at two levels:
- ALLOCPOOL() for allocating large chunks of memory (ppols) that are
later sub-allocated (and managed) by:
- SUBALLOC() for sub alloca
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>=item SHARED THREAD
> A thread that's part of a group of threads sharing a common
> interpreter environment.
I presume that this "group of threads" is one thread pool or
interpreter pool. Could you expand the definition to cover "pool".
>=item Each inter
> =item MUTEX
>
> This is a low level, under the hood, not exposed to users, thing that
> can be locked. They're non-recursive, non-read/write, exclusive
> things. When a thread gets a mutex, any other attempt to get that
> mutex will block until the owning thread releases the mutex. The
> platfor
"Dan Sugalski" <[EMAIL PROTECTED]> wrote:
> =head2 Guarantees
Maybe this isn't strictly a threading thing, but are we going to make any
guarantees about event orderings? For example, will we guarantee that a
sequence of events send from one thread to another will always be received
in the order th
On Monday, January 19, 2004, at 06:37 , Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all readers should be blocked as well.
True of non-moving collectors, too. [...]
Some of what I've written up addresses why. [...] I
At 12:58 AM + 1/20/04, [EMAIL PROTECTED] wrote:
> =item MUTEX
This is a low level, under the hood, not exposed to users, thing that
can be locked. They're non-recursive, non-read/write, exclusive
things. When a thread gets a mutex, any other attempt to get that
mutex will block until the o
On Tue, 20 Jan 2004 10:45, Dan Sugalski wrote;
> Yes. The recommendation I've always seen for deadlock avoidance is
> to always have all your code grab its mutexes in some fixed order.
Yes; otherwise, you need to back off and start again, if one lock
acquisition fails.
Consider these functio
Dan Sugalski wrote:
> For a copying collector to work, all the mutators must be blocked,
> and arguably all readers should be blocked as well.
True of non-moving collectors, too. Or, let me put it this way: non-
copying *GC* (the sweep or copy phase) can be threadsafe, but the mark
phase is neve
At 5:32 PM -0500 1/19/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
[A] copying collector is generally untenable in a threaded
environment.
Can you elaborate upon the reasoning behind this statement?
Sure. For a copying collector to work, all the mutators must be
blocked, and arguably all re
Dan Sugalski wrote:
> [A] copying collector is generally untenable in a threaded
environment.
Can you elaborate upon the reasoning behind this statement?
> The first thing that any vtable function of a shared PMC must do is to
> aquire the mutex of the PMCs in its parameter list, in ascending
At 2:44 PM -0700 1/19/04, Luke Palmer wrote:
Dan's thread proposal mentions:
=item Automatic PMC sharing will be provided
When a PMC is placed into a container which is shared (including
lexical pads and global namespaces) then that PMC will automatically
be marked as shared. It is acceptable
At 4:37 PM -0500 1/19/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> =item All shared PMCs must have a threadsafe vtable
DS> The first thing that any vtable function of a shared PMC must do is to
DS> aquire the mutex of the PMCs in its parameter list, in
Dan's thread proposal mentions:
> =item Automatic PMC sharing will be provided
>
> When a PMC is placed into a container which is shared (including
> lexical pads and global namespaces) then that PMC will automatically
> be marked as shared. It is acceptable for this to trigger an
> exception if f
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> =item All shared PMCs must have a threadsafe vtable
DS> The first thing that any vtable function of a shared PMC must do is to
DS> aquire the mutex of the PMCs in its parameter list, in ascending
DS> address order. When the mutexe
At 3:16 PM -0500 1/19/04, Dan Sugalski wrote:
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
First rip -- I left a section unfinished. It should be:
=item "Process-type" threads
The scheme must also support the perl 5 "iThreads" threading
model. In this model
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
=head1 DEFINITIONS
So we can all talk about things the same way, the following
definitons apply. Some of these are drawn from the POSIX thread spec,
and as such we should have a translation section at the end.
=o
At 3:11 PM -0500 1/19/04, Dan Sugalski wrote:
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
Whups, wrong list in the autocomplete. Just a hedge, citizen -- move along!
--
Dan
--"it's l
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
=head1 DEFINITIONS
So we can all talk about things the same way, the following
definitons apply. Some of these are drawn from the POSIX thread spec,
and as such we should have a translation section at the end.
=o
45 matches
Mail list logo
