Microkernel for JVM

[Qeroq]

Hello,
I'm currently trying to design a microkernel (currently only x86 32bit, but 64bit would be fun though later on) that is solely able to run a SINGLE Java Virtual Machine (my plan is to put an osgi container in this and implement drivers and such as bundles, so no tasks, but threads and everything running in ring zero). I know that is it difficult, but I'm willing to invest time and efford in that, because I would really like to see it working and besides I'm learning a lot of stuff from kernel dev I didn't know before, even if I could not finish this thing.

So, I'm just asking here for some advise, how you would, e.g., implement the memory manager for such a project, just to be sure I get it right, before wasting a lot of time. My plan is, just to identity map the whole available mem. Well not exactly identity mapping, just mapping around memory holes so it seems like there is a contiguous space of memory. Is there any kind of problem or issue attached with this? Other than that I'm not going to be able to use 4MB pages for addressing 64GB in 32 bit.

So actually, in this design I would have my kernel starting at 0x100000 (1MB) and ending a few megs after. From this space on, there will be the heap (and maybe some sort of stack, I'm currently figuring out how it works) for the jvm.

The libraries I think I would have to port to make a simple JVM implementation working (like JamVM, I guess) are (mainly) libc, libm and pthreads. The first ones (libc and libm) are covered by newlib, as far as I know. The last one I would have to implement on my self, right? So do you know any good tutorial for threading or even porting the POSIX threads?

Rgds Farok

Edit: Typo

[gerryg400]

Newlib contains a linux pthread implementation that you may be able to use as a guide. Look in the libc/sys/linux/linuxthreads directory. Generally speaking threads, mutexes etc. operate pretty close to the kernel so I'm not sure how portable any of it would be. I would guess 'not very'.

[Qeroq]

Hm, turns out, the stack is my greatest design problem now: Stack space needs to be continuous, but how do I allocate multiple (!) continuous spaces I don't know how large they'll grow. I could just restrict stacks in size, but there goes recursion unless I reserve several megs of mem for the stack of one thread or how much will actually suffice? A page, or two, or more?

I'm trying to find a good tutorial on threading and in the case I don't find one but another way to figure this thing out, I'll maybe write one myself to the wiki... I'll see...

[gerryg400]

It's not really a problem is it ? On 32 bit x86 you can have 1000 threads each with 1MB stack and only use 1/4 of the address space. To save physical memory you should probably only commit physical pages on demand. i.e. fault them in. That means leaving behind your original idea of mapping the entire of memory at the beginning.

[Qeroq]

But there's a problem connected with that: You can only have an address space from 0 to 4GB. Normally this isn't a problem, unless a task consumes more than 3GB or so considering you have the kernel mapped too. But this is single-process and there is only a single page directory which can map from 0-4GB. But you obviously need a point to begin with the stack. Lets say, we have the kernel and kernel data etc. in the lowest 16MB and from there, there is the heap. So where to put the stack? To 3GB mark? to 3,5GB mark? to 3,75GB?

Probably its wise to switch to long mode right at the beginning. As far as I remember, addresses in x86_64 can be much longer, increasing the size of the memory that can be addressed directly. Correct me if I'm wrong, but with this it should be possible to create the stack area somewhere in the end of the 64bit address space and page-fault in pages for the stack (maybe using 2 pages per stack) as well as pages for the heap, located in the lower regions of the memory.

Edit: Just read that long mode offers whole 64bit linear address space. Can this be interpreted as follows: With paging enabled, you have an address space up to 2^32 times bigger than 4GB, that is 16ZB? I'm clear about the fact, that there is nothing with that you can use this bunch of memory in the next years, but that's great, so the heap has virtually no limits to expand, and I can sacrifice 1 or 2GB of address space to stacks without having any bad conscience.

Edit: No, I must answer to myself, that's no true. A single task can use 48bit of address width, which results in 256TB of addressable memory. But that's still enough, I can totally live with that, so I'm going for 64bit only, which shouldn't be much of a problem nowadays I guess.