Introduce memory handles and a supporting memory manager

[mterwoord]

Basically contains #97

[Geramy]

Can we get more description where to start maybe? On Jul 23, 2015 2:02 PM, "Matthijs ter Woord" notifications@github.com wrote:

Basically contains #97 https://github.com/CosmosOS/Cosmos/issues/97

— Reply to this email directly or view it on GitHub https://github.com/CosmosOS/Cosmos/issues/159#issuecomment-124239301.

[mterwoord]

Well, I'll be starting on it tomorrow.

Basiclaly, currently, when passing objects around, we're passing direct addresses around to the area in memory they are at. We want to use handles (ie, indirect references), so that a memory manager (garbage collector) can more easily shove things around.)

[Geramy]

In assembly generation? Or in the .net framework? On Jul 23, 2015 2:17 PM, "Matthijs ter Woord" notifications@github.com wrote:

Well, I'll be starting on it tomorrow.

Basiclaly, currently, when passing objects around, we're passing direct addresses around to the area in memory they are at. We want to use handles (ie, indirect references), so that a memory manager (garbage collector) can more easily shove things around.)

— Reply to this email directly or view it on GitHub https://github.com/CosmosOS/Cosmos/issues/159#issuecomment-124242885.

[mterwoord]

Cosmos.

[merarischroeder]

Having handles to objects sounds like an inefficient idea. Direct references should be fine. I recall that a Generational GC rewrites pointers while all threads are stopped. The GC walks the stack and connected graph via the direct references, does its thing, and if it moves objects it can update memory references before continuing threads.

Having such indirect references, will only move the problem to needing to update the pointers. Where are they stored? If they're in some sort of table (sequential memory area), when the related objects are collected, that table will also need be compacted.

I haven't found your current memory manager yet - it would seem there's only allocations and no deallocations, no memory management, not even refcounting.

I would love to help, I have a software development company and have started this: https://bitbucket.org/merarischroeder/dull/wiki/Home

My last planned step is actually some sort of GC/Memory implementation which favours realtime performance.

I suggest you refer to Java GC designs. There are many there to refer to, including Realtime ones. While working in this area, I see an opportunity to give this project a killer application. I have ambitions to make Cosmos as async as possible (perhaps with absolutely no thread support), and this could mean a novel async memory manager which performs cleanup duties as short tasks.

Just thinking out loud, I am very new to this project.

[czhower]

In a rush so let me try to post this quickly...

-Our first mem mgr is a ref impl. Designed for ease of coding and flexibility with reasonable perf. The mm is pluggable and we intend later to have a variety of options and a "run off" as well to determine which ones are best. Post this, they will still be pluggable and devs will be able to choose from more than one.

-Pointer remapping is expensive in both time it takes to execute and also the book keeping. PPC and Motorola chips required this but they only did it during load.

-The indirect ptr can be done quickly and the plan is that the lookup table will reside in the CPU cache. It needs tested but we believe it will be quite fast and overall our best initial design. In fact other cpu archs have single ops that can do this. Intel is a reg based system, but Cosmos is not tied to Intel and in the future we will support ARM etc.

-DULL - This is in fact one of my goals for Cosmos as well, so will be very interested in this project.

-RE Java etc. We are of course looking at existing designs, but Cosmos executes quite differently than existing systems and this gap will grow as we move towards our other plans. This allows us to do a LOT of things that other systems cannot in how we do things. Even calling methods in my initial tests we were able to be factors faster than C++ etc (note, this is not in Cosmos currently, its a test written in ASM that will be integrated at a later date into our compiler).

-Async and threads. We have a lot planned here but our async pattern is not intended to be the traditional async patterns. Traditional patterns are for the benefit of the CPU and not the dev and generally complicated the software side rather than simplify it. The closest thing I can describe to our existing plans shortly is "mobile agents" (see my article on CodeProject) and fibers. But in fact our fibers will be even lighterweight than Windows ones. We are experimenting with a system which does not rely on CPU context switches which on Intel are very expensive relatively speaking.

Intel design is an overly complex design which has to do with historical reasons. But without managed code or emulation, we are stuck with that design. Cosmos being able to manage everything opens up a lot of possibilities and lets us skip a lot of the Intel complexities and also gives us better portability to RISC based systems.

[merarischroeder]

Thanks for taking the time to respond.

1. Noted.
2. Noted. RE: "Expensive", I see your point. The pointers are peppered across the memory space. As I said, my requirement is toward real-time performance, so no arguments there.
3. RE: "Indirect". Yeah, I had a hunch that was possible when I saw that in the X# yesterday when writing my post. I have only had formal training in MIPS, and only limited understanding of x86.
4. Dull - Awesome, most of my challenge will be finding collaborators, so please pass it on. I'm building it to be portable. Usable with Cosmos, and also other platforms. (I have just noticed your Indy.Sockets association which I will look into).
5. Noted.
6. Re: "Async": Your Code Project article is comprehensive. I would think that "Mobile Agents" would sit atop Fibres, as "Mobile Agents" doesn't necessarily describe a task-switching kernal. Also with "Mobile Agents", I encourage you to compare with "Containers" and "Docker", as these are very close to realising your concept (although not client-side). Whatever the kernal concurrency implementation is, the C# async keyword is independent of that model. If anything, you may have a plug which implements threads as Fibres. I however would like to even avoid Fibres. In the context of a network server with short requests, async is enough. (I'm off to a meeting, so I'll stop the detail there)
7. Yes, it would be interesting to run Cosmos+Dull on Open Network hardware being developed by Open Compute (backed by Facebook).

[mterwoord]

1. We definitely expect to make up for the slowdown of the indirect dereferencing using other speed tricks (at some point). But also keep in mind, that the open hardware is likely going to be ARM based etc. Also, the pointers will be isolated in blocks containing thousands (or even more) of pointers in the same block, potentially grouped by execution group (thread/process/fiber/whatever) once we get there.
2. See 2.
3. So you have the same challenge as we do: finding collaborators. Maybe you could help us out a bit with the memory things?

If you want more direct interaction with us, we have a gitter room, where most of us try to hang out...

[merarischroeder]

1. Yeah, that makes sense, aiming to minimize cache-misses.
2. I'll probably focus on Dull, and then when we start coming up against missing features in Cosmos, will start to contribute where needed. I have advanced plans for running Hackathons locally. I would like weekly hackathons and half of the weeks would be to contribute to existing open source software. X. Ok, I'll look into joining the gitter room. I'm aboard the Slack bandwagon.

[mterwoord]

1. See you soon then! :) We're still missing networking, and memory management..

[merarischroeder]

RE: Async - this was lightly dismissed, and has been weighing on my mind. .Net Async overlays Windows IO completion ports, and it's very powerful. It turns messy IO Completion port programming into sequential async code.

In Dull I have already mapped in-bound packets (coming straight off the INT) through the stack and into an Async Stream. This will provide the same performance and API as .NET Network Async without the IO Compmletion Ports layer.

I strongly recommend you make Async support a priority and any threading model secondary. I understand a concept of threads is necessary for catering for INTs, and interrupts of interrupts. But then again, that could be a closed loop, with INTs only adding to a queue of tasks to complete.

[mterwoord]

Not sure we need Async in the traditional way: In Cosmos, we have control of the code, so when we detect an async call, we can do all kinds of magic..

[merarischroeder]

I should probably put this in another thread or other discussion area, but it would appear you don't fully understand Async. There are resources, but I'd rather you spent your valuable time coding, so I'll distill it down for you.

1. Async is for awaiting external resources such as Hard Disk and Network (in fact they may be THE only resources).
2. It makes awkward IO completion syntax (Call, Response delegate, IAsyncResult) simple. So simple that you can nest use of Async through complicated chains.
3. Async is effectively syntax Magic for anonymous delegates.
4. Yes, it also makes threading somewhat nicer, but that's secondary to the primary benefit of tidying up IO completion.
5. Being for Hard Disk and Network, it is there that Async calls are "terminated". When awaiting, the network will trigger a return value and thus calling the return delegate. I have got such code already (but untested) in Dull in the StackStream class.

Therefore, "so when we detect an async call, we can do all kinds of magic" is incorrect. The implementation must be in: Network Stack, Storage IO, and by extension layers above those, such as HTTP Stack etc. Also there must be some kernal support/understanding: Async can operating on a single thread and never need threading, except for what my previous posts alluded to: Interrupts, and the fact that a response to network request may take too long before the next request comes. So much more thinking/decisions to come.

[czhower]

FWIW I havent forgotten about this thread. Just been really sick the last month but am catching up.

On 8/30/2015 8:53 AM, merarischroeder wrote:

I should probably put this in another thread or other discussion area, but it would appear you don't fully understand Async. There are resources, but I'd rather you spent your valuable time coding, so I'll distill it down for you.

1.

Async is for awaiting external resources such as Hard Disk and
Network (in fact they may be THE only resources).

2.

It makes awkward IO completion syntax (Call, Response delegate,
IAsyncResult) simple. So simple that you can nest use of Async
through complicated chains.

3.

Async is effectively syntax Magic for anonymous delegates.

4.

Yes, it also makes threading somewhat nicer, but that's secondary to
the primary benefit of tidying up IO completion.

5.

Being for Hard Disk and Network, it is there that Async calls are
"terminated". When awaiting, the network will trigger a return value
and thus calling the return delegate. I have got such code already
(but untested) in Dull in the StackStream class.

Therefore, "so when we detect an async call, we can do all kinds of magic" is incorrect. The implementation must be in: Network Stack, Storage IO, and by extension layers above those, such as HTTP Stack etc. Also there must be some kernal support/understanding: Async can operating on a single thread and never need threading, except for what my previous posts alluded to: Interrupts, and the fact that a response to network request may take too long before the next request comes. So much more thinking/decisions to come.

— Reply to this email directly or view it on GitHub https://github.com/CosmosOS/Cosmos/issues/159#issuecomment-136132945.

[merarischroeder]

That's ok, I've just gotten busy so this has gone on the backburner. But I have found a talented coder who will be able to help me build the initial per-v1 versions. I just need to get to my v0.1 milestone first (this basically means completing the architecture), and then he can complete the implementation. I'm thinking this will take 2-3 months at least. I need to make sure my main line of business continues to grow, and then I will have extra funds to accelerate development.