This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 19 Oct, 2006 1 commit
  2. 07 Oct, 2006 1 commit
  3. 30 May, 2006 1 commit
    • Simon Marlow's avatar
      replace stgMallocBytesRWX() with our own allocator · e3c55aeb
      Simon Marlow authored
      See bug #738
      
      Allocating executable memory is getting more difficult these days.  In
      particular, the default SELinux policy on Fedora Core 5 disallows
      making the heap (i.e. malloc()'d memory) executable, although it does
      apparently allow mmap()'ing anonymous executable memory by default.
      
      Previously, stgMallocBytesRWX() used malloc() underneath, and then
      tried to make the page holding the memory executable.  This was rather
      hacky and fails with Fedora Core 5.  
      
      This patch adds a mini-allocator for executable memory, based on the
      block allocator.  We grab page-sized blocks and make them executable,
      then allocate small objects from the page.  There's a simple free
      function, that will free whole pages back to the system when they are
      empty.
      e3c55aeb
  4. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  5. 05 Apr, 2006 1 commit
  6. 21 Feb, 2006 1 commit
    • Simon Marlow's avatar
      fix a deadlock in atomicModifyMutVar# · 25cc1d1f
      Simon Marlow authored
      atomicModifyMutVar# was re-using the storage manager mutex (sm_mutex)
      to get its atomicity guarantee in SMP mode. But recently the addition
      of a call to dirty_MUT_VAR() to implement the read barrier lead to a
      rare deadlock case, because dirty_MUT_VAR() very occasionally needs to
      allocate a new block to chain on the mutable list, which requires
      sm_mutex.
      25cc1d1f
  7. 09 Feb, 2006 2 commits
  8. 08 Feb, 2006 2 commits
    • Simon Marlow's avatar
      fix a bug in closure_sizeW_() · a50e6825
      Simon Marlow authored
      a50e6825
    • Simon Marlow's avatar
      make the smp way RTS-only, normal libraries now work with -smp · beb5737b
      Simon Marlow authored
      We had to bite the bullet here and add an extra word to every thunk,
      to enable running ordinary libraries on SMP.  Otherwise, we would have
      needed to ship an extra set of libraries with GHC 6.6 in addition to
      the two sets we already ship (normal + profiled), and all Cabal
      packages would have to be compiled for SMP too.  We decided it best
      just to take the hit now, making SMP easily accessible to everyone in
      GHC 6.6.
      
      Incedentally, although this increases allocation by around 12% on
      average, the performance hit is around 5%, and much less if your inner
      loop doesn't use any laziness.
      beb5737b
  9. 17 Jan, 2006 1 commit
    • simonmar's avatar
      [project @ 2006-01-17 16:13:18 by simonmar] · 91b07216
      simonmar authored
      Improve the GC behaviour of IORefs (see Ticket #650).
      
      This is a small change to the way IORefs interact with the GC, which
      should improve GC performance for programs with plenty of IORefs.
      
      Previously we had a single closure type for mutable variables,
      MUT_VAR.  Mutable variables were *always* on the mutable list in older
      generations, and always traversed on every GC.
      
      Now, we have two closure types: MUT_VAR_CLEAN and MUT_VAR_DIRTY.  The
      latter is on the mutable list, but the former is not.  (NB. this
      differs from MUT_ARR_PTRS_CLEAN and MUT_ARR_PTRS_DIRTY, both of which
      are on the mutable list).  writeMutVar# now implements a write
      barrier, by calling dirty_MUT_VAR() in the runtime, that does the
      necessary modification of MUT_VAR_CLEAN into MUT_VAR_DIRY, and adding
      to the mutable list if necessary.
      
      This results in some pretty dramatic speedups for GHC itself.  I've
      just measureed a 30% overall speedup compiling a 31-module program
      (anna) with the default heap settings :-D
      91b07216
  10. 18 Nov, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-11-18 15:24:12 by simonmar] · c5cd2343
      simonmar authored
      Two improvements to the SMP runtime:
      
        - support for 'par', aka sparks.  Load balancing is very primitive
          right now, but I have seen programs that go faster using par.
      
        - support for backing off when a thread is found to be duplicating
          a computation currently underway in another thread.  This also
          fixes some instability in SMP, because it turned out that when
          an update frame points to an indirection, which can happen if
          a thunk is under evaluation in multiple threads, then after GC
          has shorted out the indirection the update will trash the value.
          Now we suspend the duplicate computation to the heap before this
          can happen.
      
      Additionally:
      
        - stack squeezing is separate from lazy blackholing, and now only
          happens if there's a reasonable amount of squeezing to be done
          in relation to the number of words of stack that have to be moved.
          This means we won't try to shift 10Mb of stack just to save 2
          words at the bottom (it probably never happened, but still).
      
        - update frames are now marked when they have been visited by lazy
          blackholing, as per the SMP paper.
      
        - cleaned up raiseAsync() a bit.
      c5cd2343
  11. 21 Oct, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-10-21 14:02:17 by simonmar] · 03a9ff01
      simonmar authored
      Big re-hash of the threaded/SMP runtime
      
      This is a significant reworking of the threaded and SMP parts of
      the runtime.  There are two overall goals here:
      
        - To push down the scheduler lock, reducing contention and allowing
          more parts of the system to run without locks.  In particular,
          the scheduler does not require a lock any more in the common case.
      
        - To improve affinity, so that running Haskell threads stick to the
          same OS threads as much as possible.
      
      At this point we have the basic structure working, but there are some
      pieces missing.  I believe it's reasonably stable - the important
      parts of the testsuite pass in all the (normal,threaded,SMP) ways.
      
      In more detail:
      
        - Each capability now has a run queue, instead of one global run
          queue.  The Capability and Task APIs have been completely
          rewritten; see Capability.h and Task.h for the details.
      
        - Each capability has its own pool of worker Tasks.  Hence, Haskell
          threads on a Capability's run queue will run on the same worker
          Task(s).  As long as the OS is doing something reasonable, this
          should mean they usually stick to the same CPU.  Another way to
          look at this is that we're assuming each Capability is associated
          with a fixed CPU.
      
        - What used to be StgMainThread is now part of the Task structure.
          Every OS thread in the runtime has an associated Task, and it
          can ask for its current Task at any time with myTask().
      
        - removed RTS_SUPPORTS_THREADS symbol, use THREADED_RTS instead
          (it is now defined for SMP too).
      
        - The RtsAPI has had to change; we must explicitly pass a Capability
          around now.  The previous interface assumed some global state.
          SchedAPI has also changed a lot.
      
        - The OSThreads API now supports thread-local storage, used to
          implement myTask(), although it could be done more efficiently
          using gcc's __thread extension when available.
      
        - I've moved some POSIX-specific stuff into the posix subdirectory,
          moving in the direction of separating out platform-specific
          implementations.
      
        - lots of lock-debugging and assertions in the runtime.  In particular,
          when DEBUG is on, we catch multiple ACQUIRE_LOCK()s, and there is
          also an ASSERT_LOCK_HELD() call.
      
      What's missing so far:
      
        - I have almost certainly broken the Win32 build, will fix soon.
      
        - any kind of thread migration or load balancing.  This is high up
          the agenda, though.
      
        - various performance tweaks to do
      
        - throwTo and forkProcess still do not work in SMP mode
      03a9ff01
  12. 25 Jul, 2005 1 commit
  13. 13 May, 2005 1 commit
  14. 12 May, 2005 1 commit
  15. 10 May, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-05-10 13:25:41 by simonmar] · bf821981
      simonmar authored
      Two SMP-related changes:
      
        - New storage manager interface:
      
          bdescr *allocateLocal(StgRegTable *reg, nat words)
      
          which allocates from the current thread's nursery (being careful
          not to clash with the heap pointer).  It can do this without
          taking any locks; the lock only has to be taken if a block needs
          to be allocated.  allocateLocal() is now used instead of allocate()
          in a few PrimOps.
      
          This removes locks from most Integer operations, cutting down
          the overhead for SMP a bit more.
      
          To make this work, we have to be able to grab the current thread's
          Capability out of thin air (i.e. when called from GMP), so the
          Capability subsystem needs to keep a hash from thread IDs to
          Capabilities.
      
        - Small MVar optimisation: instead of taking the global
          storage-manager lock, do our own locking of MVars with a bit of
          inline assembly (x86 only for now).
      bf821981
  16. 27 Apr, 2005 2 commits
  17. 22 Apr, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-04-22 09:32:39 by simonmar] · 0f3205e6
      simonmar authored
      SMP: the rest of the changes to support safe thunk entry & updates.  I
      thought the compiler changes were independent, but I ended up breaking
      the HEAD, so I'll have to commit the rest.  non-SMP compilation should
      not be affected.
      0f3205e6
  18. 12 Apr, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-04-12 09:04:23 by simonmar] · 693550d9
      simonmar authored
      Per-task nurseries for SMP.  This was kind-of implemented before, but
      it's much cleaner now.  There is now one *step* per capability, so we
      have somewhere to hang the block count.  So for SMP, there are simply
      multiple instances of generation 0 step 0.  The rNursery entry in the
      register table now points to the step rather than the head block of
      the nurersy.
      693550d9
  19. 05 Apr, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-04-05 12:19:54 by simonmar] · 16214216
      simonmar authored
      Some multi-processor hackery, including
      
        - Don't hang blocked threads off BLACKHOLEs any more, instead keep
          them all on a separate queue which is checked periodically for
          threads to wake up.
      
          This is good because (a) we don't have to worry about locking the
          closure in SMP mode when we want to block on it, and (b) it means
          the standard update code doesn't need to wake up any threads or
          check for a BLACKHOLE_BQ, simplifying the update code.
      
          The downside is that if there are lots of threads blocked on
          BLACKHOLEs, we might have to do a lot of repeated list traversal.
          We don't expect this to be common, though.  conc023 goes slower
          with this change, but we expect most programs to benefit from the
          shorter update code.
      
        - Fixing up the Capability code to handle multiple capabilities (SMP
          mode), and related changes to get the SMP mode at least building.
      16214216
  20. 04 Apr, 2005 1 commit
  21. 27 Mar, 2005 1 commit
    • panne's avatar
      [project @ 2005-03-27 13:41:13 by panne] · 03dc2dd3
      panne authored
      * Some preprocessors don't like the C99/C++ '//' comments after a
        directive, so use '/* */' instead. For consistency, a lot of '//' in
        the include files were converted, too.
      
      * UnDOSified libraries/base/cbits/runProcess.c.
      
      * My favourite sport: Killed $Id$s.
      03dc2dd3
  22. 09 Mar, 2005 1 commit
    • wolfgang's avatar
      [project @ 2005-03-09 08:51:31 by wolfgang] · abde5fdf
      wolfgang authored
      Retain all CAFs when dynamic Haskell libraries are used from GHCi.
      The Linker usually replaces references to newCAF with references to newDynCAF,
      but the system dynamic linker won't do that for us.
      
      Also, the situation is slightly different - we never want CAFs from dylibs
      to be reverted, because the dylibs might be used both by the interpreted
      program and by GHCi itself.
      
      So instead of just caf_list, there's now both caf_list and revertible_caf_list.
      newDynCAF adds a CAF to revertible_caf_list, and newCAF either adds the CAF
      to caf_list or to the mutable list, depending on whether we are in GHCi.
      
      This hack is only active when Linker.c has loaded libHSbase_dyn.[so|dylib],
      but for now, it applies to all CAFs, not just dynamically-linked ones.
      If that is worth fixing, we could do that by checking whether the the CAF
      closure or it's info pointer is in the main executable's address range.
      
      MERGE TO STABLE
      abde5fdf
  23. 10 Feb, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-02-10 13:01:52 by simonmar] · e7c3f957
      simonmar authored
      GC changes: instead of threading old-generation mutable lists
      through objects in the heap, keep it in a separate flat array.
      
      This has some advantages:
      
        - the IND_OLDGEN object is now only 2 words, so the minimum
          size of a THUNK is now 2 words instead of 3.  This saves
          some amount of allocation (about 2% on average according to
          my measurements), and is more friendly to the cache by
          squashing objects together more.
      
        - keeping the mutable list separate from the IND object
          will be necessary for our multiprocessor implementation.
      
        - removing the mut_link field makes the layout of some objects
          more uniform, leading to less complexity and special cases.
      
        - I also unified the two mutable lists (mut_once_list and mut_list)
          into a single mutable list, which lead to more simplifications
          in the GC.
      e7c3f957
  24. 07 Oct, 2004 1 commit
    • wolfgang's avatar
      [project @ 2004-10-07 15:54:03 by wolfgang] · b4d045ae
      wolfgang authored
      Position Independent Code and Dynamic Linking Support, Part 1
      
      This commit allows generation of position independent code (PIC) that fully supports dynamic linking on Mac OS X and PowerPC Linux.
      Other platforms are not yet supported, and there is no support for actually linking or using dynamic libraries - so if you use the -fPIC or -dynamic code generation flags, you have to type your (platform-specific) linker command lines yourself.
      
      
      nativeGen/PositionIndependentCode.hs:
      New file. Look here for some more comments on how this works.
      
      cmm/CLabel.hs:
      Add support for DynamicLinkerLabels and PIC base labels - for use inside the NCG.
      needsCDecl: Case alternative labels now need C decls, see the codeGen/CgInfoTbls.hs below for details
      
      cmm/Cmm.hs:
      Add CmmPicBaseReg (used in NCG),
      and CmmLabelDiffOff (used in NCG and for offsets in info tables)
      
      cmm/CmmParse.y:
      support offsets in info tables
      
      cmm/PprC.hs:
      support CmmLabelDiffOff
      Case alternative labels now need C decls (see the codeGen/CgInfoTbls.hs for details), so we need to pprDataExterns for info tables.
      
      cmm/PprCmm.hs:
      support CmmLabelDiffOff
      
      codeGen/CgInfoTbls.hs:
      no longer store absolute addresses in info tables, instead, we store offsets.
      Also, for vectored return points, emit the alternatives _after_ the vector table. This is to work around a limitation in Apple's as, which refuses to handle label differences where one label is at the end of a section. Emitting alternatives after vector info tables makes sure this never happens in GHC generated code. Case alternatives now require prototypes in hc code, though (see changes in PprC.hs, CLabel.hs).
      
      main/CmdLineOpts.lhs:
      Add a new option, -fPIC.
      
      main/DriverFlags.hs:
      Pass the correct options for PIC to gcc, depending on the platform. Only for powerpc for now.
      
      nativeGen/AsmCodeGen.hs:
      Many changes...
      Mac OS X-specific management of import stubs is no longer, it's now part of a general mechanism to handle such things for all platforms that need it (Darwin [both ppc and x86], Linux on ppc, and some platforms we don't support).
      Move cmmToCmm into its own monad which can accumulate a list of imported symbols. Make it call cmmMakeDynamicReference at the right places.
      
      nativeGen/MachCodeGen.hs:
      nativeGen/MachInstrs.hs:
      nativeGen/MachRegs.lhs:
      nativeGen/PprMach.hs:
      nativeGen/RegAllocInfo.hs:
      Too many changes to enumerate here, PowerPC specific.
      
      nativeGen/NCGMonad.hs:
      NatM still tracks imported symbols, as more labels can be created during code generation (float literals, jump tables; on some platforms all data access has to go through the dynamic linking mechanism).
      
      driver/mangler/ghc-asm.lprl:
      Mangle absolute addresses in info tables to offsets.
      Correctly pass through GCC-generated PIC for Mac OS X and powerpc linux.
      
      includes/Cmm.h:
      includes/InfoTables.h:
      includes/Storage.h:
      includes/mkDerivedConstants.c:
      rts/GC.c:
      rts/GCCompact.c:
      rts/HeapStackCheck.cmm:
      rts/Printer.c:
      rts/RetainerProfile.c:
      rts/Sanity.c:
      Adapt to the fact that info tables now contain offsets.
      
      rts/Linker.c:
      Mac-specific: change machoInitSymbolsWithoutUnderscore to support PIC.
      b4d045ae
  25. 13 Aug, 2004 2 commits
  26. 12 Nov, 2003 1 commit
    • sof's avatar
      [project @ 2003-11-12 17:49:05 by sof] · 20593d1d
      sof authored
      Tweaks to have RTS (C) sources compile with MSVC. Apart from wibbles
      related to the handling of 'inline', changed Schedule.h:POP_RUN_QUEUE()
      not to use expression-level statement blocks.
      20593d1d
  27. 22 Apr, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-04-22 16:25:08 by simonmar] · 1da232fc
      simonmar authored
      Fix an obscure bug: the most general kind of heap check,
      HEAP_CHECK_GEN(), is supposed to save the contents of *every* register
      known to the STG machine (used in cases where we either can't figure
      out which ones are live, or doing so would be too much hassle).  The
      problem is that it wasn't saving the L1 register.
      
      A slight complication arose in that saving the L1 register pushed the
      size of the frame over the 16 words allowed for the size of the bitmap
      stored in the frame, so I changed the layout of the frame a bit.
      Describing all the registers using a single bitmap is overkill when
      only 8 of them can actually be pointers, so now the bitmap is only 8
      bits long and we always skip over a fixed number of non-ptr words to
      account for all the non-ptr regs.  This is all described in StgMacros.h.
      1da232fc
  28. 27 Mar, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-03-27 13:54:31 by simonmar] · bf8b921f
      simonmar authored
      Two performance tweaks:
      
        - Use specialised indirections, which perform the right kind of
          return without needing to enter the object they point to.  This
          saves a small percentages of memory reads.
      
        - Tweak the update code to generate better code with gcc.  This
          saves a few instructions per update.
      bf8b921f
  29. 26 Mar, 2003 1 commit
  30. 24 Mar, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-03-24 14:46:53 by simonmar] · b3f53081
      simonmar authored
      Fix some bugs in compacting GC.
      
      Bug 1: When threading the fields of an AP or PAP, we were grabbing the
      info table of the function without unthreading it first.
      
      Bug 2: eval_thunk_selector() might accidentally find itself in
      to-space when going through indirections in a compacted generation.
      We must check for this case and bale out if necessary.
      
      Bug 3: This is somewhat more nasty.  When we have an AP or PAP that
      points to a BCO, the layout info for the AP/PAP is in the BCO's
      instruction array, which is two objects deep from the AP/PAP itself.
      The trouble is, during compacting GC, we can only safely look one
      object deep from the current object, because pointers from objects any
      deeper might have been already updated to point to their final
      destinations.
      
      The solution is to put the arity and bitmap info for a BCO into the
      BCO object itself.  This means BCOs become variable-length, which is a
      slight annoyance, but it also means that looking up the arity/bitmap
      is quicker.  There is a slight reduction in complexity in the byte
      code generator due to not having to stuff the bitmap at the front of
      the instruction stream.
      b3f53081
  31. 21 Mar, 2003 1 commit
    • sof's avatar
      [project @ 2003-03-21 16:18:37 by sof] · 557bca73
      sof authored
      Friday morning code-wibbling:
      - made RetainerProfile.c:firstStack a 'static'
      - added RetainerProfile.c:retainerStackBlocks()
      557bca73
  32. 13 Dec, 2002 1 commit
  33. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      ------------------------------------------
      
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
      
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
      
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
      
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
      
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
      
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
      
        - Info tables are a bit more complicated.  See InfoTables.h for the
          details.
      
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
          fixed.
      
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
      
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
      0bffc410
  34. 21 Oct, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-10-21 11:38:53 by simonmar] · 2be44cb2
      simonmar authored
      Bite the bullet and generalise the central memory allocation scheme.
      Previously we tried to allocate memory starting from a fixed address,
      which was set for each architecture (0x5000000 was a common one), and
      to decide whether a particular address was in the heap or not we would
      do a simple comparison against this address.
      
      This doesn't work too well, because:
      
       - if we dynamically-load some objects above the boundary, the
         heap-allocated test becomes invalid
      
       - on windows we have less control, and the heap might be
         split into multiple sections
      
       - it turns out that on some Linux kernels we don't get memory where
         we asked for it.  This might be a bug in those kernels, but it
         exposes the fragility of our allocation scheme.
      
      The solution is to bite the bullet and maintain a table mapping
      addresses to a value indicating whether that address is in the heap or
      not.  Since we normally allocate heap in chunks of 1Mb, the table is
      quite small: 4k on a 32-bit machine, using one byte for each 1Mb
      block.  Testing an address for heap residency now involves a memory
      access, but the table is normally cache-resident.  I didn't manage to
      measure any slowdown after making the change.
      
      On a 64-bit machine, we'll need to use a 2-level table; I haven't
      implemented that yet.
      
      Now we can generalise the procedure used to grab memory from the OS.
      In the general case, we allocate one megablock more than we need to,
      and trim off the slop around the allocation to leave an aligned chunk.
      The next time around, however, we try to allocate memory right after
      the last chunk allocated, on the grounds that it is aligned and
      probably free: if this doesn't work, we have to back off to the
      general mechanism (it seems to work most of the time).
      
      This cleans up the Windows story too: is_heap_alloced() has gone, and
      we should be able to handle more than 256M of memory (or whatever the
      arbitrary limit was before).
      
      MERGE TO STABLE (after lots of testing)
      2be44cb2
  35. 26 Mar, 2002 2 commits
    • sof's avatar
      [project @ 2002-03-26 23:56:44 by sof] · b6beb173
      sof authored
      TEXT_BEFORE_HEAP & cygwin: same as for mingw
      b6beb173
    • simonmar's avatar
      [project @ 2002-03-26 10:43:15 by simonmar] · 4b5f32d7
      simonmar authored
      A couple of cleanups to the previous change: we should test
      TABLES_NEXT_TO_CODE rather than USE_MINIINTERPRETER to enable the
      MacOSX "plan C", and use structure field selection rather than array
      indexing to get the entry code ptr from the info table.
      4b5f32d7