mit-scheme-devel
[Top][All Lists]
Advanced

[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


From: Taylor R Campbell
Subject: Re: [MIT-Scheme-devel] Bug: Poor error message; maybe a sign of something worse?
Date: Wed, 21 Sep 2011 00:38:04 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/9.1

   Date: Tue, 20 Sep 2011 16:11:39 -0700
   From: Matt Birkholz <address@hidden>

   > 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]

It would take delicate surgery to LIAR.  A little less than register
maps that interrupt handlers can parse, perhaps, but a nontrivial
amount nevertheless.  Simply saving registers to their homes is not
enough; they wouldn't be saved in continuations or traced as GC roots.

   > Another approach would [...] take substantial re-engineering [...]

   And a BIG smack up side the portabimini.

Not with the native compiler back ends, really.

   > 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?

Splitting one procedure into two can split one basic block into two.

   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. ;-)

What is easy is constructing a counterexample to the proposition that
some amount of space is guaranteed.  For example, I imagine that a
sufficiently large procedure of (%record 0 0 0 0 0 0 0 (%record 0 0 0
0 0 0 0 (%record ...))) would easily exceed the default safety margin
without coming near 64 kilobytes of straight-line machine code.

What is hard is going through LIAR and either (a) proving that there
are no counterexamples left, or (b) making it do enough bookkeeping to
guarantee that allocations lie within the safety margin or to emit an
interrupt branch that takes the potential allocations into account
when checking for heap overflow.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]