From: Godmar Back (gback@cs.utah.edu)
Date: Thu Dec 03 1998 - 19:23:47 EST
>
> On Dec 3, 1998, Archie Cobbs <archie@whistle.com> wrote:
>
> > Alexandre Oliva writes:
>
> >> Can't we just junk the old scheme and adopt the new one? Is it likely
> >> to break anything?
>
> > Yeah, we should fix it. When is "block.old" going to go away and
> > "block.new" replace it?
>
> Well, from what I've just read in FAQ.gcblock, not any time soon :-(
>
> What do you think of gc-block-hash for the old scheme and
> gc-block-mmap for the new one? I was thinking of moving them into
> kaffevm/mem, and just select the appropriate blocking scheme with
> configure/Makefile hacks. Is that ok?
>
That was fine by me. Using symlinks instead of subdirectories is fine too.
Just remember to make sure it works for both people configuring
in the source tree and those who do not. But you're aware of this.
About the restrictions:
I'm discussing a few options with Jason and Edouard, and Jason will be doing
some tests. Basically, the problem is managing your virtual address space
portably.
One of the avenues we're looking at it to preallocate virtual addresses
by mmapping large pieces: the question then becomes how big the OS
overhead is for that.
As soon as we have a solution that works for the major platforms
(let's include Solaris here), I would like to make it the default.
I think the old scheme will hang around for platforms that do not
support mmap --- similar to how unix-internal hangs around for platform
with not setitimer & friends support. People using Kaffe on these
platforms will keep it up-to-date, if not it will practically die of
natural causes.
The reason I wanted to check it in is so that Jason would get feedback
and so that other people could become familiar with the idea and evaluate
its performance improvements. The improvement is not stellar --- but
it does reduce the run-time library's compile time from 24 to 21 seconds on
an older PII/333 (that's the most important testcase).
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:05 EDT