 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31/01/2011 06:56 PM, Darren New wrote:
> 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.
Man, I had no idea...
>> 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.
Well, since the microcode is just a bunch of extremely wide bitmaps that
open and close various switches, it wouldn't surprise me if doing so in
the wrong combination could short-circuit something, or do something
similarly bad.
OTOH, maybe if the microcode is user-modifyable, you'd design in some
margin for error...
(Do modern AMD64 processors let you change the microcode? Or is it wired
in permanently?)
> 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.
Oh, OK.
> 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 what you're saying is it lets you access a file like you access
memory? (And presumably avoids the data being swapped out to the swap
file when you actually want it to end up in some other file anyway...)
>> 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.
OK.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> I thought that (for example) if a
> Unix process exits without freeing the memory it allocated, that memory
> remains allocated forever.
I really can't understand why you would think that. Processes ask the
OS for memory (how else is the OS able to allocate memory to different
processes?), but the OS would then just let that memory remain allocated
when the process ends, if it didn't ask the OS explicitly to free it?
*Why* would it do that, given that freeing the memory is, relatively
speaking, trivial?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Well, since the microcode is just a bunch of extremely wide bitmaps that
> open and close various switches, it wouldn't surprise me if doing so in
> the wrong combination could short-circuit something, or do something
> similarly bad.
That's a point. I don't think that's real common, tho. There's usually
something where you're connecting an input to an output. You connect the
memory bus to the register, not the power in to the power out. :-)
> So what you're saying is it lets you access a file like you access
> memory? (And presumably avoids the data being swapped out to the swap
> file when you actually want it to end up in some other file anyway...)
Yes, precisely.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> *Why* would it do that, given that freeing the memory is, relatively
> speaking, trivial?
On the Amiga, it's because you might have passed that memory to something
else, or loaded code into it to handle interrupts. But then, the Amiga was a
single-user OS with no memory protection, so you did that sort of thing. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31/01/2011 09:19 PM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> I thought that (for example) if a
>> Unix process exits without freeing the memory it allocated, that memory
>> remains allocated forever.
>
> I really can't understand why you would think that.
Because in order to do this, the OS would have to keep track of not only
what resources are in use, but *who* is using them.
OTOH, if you have virtual memory, you presumably have to keep track of
who's using which pages anyway...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 31/01/2011 14:28, Invisible a écrit :
>>> 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? And when you access anything in that
> region, the necessary pages are read from disk? (And, presumably, saved
> back to that file rather than being copied to swap when physical memory
> is required.)
>
> So... how do you change the size of the file then?
For a memmap-ed file, usually you don't.
For a normal file, opening in append mode, and using seek to reach the
right last byte counted from the start followed by either a write, if
you want to extend it or directly a truncate call if you want it shorter.
memmap is just a "convenient" way to access the bytes in a file, just
reading and writing them as an array in memory.
seek, read & write are just as good (but file oriented, so if your huge
and smart code is expecting an array of bytes... memmap come easy for
the lazy programers)
--
Software is like dirt - it costs time and money to change it and move it
around.
Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 31/01/2011 09:19 PM, Warp wrote:
> > Invisible<voi### [at] devnull> wrote:
> >> I thought that (for example) if a
> >> Unix process exits without freeing the memory it allocated, that memory
> >> remains allocated forever.
> >
> > I really can't understand why you would think that.
> Because in order to do this, the OS would have to keep track of not only
> what resources are in use, but *who* is using them.
That's kind of what the OS does.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Because in order to do this, the OS would have to keep track of not only
> what resources are in use, but *who* is using them.
Yes, it does that. Especially with VM, as you say, since every time the OS
switches to running a different process, it has to reassign what pages of
physical memory go with which virtual addresses.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31/01/2011 09:31 PM, Darren New wrote:
> Orchid XP v8 wrote:
>> Well, since the microcode is just a bunch of extremely wide bitmaps
>> that open and close various switches, it wouldn't surprise me if doing
>> so in the wrong combination could short-circuit something, or do
>> something similarly bad.
>
> That's a point. I don't think that's real common, tho. There's usually
> something where you're connecting an input to an output. You connect the
> memory bus to the register, not the power in to the power out. :-)
Connect two outputs together, with one trying to drive a line high, and
the other trying to drive it low, and you could have some "interesting"
problems.
>> So what you're saying is it lets you access a file like you access
>> memory? (And presumably avoids the data being swapped out to the swap
>> file when you actually want it to end up in some other file anyway...)
>
> Yes, precisely.
OK. So what's all this stuff about "the OS loads programs by memory
mapping them"? (Hopefully this will explain why programs show up as
generating a non-zero number of "page faults", even though no swapping
is actually happening...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Connect two outputs together,
I don't think two outputs would have a gate between them like that. However,
at this point I'm really over my head. I've never *actually* written
microcode for a real computer myself. :-)
> OK. So what's all this stuff about "the OS loads programs by memory
> mapping them"? (Hopefully this will explain why programs show up as
> generating a non-zero number of "page faults", even though no swapping
> is actually happening...)
It's exactly the same thing. If you have a chunk of executable that's
supposed to be in addresses 0x1000 to 0x3000, and that's at offset zero in
the file, you memmap the file into the page tables. Basically, you use the
executable file itself as the swap file for that region of memory.
That's why in UNIX you can delete a running executable file, but you can't
write to it. Because you're actually running code right out of the file, and
not a copy of the file.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
