GC needs to know about all references in the program. If the mutator (the program) is running concurrently with the collector, it's difficult (though not impossible) for the collector to construct this consistent view.
That's certainly the case for full CPS, but using a CPS intermediate language does not imply call/cc. Indeed Kennedy targeted the .Net CIL; a direct-style VM. The important thing to note is that continuations and functions can be statically distinguished. The article conflates the two, which is why I don't find it very useful.
I recommend Andrew Kennedy's "Compiling with Continuations, Continued" article if you are actually interested in using continuations in a production compiler. Might's formulation of CPS is good for analysis but not actually that great for code generation in my opinion. My take on the topic is here: http://wingolog.org/archives/2014/01/12/a-continuation-passi...
AFAIUI libc is in the initrd, but it's a statically linked libc. Guile's dynamic FFI uses dlopen/dlsym to get its function pointers, so it can't do that in a statically linked libc. (Or could it? I suppose there's no reason why a statically linked library wouldn't expose symbol tables, whether via dlsym or some other means.)
Your point about size is well-taken though. Besides libc in this case, Guile's build products are much larger (and slower) than LuaJIT's images because we've been trying to write the compiler in Scheme from the very beginning. We can't even think about doing a nice JIT until we have a good AOT compiler, because otherwise the JIT written in Scheme would be too slow.
You can redirect the control-flow of the program by overwriting a return address or a vtable. Once you've done that, it's easiest if you can redirect control to code you've written, in executable heap; but if that's not possible, you can still use return-to-libc, or potentially "return-oriented programming" strategies.
Sure, it's possible. The sequence of multiplications chosen to reach the exponent is different, so these expressions take different paths through scm_integer_expt.
* libguile/numbers.c (scm_product): Avoid signed integer overflow, which
modern C compilers are allowed to assume will never happen, thus
allowing them to optimize out our overflow checks.
Sounds like your problem is more that Scheme is too small for the programs you'd like to write. Implementations that are adequate to your needs being incompatible with each other is a natural side effect.
The new standard will help marginally, but there will be no grand unification of Schemes. R6RS was big enough for your needs but did not achieve wide adoption. There is no fundamental reason why this would be different for the larger R7RS report (on which work has not yet begun). Indeed, some implementations have already forked with an explicit intention of going on their own paths (Racket).
In short, for serious work, you might be able to share modules between implementations if that matters to you, but your overall application will be implementation-specific.
"MCNP is written in the style of Dr. Thomas N. K. Godfrey, the principal MCNP programmer from 1975-1989 ... All variables local to a routine are no more than two characters in length, and all COMMON variables are between three and six characters in length ... The principal characteristic of Tom Godfrey's style is its terseness. Everything is accomplished in as few lines of code as possible. Thus MCNP does more than some other codes that are more than ten times larger. It was Godfrey's philosophy that anyone can understand code at the highest level by making a flow chart and anyone can understand code at the lowest level (one FORTRAN line); it is the intermediate level that is most difficult. Consequently, by using a terse programming style, subroutines could fit within a few pages and be most easily understood. Tom Godfrey's style is clearly counter to modern computer science programming philosophies, but it has served MCNP well and is preserved to provide stylistic consistency throughout."
Well, I guess the one thing I would correct is the "why". The LLInt doesn't just produce assembler to be fast, though it is faster than the old interpreter. The real reason it produces assembler is to control the stack representation, so that it works better with tiering, exceptions, and the optimizing compiler (DFG). Otherwise, interpreting was a lose, because tiering up cost too much.
As you can see, the situation is a bit complicated. If I could have made the article shorter, I would have :)
No offense intended, but this comment does not add very much while misunderstanding some other things. For example, I did not write the LLInt. It was mostly written by Apple's Filip Pizlo.
If this is the sort of topic you are interested in, then you can have the patience to read a few paragraphs. If it's not, then summarizing isn't going to help :)
Nice work, and (as another fastmail.fm user) thank you for the responsible disclosure. May it amply repay you in consulting gigs :)
Regarding the script injection from image file names, there is a simple solution to this problem: separate the data types of strings and document structure. For example:
I look forward to seeing articles on Moore's work; I did not have the pleasure of knowing him.
In the meantime, this headline had me a little confused, thinking of the chip designer Chuck Moore who was Forth's creator. It doesn't seem that this is the same Moore. Just FYI :)
A few articles I wrote on working at Igalia last year:
http://wingolog.org/archives/2013/06/05/no-master
http://wingolog.org/archives/2013/06/13/but-that-would-be-an...
http://wingolog.org/archives/2013/06/25/time-for-money