Invisible wrote:
> On 22/12/2010 09:27 PM, Darren New wrote:
> 
>> 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.
> 
> I didn't know it actually did that. I thought that (for example) if a 
> Unix process exits without freeing the memory it allocated, that memory 
> remains allocated forever. (Presumably it gets pages out to disk fairly 
> soon, but even so...)

No, that would be AmigaOS (intentionally, it turns out). :-)

Linux closes files, deallocates memory, reclaims disk space for unlinked 
files that this process had the last open on, unlocks files, closes the file 
holding the executable code, frees up page maps, and releases certain kinds 
of semaphores. And probably more, nowadays.

>>> 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.
> 
> I was thinking more that if you get the microcode right, you might 
> physically fry the processor.

Oh. Not in any microcode I've ever seen (not that I've seen much), but I 
imagine it's possible.

>> 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.
> 
> I'm not sure I see how.

Because you couldn't have pointers into the middle of segments. The memory 
model was a bunch of "objects" in the sense that they were atomic lumps of 
memory that you could move around without adjusting pointers everywhere.

I only read about the assembly language of the thing, tho, so I don't really 
know any more details than that.

>> 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.
> 
> That sounds much more interesting.

That too. You can look up the details with google.

> 
>>> OK, now I must know... WTF is this "memmap" that I keep hearing about?
>>
>> http://lmgtfy.com/?q=what+is+memmap
> 
> I'm not sure I completely understand.
> 
> So, a memory-mapped file is a region of virtual memory which contains 
> the same data as a file on disk?

You know how swap space works, right? The page file?

memmap is using the exact same mechanism, except it pages out to the file 
you specify instead of "the swap space".

Or, viewed another way, all of memory is memmapped, and that system call 
lets you pick which file it's memmapped into instead of the default.

> So... how do you change the size of the file then?

I don't know that you do, if that's how you're accessing it. I haven't used 
it in so long that it's all probably changed by now.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message