Memory hogging in an OS without paging

[Colonel Kernel]

a microsoft researcher i once met was working on such single-space protections mechanism.

If you don't mind me asking, who was he/she and how did you meet him/her?

One of the thing he used was to modify the 'present' mappings as thread were tunnelled from one component to another. E.g. as the thread leaves the 'application' context to run code from the TCP component, parts from the TCP component were now mapped as present (they were previously marked absent so that the application cannot harm them), and as the thread executed IP component, TCP pages were hidden again and IP pages revealed. When the thread finally returned to the application, everything came back to "normal".

That sounds a lot like the way Windows CE works (just read up on it last night). I guess it saves you from having to flush all non-global TLB entries -- instead you'd just have to flush all the entries for the two apps involved in the "process switch". I'm not sure the complexity is worth it.

i dunno if they integrated that into singularity or not, however.

I doubt it. Singularity depends entirely on static verification of type-safe code to ensure that one process does not refer to memory owned by another process. It's pretty cool, actually -- I recommend reading their technical report. Unfortunately for us hobbyists, their compiler technology is way beyond what any one of us could hope to whip up in our spare time.

Because of all these questions bubbling in my mind about memory management, I've now started looking at how I will design IPC, and to figure that out, I'm trying to imagine how I might eventually implement a TCP/IP stack or file system. I wanted to keep things practical, but I guess sometimes you need to take a step back and reflect in order to make the next big design decision...

[JoeKayzA]

Unfortunately for us hobbyists, their compiler technology is way beyond what any one of us could hope to whip up in our spare time.

...and that was exactly the reason why I laid down my virtual machine based OS design again. I simply didn't want to use an existing one like mono (although it claims to be easily portable - so it should be possible to create a standalone version of it), but designing a new one on my own, with compilers...simply too much.

cheers Joe

[Pype.Clicker]

a microsoft researcher i once met was working on such single-space protections mechanism.

If you don't mind me asking, who was he/she and how did you meet him/her?

sure. He was Austin Donnelly, who presented a paper Lightweight Thread Tunelling in Network Applications at IWAN'02, where i presented a paper myself too.

[Rob]

Singularity, as I understand it, does allow passing a memory block from one process to another (through what they call the exchange heap). So the process points into the exchange heap (memory is allocated on that). The "trick" is that only one process (thread?) can own (write acccess) a region of memory inside the exchange heap. If you pass it to another process you loose control of it (basically). Multiple processes can read from it though.

Sounds a lot like what is described above. Also I saw a Windows Vista movie on channel 9 on the new audio system / stack which implements something a bit similar with audio buffers. I'm not sure how or if it is protected though...

[Colonel Kernel]

Singularity, as I understand it, does allow passing a memory block from one process to another (through what they call the exchange heap). So the process points into the exchange heap (memory is allocated on that). The "trick" is that only one process (thread?) can own (write acccess) a region of memory inside the exchange heap. If you pass it to another process you loose control of it (basically). Multiple processes can read from it though.

Yeah, that's a pretty neat compiler trick. It reminds me of the semantics of std::auto_ptr in C++.

This notion of transferring ownership of a block of memory rather than copying it is very similar in spirit to message passing via page table manipulation. I'm investigating whether the avoidance of copying is worth the additional complexity for my poor, unmanaged, 20th century OS.

[Rob]

It very well might be. The advantage of not copying is especially valuable in high throughput cases like video, audio and things like networking. But you probably already knew that ;D

[Candy]

It very well might be. The advantage of not copying is especially valuable in high throughput cases like video, audio and things like networking. But you probably already knew that ;D

I've been designing my lowlevel driver handling around not copying, so that all you keep passing back & forth are page numbers. Also, I'm trying to add a FIFO-type cylindrical buffer with C++ STL-ish syntax to make multithreading easier, and I'm trying to automate the use of it (so you don't even have to explicitly add fifo's in between).

[Kevin McGuire]

@Candy, Rob, Colonel Kernel
That was my idea for about 2 years now. Just use pages to share memory for high performance thoughput between processes, and encapsulate the page share method into packets or messages.

Sigularity, was trying to use .NET code for as much of the operating system as possible. They threw performance out the window, and decided to work towards.. security - or something if I remember correctly. They even changed the .NET JIT compiler, to something like a virtual machine I think so that it compiles code ahead of time..?

@Candy
I use a FIFO cylindrical style buffer too, and im trying to get the CRT to a condition where you as the programmer does not have to deal with it - but with-out sacrificing performance.

[Rob]

kmcguire: actually their (Singularity's) primary goal is on security and stability. However, they are also looking at perfomance.

The advantage (as they've explained in their papers and videos) of having a completely intepreted environment is that they have no need for hardware isolation of processes and thus no ring 3 <-> ring 0 transitions. Coupled with (special) shareable buffers (passing a buffer to another process also passes owner ship so you can't corrupt "shared" memory) means no data copying which enhances performance.

This clearly shows that although interpreted code is (normally) slower it can get you (potentially huge) performance benefits in other areas while maintaining security.

From what I understand they compile the IL/bytecode to native instructions when you install something into the system. It has no JIT compiler on board (this would be bad for a number of reasons as they explain in their videos). However the system will only accept IL binaries, so you can't run a binary you compiled yourself (to x86 code).

Since they have sources of numerous internal compilers it is "easy" to combine these tools to operate in such a way.

[Colonel Kernel]

This clearly shows that although interpreted code is (normally) slower it can get you (potentially huge) performance benefits in other areas while maintaining security.

IL is never interpreted. In .NET, it's JIT compiled, and in Singularity, it's pre-compiled to native code by the Bartok compiler at install-time.

[Rob]

That's correct. I couldn't find the right English words to use
(Dutch is my first language). What I kind of meant was that
when you write code it is not compiled into a binary your
processor understands. It still needs to be "interpreted" for
that. Either in a virtual machine kind of way, JIT'ing or futher
compilation.

Sorry about that...

[Crazed123]

memory usage hysteresis?

so we aren't cruel to processes experience some peeks of memory usage in their lifetime?

Just an idea.

That makes a lot of sense as a policy. My question was more about mechanism. Without paging (i.e. -- the ability to save the contents of dirty pages that the OS is about to give to some other process) or a "visible revocation" protocol, what other mechanisms can be used? The quota is one, although it attacks the problem quite early by preventing a process from allocating "too much" memory in the first place. But this might be cruel, as you said. I'm thinking more along the lines of how to correct a bad situation once a process has already allocated nearly all memory...

Here's something to think about: What if you do have paging but all swap space is used?

[Kevin McGuire]

@Rob, Colonel Kernel
Oh. I see. Its is compiled once it is installed onto the system. Now, it makes sense from what I remember. Security and stability, with performance later if naturaly.

Ok, They did not throw performance out the window par say. I don't know where I come up with that stuff.

Thanks.

[Candy]

@Candy
I use a FIFO cylindrical style buffer too, and im trying to get the CRT to a condition where you as the programmer does not have to deal with it - but with-out sacrificing performance.

I'm aiming for the exact opposite, which makes my design a bit awkward. You have to program for the CRT specifically, after which it allows you to recombine existing code without knowing how it looks. In the vein of modular programming like C++ OO, but with linking at runtime with modules that can be produced after you compile your code. Can be linked even with modules that weren't available at the time of starting the program, so if you install an update all your running programs can use that without any changes.

Main problem, the datatypes must be set in stone and there needs to be quite a bit of default stuff before it's useful. So, that's my main userland problem. Stuff like images, files and streams of either of these are pretty simple (image => something you can display, image stream => movie, file => thing that contains bytes, file stream => rar file, tar file etc.) but there are more complex things such as converting between files and N-channel sound, where I cannot determine N beforehand. Also, there need to be filters from type X to type X, such as echo effects on sound channels and blurring (sharpening, stretching etc) a movie in runtime.

[Kevin McGuire]

That sounds interesting. I was on the same path a year ago, and I still am really. Although I simplified it due to the fact I thought they would be too much overhead trying to make a sorta global standard for all communication.

I figured instead of defining a global standard for communication, I decided on a way that would be suited for the service or driver, I think you could call it. It just felt like too much work. It sounds like you are making a global encapsulation standard which is great, but is it worth it and what are the advantages you get from it?

I am it seems, if I understand you correctly, going to need to (from the eyes of a developers) write modules that dynamicly link which has not been directly on my mind and is not now, or the equivilent which is on my mind for starters a library of obj and headers that the program includes that are the CRT you could say for communication with a certain service.
(I know CRT isnt the right word, but I was trying to stay consistant with my last post. )
(The process<->kernel comm. is contained in the CRT.)

The reason I thought it would be too much overhead is because a audio service for example would not need any knowledge of graphical objects or meta-data. So it seemed like overhead, when its communication standard could be optimized by removing those meta-(objects, concepts) from its stream you could call the packet.

My current design, with some un-needed stuff knocked out for this post's description, is:
(this is a standard so far only for process<->kernel comm.)
(it uses a persistant page - 4096kb)

struct tCmdHeader{
unsigned int flags;
unsigned int cmdPtr;
};
struct tCmd{
unsigned int flags;
unsigned int extraSize;
unsigned int next; // relative offset from page address.
unsigned int cmd;
};

As the packet is filled with commands, they are linked in a list struct. Each one can carry extra data, at the end of its tCmd struct. This method does work, it is not just a idea. I have it currently implemented.

struct tcmdQueryCount{
unsigned int count;
};

initPacket(); // init tcmdHeader
addCmd(CMD_QUERYCOUNT, &QueryCount, sizeof(QueryCount);
// This links a cmd into the packet, and sets some
// extra space to hold the return.
// #add some more cmds.. if needed.
executePacket(); // sets flag, packet gets executed.
// #do some stuff while waiting..
// get result


BUT, this is just the way the kernel likes to communicate. As far as a developer is concerned that could use multiple packets and could do any sorta of design they wanted. I am just trying to get some ideas flowing here, because I feel my design is lacking? It took me roughly 3 - 4 function calls just to setup the packet and add commands. I want something FAST and light weight. I want it flexible!

I'v thought of treating the packet space like a heap... blah. Anything that could break-though to faster communications between processes.

Main problem, the datatypes must be set in stone and there needs to be quite a bit of default stuff before it's useful. So, that's my main userland problem. Stuff like images, files and streams of either of these are pretty simple (image => something you can display, image stream => movie, file => thing that contains bytes, file stream => rar file, tar file etc.) but there are more complex things such as converting between files and N-channel sound, where I cannot determine N beforehand. Also, there need to be filters from type X to type X, such as echo effects on sound channels and blurring (sharpening, stretching etc) a movie in runtime.

I would love to know more.