[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MIT-Scheme-devel] Bug: Poor error message; maybe a sign of somethin
Re: [MIT-Scheme-devel] Bug: Poor error message; maybe a sign of something worse?
Tue, 20 Sep 2011 16:11:39 -0700
> From: Taylor R Campbell <address@hidden>
> Date: Tue, 20 Sep 2011 19:10:19 +0000
> To recap: Alexey's symptom is that LIAR chokes when it generates a
> straight-line sequence of machine code that exceeds 64 kilobytes. The
> immediate source of the problem is that the format word just before
> any straight-line sequence of code saying how far it is from the start
> of the previous one is a 16-bit field.
Break the block. What's a little register dumping and interrupt
testing for a healthy, young machine? [pinch]
> I could `fix' it by taking, say, the maximum value and reinterpreting
> it to mean an extra-long 32-bit format word precedes it or something.
> However, that doesn't solve the real problem, which is that straight-
> line sequences of code are uninterruptible, either by ^G or by a heap
> overflow or whatever.
Thus the "basic" in "basic block". I'm afraid your "problem" is my
> We allow interrupt handlers [only when] the stack looks good.
> As long as the code polls for interrupts periodically, this is OK.
> Currently, `periodically' is at most every 64 kilobytes of machine
> instructions, which is reasonable enough, but expanding that to every
> four gigabytes of instructions sounds rather sketchy.
Ya: "No" to 4GB basic blocks.
> Another approach would [...] take substantial re-engineering [...]
And a BIG smack up side the portabimini.
> I don't see any nice way to work around or solve this problem, without
> just splitting the input to LIAR into separate procedures, which is
> what I have advised Alexey to do.
Hang on; you lost me. What basic block spans procedures? How does
separating procedures break basic blocks?
> [*] As an aside, I don't think we test for heap overflow reliably: I
> suspect the heap can overflow before we poll for interrupts.
> Certainly there are no formally engineered limits in place, or
> bookkeeping in the code generator, to prevent that from happening.
> But that's a separate issue.
There is a 64KB basic block limit. It's not easy to prove, from that
limit, that some number of bytes in a safe-landing cushion will always
be SAFE, but I want to run some things in the GC interrupt handler
anyway. That cushion just better be BIG. ;-)