Duane Rettig <email@example.com> wrote:
| On the third hand, I have often raised some ruckus in comp.arch
| to ask them there for fast user-level trap handling as the
| best way for general-purpose computer architectures to support
| garbage-collected langauges. If such an architecture (plus
| supporting kernel) were to ever be available in a general
| purpose operating system, then even if such a conditional
| trap were to take 30-50 cycles, it would still be worthwhile
| to pursue it to replace the 5-10 cycle software barrier, since
| software barriers tend to never be zero-cost, but traps, when
| not taken, do tend to be zero cost, so the challenge is to find
| the best algorithm that minimizes the number of times a trap is
| actually taken.
But notice that the Hosking, et al, paper I cited in a parallel reply
made the point that it's not necessarily the cost of the trap that's
the killer, but the large size of a hardware page [4 KB or larger]
compared to the optimum card size [256-512 bytes]. With a page-trapping
system, at GC time you have to scan *all* of each page that got stored
into, even if only one word got stored per page.
Unfortunately, as memory sizes grow, pressure on TLB sizes will only
push hardware page sizes higher & higher. As I noted in the other
reply, some (non-PC) servers already default to 16 KB pages, and in
some applications use *much* larger hardware page sizes -- *megabytes*,
even!! -- to avoid TLB thrashing. In those situations, software write
barriers once again become a big win.
 SGI's Origin systems, running Irix on MIPS, support up to *16 MB*
pages for large HPC apps. This is aided enormously by the fact that
the MIPS TLB supports multiple page sizes in a single process, so
that not all shared-library pages have to be huge just because the
app is using large pages in some other part of its address space.
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607