Super good question. I owned and used NeXT slabs, 1992 - 1999.
The Mach-as-microkernel thing couldn't have helped portability. The Mach task, port, thread and pager abstractions seem like they'd be difficult to port, but I could be wrong.
I read at the time that NeXTStep the GUI ran faster on Solaris than on Mach, because pipes and sockets were faster than Mach ports. So I'll believe the very little assembly.
I suspect that Mach-O file format had something to do with the portability, you can put arbitrary sections in it. Some NeXT games kept image and sound "files" in a single huge Mach-O executable.
"Mach 3 (Figure B.1) moves the BSD code outside
of the kernel, leaving a much smaller microkernel. This system implements
only basic Mach features in the kernel; all UNIX-specific code has been evicted
to run in user-mode servers. Excluding UNIX-specific code from the kernel
allows replacement of BSD with another operating system or the simultaneous
execution of multiple operating-system interfaces on top of the microkernel.
In addition to BSD, user-mode implementations have been developed for DOS,
the Macintosh operating system, and OSF/1. This approach has similarities to
the virtual-machine concept, but the virtual machine is defined by software
(the Mach kernel interface), rather than by hardware."
Early in that timeline Solaris was heavily into being a "pure" System V r4. The pipes and sockets implementations were based on System V Streams -- the in joke was that streams were much more like sewers and they weren't pleasant. Numbers wise, they were perhaps 2 orders of magnitude slower than on SunOS (BSD based). At one state university, where a very "beefy" SPARCcenter 2000 was purchased to support 500 simultaneous users, Solaris on this system could barely support 40 users (streams performance was the reason - telnet sessions pushed several streams modules). Sun ended up having to provide 10 SPARCstation 10 systems running SunOS which could easily support 70 simultaneous users each in order to fulfill the contractual obligations. The SPARCcenter 2000 was turned into an NFS file server.
After the early days, Solaris did improve, but I think that was because ideas / pieces of BSD (from SunOS) were put back into the OS.
I don't think Solaris pipes / sockets performed better than Mach.
Early Solaris was definitely not very good. I briefly ran Solaris 2.4 on a SparcStation 5, and reinstalled SunOS 4.1.x because Solaris 2.4 was so bad. 2.5 was decent though!
The impression I always got from those abstractions were that they were precisely there to support portability. Pagers, for example, are quite flexible about what can back them and what the geometry of that backing can be.
Yes, but it was explicitly a different kind of portability: running MSDOS or VMS executables unchanged, for example.
The task/port/thread/pagers are primitives that let Mach run some other OS executables, not made it easy to port Mach to other hardware. There were papers about getting MSDOS and VMS executables to run in Mach tasks. Some startup was making a system to run (pre-OSX) Mac executables.
The Mach-as-microkernel thing couldn't have helped portability. The Mach task, port, thread and pager abstractions seem like they'd be difficult to port, but I could be wrong.
I read at the time that NeXTStep the GUI ran faster on Solaris than on Mach, because pipes and sockets were faster than Mach ports. So I'll believe the very little assembly.
I suspect that Mach-O file format had something to do with the portability, you can put arbitrary sections in it. Some NeXT games kept image and sound "files" in a single huge Mach-O executable.