[racket-dev] stypes.h + 3M woes

You're right that the comment about keys under 256 is out of date.

The GC implementation should take _scheme_last_type_ into account. My
initial thought is that the array needs to be bigger than that, because
the intent is that new type tags can be created at run time with
scheme_make_type(). Then again, values with a new tag created via
scheme_make_type() must be allocated as atomic, since the protocol for
extending the GC for non-atomic types is not currently intended to be
public.

If you're modifying "stypes.h", though, "public" is not relevant. You
should be able to add lots of new types to "stypes.h" without reaching
512 or otherwise running into GC limits, though you do need to
registers traversal functions with the GC for the new type tags.

Maybe you can say more about what you're trying to do overall? I think
I'm probably giving you incomplete advice here, but I'm not sure which
of the various implementation details (type tags having GC traversal
procedures, type-tag names, hashing, versioning) are relevant for your
task.

At Sun, 5 May 2013 23:40:32 -0400, Jon Zeppieri wrote:
> I overlooked the crucial line of the second stack trace. The
> fixup_table and mark_table fields of the NewGC each allocate space for
> 512 function pointers, indexed by type tag (I think). So, when I tried
> to create a tag with 512 as it's value, I ended up writing outside of
> the array bounds. Maybe those arrays should have length
> _scheme_last_type_?
> 
> -Jon
> 
> 
> On Sun, May 5, 2013 at 8:16 PM, Jon Zeppieri <zeppieri at gmail.com> wrote:
> > When I try to make a hole in the enumeration defined in stypes.h (by
> > explicitly setting the value of a member), I get a segfault in the 3m
> > build, though not the cgc one.
> >
> > Depending on where I place the hole, I've seen different stack traces.
> > If I place the new tag before the _rt_ tags, then I get:
> >
> > #0  0x00007fff886d9db0 in bzero$VARIANT$sse42 ()
> > #1  0x000000010030d5ea in malloc_pages () at vm_osx.c:185
> > #2  0x0000000100314106 in allocate_big (request_size_bytes=32807,
> > type=0) at newgc.c:974
> > #3  0x0000000100314e08 in GC_malloc_weak_array (size_in_bytes=16384,
> > replace_val=0x0) at newgc.c:1463
> >
> > If I place it after (which is where I want to place it), I get:
> >
> > #0  0x0000000000000000 in ?? ()
> > #1  0x0000000100310e9f in repair_heap [inlined] () at
> > /Users/jaz/src/racket/src/racket/gc2/newgc.c:4171
> > #2  0x0000000100310e9f in garbage_collect (gc=0x7fff5fbf7c00,
> > force_full=5339440, switching_master=1606384640, lmi=0x7fff5fbf7c00)
> > at newgc.c:4753
> > #3  0x000000010031487a in scheme_get_thread_local_variables [inlined]
> > () at /Users/jaz/src/racket/src/racket/include/schthread.h:1283
> > #4  0x000000010031487a in allocate_slowpath [inlined] () at
> > /Users/jaz/src/racket/src/racket/gc2/newgc.c:1289
> > #5  0x000000010031487a in allocate (request_size=4300306736,
> > type=1606384720) at newgc.c:1348
> > #6  0x00000001002ad122 in scheme_make_stx_w_offset (val=0x102a00300,
> > src=0x1003b10b8, props=0x1003b10b8, line=-1, col=-1, pos=1553,
> > span=140734799772896) at syntax.c:577
> >
> >
> > I noticed that gc2.h's description of GC_init_type_tags() mentions
> > that the count parameter will always be less than 256, and I wondered
> > if that could be causing a problem, because I was trying to create a
> > type tag with a value of 512. However, the comment appears to be
> > wrong, because stypes.h currently defines tags up to 259
> > (_scheme_last_type_ == 260), and it looks like _scheme_last_type_ is
> > used as the count param in salloc.c.
> >
> > Is there some other limit (aside from the limit of Scheme_Type itself,
> > which is defined as a short, so that's at least 16 bits)?  Or is there
> > an assumption that the enumeration is dense? Or something else?
> >
> > -Jon
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev