Orchid XP v8 wrote:
> And yet, code written in languages assuming GC management and languages 
> assuming manual management can not only interoperate, but even be linked 
> together in the same process image.

Sure. But then you get things like "finalizers" to clean up unmanaged 
resources, the "using" statement to enforce the use of finalizers, all kinds 
of odd rules in the GC engine that slow it down because it has to deal with 
finalizers, etc.

Sort of the same way that when a process in UNIX exits, there's a list of 
things the kernel cleans up for it on its way out.

> That sounds moderately mental. I'd hate to think what happens if you get 
> the microcode wrong...

The same as if you get any other program wrong. What do you mean? It's 
probably far easier than writing a modern bytecode interpreter like the JVM.

> Not even built into the language - built into a library. And, 
> presumably, by changing that library, you can change how the filesystem 
> works...

Right. That's the idea. Basically, what's a file? It's a data structure you 
access. Why is a file different from an array of bytes held by a process 
that just never exits?

> Well, to some extent there /is/. By definition, an application is 
> something that solves a real-world problem, and an OS is something that 
> provides services to applications.

Where do you draw the distinction, if there's exactly one application 
running on the custom OS?

>> 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.
> 
> Sure. If the virtual address space supports it, why not? (Other than 
> "because most OS designs assume that you would never want to do such a 
> thing".)

Well, that's exactly the point. Most computer languages completely ignore 
virtual memory. Only managed OO languages come close to having a concept of 
memory as something other than an array of bytes, and even that is more 
segments than pages.

I used to use an HP mainframe that was incapable of running C, because it 
was a segmented chip. It was really old, but it would be ideal for running 
an OO language nowadays, because you had tons of segments available, etc. 
Basically, pointers pointed to segments, not bytes, so it was in hindsight a 
very OO kind of architecture.

The Burroughs B series had typed machine code. Each memory address also had 
tag bits saying what type was stored there, so the machine code just had an 
"add" instruction, not an "add integers" or "add floats". The operands said 
what the type was. And array accesses had to go through an array pointer, 
which included the bounds of the array.  Again, another machine you couldn't 
run C on.

> OK, now I must know... WTF is this "memmap" that I keep hearing about?

http://lmgtfy.com/?q=what+is+memmap

> I'm more dubious about how useful it is for everyone else. 

As I've said, I think that the very small and the very large will both be 
using this sort of thing more and more. If you can cut $5 off the cost of 
building a TiVO by using a language other than C, you'll see that happening. 
If you can cache 20% more stuff on a memcached-like server by ditching 
Linux, you'll see Amazon starting to do that I expect. Most large servers 
are single-purpose nowadays anyway.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message