 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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...)
>> 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.
>> 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?
I suppose to some extent it's a bit arbitrary. But if you have, say, a
library who's only purpose is to take graphics requests and poke the
necessary hardware registers to make pixels change colour, you could
call that part of an OS.
The "first" OS was of course the Disk Operating System, remember. ;-)
> 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.
> 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.
>> 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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
