Leopold Toetsch wrote:
> Gordon Henriksen wrote:
>
> > Or, hell, put the flags directly in the VTABLE if it's not
> > necessary for them to vary across instances.
>
> No, flags are mutable and per PMC *not* per class.
Of course there are flags which must remain per-PMC. I wasn't
referring to them. Sorry if that wasn't clear.
If a flag is only saying "my VTABLE methods use the UnionVal as {a
void*/a PObj*/a PMC*/data}, so GC should trace accordingly," it may be
a waste of a per-object flag bit to store those flags with the PMC
instance rather than with the PMC class. And if it's with the VTABLE,
then it doesn't need to be traced. (But, then, all PObjs don't have
VTABLES...)
Sidebar:
If we're looking at lock-free concurrency, flag updates probably have
to be performed with atomic &'s and |'s. BUT: Doesn't apply during GC,
since other threads will have to be stalled then.
> > Do any PMC classes use *both* struct_val *and* pmc_val concurrently?
>
> E.g. iterator.pmc. UnmanagedStruct uses int_val & pmc_val. This is no
> problem. These PMCs don't morph.
Er, int_val and pmc_val at the same time? That's not quite what the
layout
provides for:
typedef union UnionVal {
struct { /* Buffers structure */
void * bufstart;
size_t buflen;
} b;
struct { /* PMC unionval members */
DPOINTER* _struct_val; /* two ptrs, both are defines */
PMC* _pmc_val;
} ptrs;
INTVAL int_val;
FLOATVAL num_val;
struct parrot_string_t * string_val;
} UnionVal;
Says to me:
struct_val and pmc_val concurrently
-- or --
bufstart and buflen concurrently
-- or --
int_val
-- or --
num_val
-- or --
string_val
I don't know if C provides a guarantee that int_val and ptrs._pmc_val
won't
overlap just because INTVAL and DPOINTER* fields happen to be the same
size.
At least one optimizing compiler I know of, MrC/MrC++, would do some
struct
rearrangement when it felt like it.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
