This scheme with constant strings in constant memory doesn't work - at least not with ARENA_DOD_FLAGS enabled, which assumes *all* objects are coming from arenas. These string headers live outside of any arena.
Oh, yes--darn.
It could work w/o ARENA_DOD_FLAGS *if* these strings get additional flags set: - is_live ... would prohibit setting live bits - dont_touch_or_free_header ... might be needed for destruction
I wonder if it's possible to identify these at runtime as living in the C-constant region of memory? For instance, if we could tell their memory address is < stack base, and use that to identify them as constant?
But with ARENA_DOD_FLAGS enabled, I don't see much chance to get this running. This would need collecting all constant strings in an aligned memory segment, attach an arena header to it and set live bits in attached dod_flags - a lot of work for a preprocessor, albeit doable with a lot of effort.
It should be possible to aggregate all of the constants into a single array (one include, rather than one-per-source-file), which would let us identify them by their memory location, as residing in this range. That seems pretty straightforward to do. So rather than compiling to static_string_532, instead _S("foo") would compile to static_strings[7], or something. Then the check is just whether (some_string >= static_strings[0] && some_string <= static_strings[max])--if so, it was from a literal (and thus, is constant).
PS why I really like to have something like this:
$ time parrot -jG ff.pasm 010
real 0m1.728s # with _S("__get_integer") real 0m2.148s # with const_string(...)
Yes, it seems like a good idea, in general terms; quite reasonable, as an extension of what C already does for C strings. (FWIW, ObjC has support for literal NSStrings--I'm not sure how much of the "work" is done at compile-time v. runtime, though the tricky part for us is really GC, which isn't a factor for ObjC. I wonder what Java does for string literals? Maybe something similar to the above.)
JEff
