Re: [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 zeppi...@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 0x7fff886d9db0 in bzero$VARIANT$sse42 () #1 0x00010030d5ea in malloc_pages () at vm_osx.c:185 #2 0x000100314106 in allocate_big (request_size_bytes=32807, type=0) at newgc.c:974 #3 0x000100314e08 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 0x in ?? () #1 0x000100310e9f in repair_heap [inlined] () at /Users/jaz/src/racket/src/racket/gc2/newgc.c:4171 #2 0x000100310e9f in garbage_collect (gc=0x7fff5fbf7c00, force_full=5339440, switching_master=1606384640, lmi=0x7fff5fbf7c00) at newgc.c:4753 #3 0x00010031487a in scheme_get_thread_local_variables [inlined] () at /Users/jaz/src/racket/src/racket/include/schthread.h:1283 #4 0x00010031487a in allocate_slowpath [inlined] () at /Users/jaz/src/racket/src/racket/gc2/newgc.c:1289 #5 0x00010031487a in allocate (request_size=4300306736, type=1606384720) at newgc.c:1348 #6 0x0001002ad122 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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] stypes.h + 3M woes
On Mon, May 6, 2013 at 8:08 AM, Matthew Flatt mfl...@cs.utah.edu wrote: 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. Right, but I was trying to add a new type with the explicit value of 512. That's where I ran into trouble with the fixup_table and mark_table. 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. I was looking into what it would take to add immediately represented types, other than fixnums, to racket. The eventual goal is to represent characters in the (Scheme_Object *) word itself. The code point would occupy the upper N-1 bytes of the word, and the least significant byte would contain a type tag. Since fixnums have a 1 in the least significant bit, and pointers have #b00 in their least significant bits, the tag would have to end with #b10. First, I thought about reserving the first 256 type tags for immediates (which would be sparsely populated, since, again, they need to end in #b10). Then I realized that the order of groups of tags in stypes.h is significant. Possibly the order could be reversed, to put the internal objects last, rather than first. But since I'm trying to change as little as possible, my next thought was to shift the raw tag (the least significant byte of the word) 8 bits to the left. So, the first valid immediate tag would then be 512. (For type-specific predicates, the shift wouldn't be necessary; CHARP could be defined as ((obj) 0xff == 2), for example, but the generic SCHEME_TYPE macro would need to do a bit more work.) So, I was trying to move scheme_char_type to the end of the list, with an explicit value of 512. The first step was just to change the type tag. Then I could try to change the actual representation. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] stypes.h + 3M woes
At Mon, 6 May 2013 11:58:13 -0400, Jon Zeppieri wrote: On Mon, May 6, 2013 at 8:08 AM, Matthew Flatt mfl...@cs.utah.edu wrote: 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. Right, but I was trying to add a new type with the explicit value of 512. That's where I ran into trouble with the fixup_table and mark_table. 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. I was looking into what it would take to add immediately represented types, other than fixnums, to racket. The eventual goal is to represent characters in the (Scheme_Object *) word itself. The code point would occupy the upper N-1 bytes of the word, and the least significant byte would contain a type tag. Since fixnums have a 1 in the least significant bit, and pointers have #b00 in their least significant bits, the tag would have to end with #b10. First, I thought about reserving the first 256 type tags for immediates (which would be sparsely populated, since, again, they need to end in #b10). Then I realized that the order of groups of tags in stypes.h is significant. Possibly the order could be reversed, to put the internal objects last, rather than first. But since I'm trying to change as little as possible, my next thought was to shift the raw tag (the least significant byte of the word) 8 bits to the left. So, the first valid immediate tag would then be 512. (For type-specific predicates, the shift wouldn't be necessary; CHARP could be defined as ((obj) 0xff == 2), for example, but the generic SCHEME_TYPE macro would need to do a bit more work.) So, I was trying to move scheme_char_type to the end of the list, with an explicit value of 512. The first step was just to change the type tag. Then I could try to change the actual representation. Ok. I guess all you need to do for now is change `NUMBER_OF_TAGS' in newgc.c to a large enough value. _ Racket Developers list: http://lists.racket-lang.org/dev
