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, no need to check flags. Alter the vtbl instead.
>(Perhaps a simple state machine.)
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.
Doesn't matter whether they're shared. Mark & sweep, generational, and
refcount garbage collection all need workspace.
>Put the sync data into a seperate area and then access the external data.
There lies race conditions. (cf 5.6.0's lock issues) For synchronization
data to be valid it must be there at creation time. If it needs to be
tacked on later you run into race issues with multiple threads trying to
init the sync data.
>If the sync data is in the SV, I believe there is a race condition between
>the destruction and grabbing a lock.
Nope. If the variable is shared, the lock will need to be taken to destroy
it. If it's not shared it's not an issue.
>And why carry around IV/NV and ptr? Make it into a union, to allow room.
Speed? Valid tradeoff, though. We can do it both ways to see what's better.
>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 maintains
>both.
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 big things get laid out)
> >>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
>
>NI> So my own favourite right now allows a little more - to keep data and
>token
>NI> together for cache, and to avoid extra malloc() in simple cases.
>NI> Some variant like:
>
>NI> struct {
>NI> vtable_t *vtable; // _new_ - explcit type
>NI> IV flags; // sv_flags
>NI> void *sync_data; // _new_ - for threads etc.
>NI> IV GC_data; // REFCNT
>NI> void *ptr; // SvPV, SvRV
>NI> IV iv; // SvIV, SvCUR/SvOFF
>NI> NV nv; // SvNV
>NI> }
>
>NI> The other extreme might be just a pointer with LS 3 bits snaffled for
>NI> "mark" and two "vital" flags - but that just means above lives via the
>NI> pointer and everything is one more de-ref away _AND_ needs masking
>NI> except for "all flags zero" case (which had better be the common one).
>
>NI> As I recall my LISP it has two pointers + flags
>
>--
>Chaim Frenkel Nonlinear Knowledge, Inc.
>[EMAIL PROTECTED] +1-718-236-0183
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
