|
 |
Orchid XP v8 wrote:
> Perhaps. I guess it kind of depends on what you're trying to do. If you
> have an application that just does its computations in its own little
> world, then it's fine. If, on the other hand, the application wants to
> do arbitrary stuff with the whole machine, then... yeah.
Not necessarily. There are memory models that really just don't mix, for
example. GCed memory with non-GCed external resources is the classic. This
paper describes how if you assume you have a C-like/Pascal-like workload,
using thousands of page faults a second to do GC isn't going to be
efficient. Etc.
> Wasn't there an OS written in Smalltalk at some point? (Or was that only
> for special hardware?)
Yes. The "dolphin" computer. It had programmable microcode, so when you
booted a Smalltalk image, the machine code *was* smalltalk bytecodes. When
you booted a COBOL program, the machine code was appropriate for COBOL.
> Certainly you can see that if the Smalltalk
> runtime was running on the bare metal, it would have all sorts of
> interesting consequences. (For example, since *everything* can be
> changed, you could invent some new bizare concept of files.)
They had what you'd consider a bizarre concept for files. That's the point.
You didn't have to worry about "destructors" for files, precisely because
"file" was built into the language, not the OS. So to speak.
> if you tried to write an actual "operating system" in Haskell, rather
> than just an application.
But that's the point. When your application runs on the bare metal, there's
no distinction between OS and application.
>> http://www.artima.com/lejava/articles/azul_pauseless_gc.html
>
> That contains a lot of "look at us, aren't we clever!" and not very much
> technical detail. It seems the only novel detail is that they're using
> the memory protection hardware to trap and remap accesses to moved
> objects. That's a neat detail, and one which (they assert) would be too
> inefficient with a normal OS. But that seems to be just about it.
That's the only neat technical trick they used to implement their other
tricks. I think it's more interesting that they're actually getting away
from the linear memory model that C and Pascal foisted on us.
In other words, they're using an OO memory model. Objects are contiguous
blobs, but it doesn't really matter beyond that where they are in the
address space. So instead of doing a compacting garbage collection in a
linear space, they do a compacting garbage collection on a per-page basis.
*That* is really the innovation.
> Haskell has a rather interesting invariant: since *most* objects are
> immutable, old objects can never point to new objects. It seems like
> this should make some kind of interesting GC algorithm possible.
Erlang takes great advantage of that too, yes.
> Personally, I thought the article on GC avoiding paging was more
> interesting.
Yeah. Again, it's the sort of thing you have a hard time doing in an OS
tuned for something with a memory model like C's.
>> Traditional file system interfaces probably do too.
>
> Now, do you mean "file systems", or do you mean "interfaces to file
> systems"?
Interfaces. The reality of file systems nowadays isn't anywhere near what
the interface looks like. Internally, it's much closer to multic's file
system, yet it's generally presented with UNIX file system semantics.
(In Multics, the basic way of getting to a file was essentially memmap.
That's why UNIX files are all represented as an array of bytes, with no
records, no insert/delete bytes, etc. It's modeling multics' interface
without the convenience of either having it in memory *or* having the OS
provide you useful services.)
> Well, we'll see what happens.
Yeah, sadly, I don't have a whole lot of hope. Altho the thing with each
application running in its own Xen hypervisor slot sounds interesting. I'll
have to look at the implications of that a little more closely.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
