On Fri, Feb 16, 2001 at 02:54:04PM -0500, Stephen P. Potter wrote:
> Is this (these) thread(s) to the point where it is worth spinning off a new
> sublist? If a couple of the main contributors (Dan, Simon,
Hey, I proudly know *nothing* about GC.
> say yes, can we get perl6-internals-gc created?
Is this (these) thread(s) to the point where it is worth spinning off a new
sublist? If a couple of the main contributors (Dan, Simon, Branden, etc)
say yes, can we get perl6-internals-gc created?
-spp
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> Be careful what you ask for from us language designers. If you're not
LW> careful, we'll take away your low-level primitives and give you something
LW> like Ada's rendezvous model.
Okay, give. You obviously think it is bad. (I don't know
Dan Sugalski writes:
: A language issue. Being able to require multiple locks upon entering a sub,
: along with timeouts and retries and such, would be very nice, and something
: for the language people. (Which probably means some of us over there, since
: I don't know that we have that much th
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> the user needs a mechanism to handle multi-object locking, or a clean
>> method to order his lock aquisition.
DS> A language issue. Being able to require multiple locks upon
DS> entering a sub, along with timeouts and retries and such, wo
At 06:15 AM 8/7/00 -0400, Chaim Frenkel wrote:
> > "JT" == John Tobey <[EMAIL PROTECTED]> writes:
>
>JT> SVs are never downgraded, so no one's source and destination are
>JT> another's respective destination and source. Maybe the above sequence
>JT> isn't exactly right, but if we adhere to st
> "JT" == John Tobey <[EMAIL PROTECTED]> writes:
JT> SVs are never downgraded, so no one's source and destination are
JT> another's respective destination and source. Maybe the above sequence
JT> isn't exactly right, but if we adhere to strict rules for lock
JT> sequencing, there won't be a
Chaim Frenkel wrote:
> The string/number duality should be handled by the vtbl. So a string that
> is never accessed as a number, doesn't waste the space. And numbers that
> are rarely accessed as a string save some room. And as needed the vtbl can
> be promoted to a duality version that maintain
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>And why carry around IV/NV and ptr? Make it into a union, to allow room.
_my_ original "ramblings" posting did.
I kept the triple to pad the thing to 8 words.
Partly as devil's advocate against the "squeeze it all into one word" camp ;-)
Essentially
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > ``Abundant macros, inline functions, and API functions will be
> > used wherever possible so as to allow fundamental changes to the
> > internal representation.''
>
> That belongs in a different RFC, the one roughing out the embedding,
> ex
At 10:30 AM 8/6/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 08:33 AM 8/6/00 -0400, John Tobey wrote:
> > >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
> > > > >Why waste space on flags? The vtbl should handle that.
>
John Tobey wrote:
> Sorry, I fail to see why. To upgrade or destroy an object:
>
> 1. lock the object
> 2. lock the source arena
> 3. lock the destination arena
> 4. move bits
> 5. unlock the destination arena
> 6. unlock the source arena
> 7. unlock the object
Arena
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 08:33 AM 8/6/00 -0400, John Tobey wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
> > > >Why waste space on flags? The vtbl should handle that.
> > >
> > > Because some flags are universal, and if t
At 08:33 AM 8/6/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
> > >Why waste space on flags? The vtbl should handle that.
> >
> > Because some flags are universal, and if they're not, this field
> > gets tossed.
>
>Flags tha
At 08:40 AM 8/6/00 -0400, John Tobey wrote:
>Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > >> If the sync data is in the SV, I believe there is a race
> > >> condition between the destruction and grabbing a lock.
> >
> > DS> Nope. If the variable is shared, the lock will need to be taken
> > DS> to
Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
> DS> Most of what gets flag-checked now will probably do this, yes.
>
> >> And why waste the GC data. I suspect that most variables will not be shared.
>
> DS> Doesn't matter whether they're shared. Mark & sweep, gene
Dan Sugalski wrote:
> I agree with this, though I'm pretty sure most scalars end up with multiple
> types. I'm up for either way, though--I think some test code is in order
> once things get a bit more hammered out. (I'd like to get some sample
> variable code put together in a few weeks, once the
On Sun, Aug 06, 2000 at 08:33:52AM -0400, John Tobey wrote:
> If the stuff lives in an arena, have one mutex-init lock per page of
> the arena. I imagine every arena page will be aligned on 4k or so and
> will have a structure at the beginning containing the interpreter
> pointer and stuff like t
On Sun, Aug 06, 2000 at 08:40:51AM -0400, John Tobey wrote:
> Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > >> If the sync data is in the SV, I believe there is a race
> > >> condition between the destruction and grabbing a lock.
> >
> > DS> Nope. If the variable is shared, the lock will need to b
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> >> If the sync data is in the SV, I believe there is a race
> >> condition between the destruction and grabbing a lock.
>
> DS> Nope. If the variable is shared, the lock will need to be taken
> DS> to destroy it. If it's not shared it's not an issue.
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
> >Why waste space on flags? The vtbl should handle that.
>
> Because some flags are universal, and if they're not, this field
> gets tossed.
Flags that vary only when the vptr varies could go in a field of
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Most of what gets flag-checked now will probably do this, yes.
>> And why waste the GC data. I suspect that most variables will not be shared.
DS> Doesn't matter whether they're shared. Mark & sweep, generational, and
DS> refcount garb
At 11:44 PM 8/5/00 -0400, Chaim Frenkel wrote:
>Why waste space on flags? The vtbl should handle that.
Because some flags are universal, and if they're not, this field gets tossed.
>There are a limited
>number of valid combinations, the vtbl could alter the behavior and
>trading space for speed,
Why waste space on flags? The vtbl should handle that. There are a limited
number of valid combinations, the vtbl could alter the behavior and
trading space for speed, no need to check flags. Alter the vtbl instead.
(Perhaps a simple state machine.)
And why waste the GC data. I suspect that most
At 01:03 PM 8/5/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > and it will require
> > jumping through a lot of hoops because of perl's profligate use of dynamic
> > polymorphing. If it's needed, well, we'll do it, but I'd rather put the
> > effort elsewhere to start.
>
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> That's going to complicate a lot of things, and it will mean perl will end
> up doing all sorts of temp SV creation when these 'mini SVs' get passed to
> subs. Plus it complicates life a lot for people writing the guts. (Which
> would be us. :)
The pro
At 02:45 PM 8/5/00 +, Nick Ing-Simmons wrote:
>We currently (perl5) have the "token" being:
>
>struct sv {
> void* sv_any; /* pointer to something */
> U32 sv_refcnt; /* how many references to us */
> U32 sv_flags; /* what we are */
>};
>
>3
At 08:12 AM 8/5/00 -0400, John Tobey wrote:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> > John Tobey <[EMAIL PROTECTED]> writes:
> > >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > >> Yup, and I realized one of my big problems to GCs that move memory
> > >> (references that are pointers and such)
John Tobey <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
>> John Tobey <[EMAIL PROTECTED]> writes:
>> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> >> Yup, and I realized one of my big problems to GCs that move memory
>> >> (references that are pointers and such) really i
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> Yup, and I realized one of my big problems to GCs that move memory
> >> (references that are pointers and such) really isn't, if we keep the
> >> two-level variabl
John Tobey <[EMAIL PROTECTED]> writes:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Yup, and I realized one of my big problems to GCs that move memory
>> (references that are pointers and such) really isn't, if we keep the
>> two-level variable structure that we have now. The 'main' SV structure
John Tobey writes:
> OK. Ask, cancel that request. Sorry.
In the future, it's best to address your list requests directly
to the working group chair. They'll decide and ask Ask. In fact,
asking Ask could probably be done offline.
Nat
OK. Ask, cancel that request. Sorry.
-John
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 02:45 PM 8/4/00 -0400, John Tobey wrote:
> >I guess, more than establishing a working group, I'm hoping to siphon
> >GC debates out of the more general internals list, since a lot of
> >people love discussin
At 02:45 PM 8/4/00 -0400, John Tobey wrote:
>I guess, more than establishing a working group, I'm hoping to siphon
>GC debates out of the more general internals list, since a lot of
>people love discussing GC at great length, and I don't expect that
>debate to have much relevance to the rest of th
At 02:48 PM 8/4/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Yup, and I realized one of my big problems to GCs that move memory
> > (references that are pointers and such) really isn't, if we keep the
> > two-level variable structure that we have now. The 'main' SV stru
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Yup, and I realized one of my big problems to GCs that move memory
> (references that are pointers and such) really isn't, if we keep the
> two-level variable structure that we have now. The 'main' SV structure
> won't move, while the guts that the equi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This seems a bit premature, given that we haven't actually come up with
> even a framework for an API, or hashed out much on the format of variables
> or the interpreter structure. (Nor the threading or event stuff...)
>
> Are you comfortable with a sho
At 12:31 PM 8/4/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> This seems a bit premature, given that we haven't actually come up with
>DS> even a framework for an API, or hashed out much on the format of
>variables
>DS> or the interpreter structure
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> This seems a bit premature, given that we haven't actually come up with
DS> even a framework for an API, or hashed out much on the format of variables
DS> or the interpreter structure. (Nor the threading or event stuff...)
Either the A
At 09:42 AM 8/4/00 -0400, John Tobey wrote:
>Oops, I guess this should be contingent on Dan Sugalski's approval.
This seems a bit premature, given that we haven't actually come up with
even a framework for an API, or hashed out much on the format of variables
or the interpreter structure. (Nor
Oops, I guess this should be contingent on Dan Sugalski's approval.
-John
John Tobey <[EMAIL PROTECTED]> wrote:
> Ask, can we please have the following list:
>
> Name: perl6-internals-gc
> Chairs: John Tobey <[EMAIL PROTECTED]>
> Ken Fox <[EMAIL PROTECTED]>
> De
Ask, can we please have the following list:
Name: perl6-internals-gc
Chairs: John Tobey <[EMAIL PROTECTED]>
Ken Fox <[EMAIL PROTECTED]>
Deadline: Conterminous with perl6-internals (currently 13
October 2000)
Mission:Determine which g
42 matches
Mail list logo
