[Openmcl-devel] Solaris x86-64?

[Chris Curtis]

On Jan 2, 2008, at 11:39 AM, Gary Byers wrote:

> I played around it a little a year or two ago; I don't currently
> have Solaris installed and what I remember is a little fuzzy, so
> take this with a grain of salt ...

Well, what you call "fuzzy" is often better than my good days... ;-)

> There was something different (relative to Linux, Darwin, and FreeBSD)
> about how Solaris's mmap (the system call used to ... map memory)
> implementation worked; the lisp wants to try to reserve a large
> (512GB) chunk of address space, preferably at a fixed address.  The
> way that the we do it, Solaris would (I'm a little fuzzy on the
> details) either give us a a large chunk or let us excerise control
> over where it was, but not both.  When it allocated the large
> chunk of address space, the addresses in question were in the
> upper half of the 64-bit address space (had their sign bit on),
> and I was concerned that something, somewhere in the lisp would
> get confused by this.  (I read somewhere that Solaris's mmap()
> will behave more like other OS's if one tries to map a file
> descriptor open on /dev/zero rather than trying to create
> an anonymous mapping like CCL's kernel does, but I never tried
> that.)

Interesting... MAP_ANON is defined as being exactly equivalent to mmap- 
ing /dev/zero (at least in the man page).

FWIW, when I tested it just now, my mmap of (1024L<<30L) at  
0x300000000000L Solaris agrees with me and gives it back at that base.  
(There's still the issue that it's also happily unmapping everything  
else in that range, but that's a separate problem -- one Darwin has  
already -- and presumably easy enough to fix.)

> That's about as far as I got; the lisp kernel compiled but
> the initial memory reservation didn't behave the way that
> I'd have liked it to.  I didn't get far enough to stress
> anything else, but I'd guess that there'd likely some other
> OS-dependent code (signal/exception handling) that'd have
> to be conditionalized.  It's hard to know whether there
> are other things that behave differently from what the
> lisp expects/wants, but it'd probably take about a week or
> two to account for the expected/minor OS differences.

Yeah, Linux and Solaris have a few differences in signals, including a  
different delivery order. But otherwise Solaris seems fairly POSIXly  
consistent in this area, which (hopefully) means most of the  
differences were already sniffed out under darwin.

> The x86-64 port needs (or at least really, really wants)
> some way to set the gs segment register so that it points
> to per-thread lisp data.  I don't remember whether Solaris
> offers a way to do this; if not, it might be hard to work
> around that.

That one I'd have to spend a little more time digging into... nothing  
off the top of my head, since I've tried really hard to forget  
everything I ever knew about segmented memory.

So it at least looks like it's at least somewhat possible. I know it's  
definitely not available for normal user consumption, but is there any  
guide somewhere as to how I'd go about starting to build the codebase  
from scratch? It seems somehow a waste to run lx-branded zones on  
Solaris just to get CCL running. (Plus, it'd be really nifty to add  
the dtrace hooks....)

--chris