Closed iefserge closed 9 years ago
I am of the opinion that we shouldn't rush towards a process model.
Isolates and contexts are what v8 provides, so runtime should expose both of those, but let the code decide how to use them. Sometimes I think code should be separated by isolates, but other times by context.
I have two related questions right now:
Yeah, this basically adds isolates support. I think I should stop calling JS applications processes.
how will you interrupt an isolate on a single CPU?
Using timer IRQ.
how will synchronization work on multiple-cpus?
We can run isolates in parallel on multiple cpus, they are like separate instances of VM.
Updated issue name and description.
Using timer IRQ.
Will there be a control isolate that gains control when the timer fires? I like the idea of being able to write the scheduler in JS space. A userland scheduler is a crazy (but awesome) concept.
How easy/safe is it to interrupt v8 arbitrarily and then resume it later?
We can run isolates in parallel on multiple cpus, they are like separate instances of VM.
I think my question was how do we provide synchronization when two isolates need to access the same data structure. These isolates may or may not reside on the same CPU, and may be interrupted because of the timer.
Using timer IRQ.
Will there be a control isolate that gains control when the timer fires? I like the idea of being able to write the scheduler in JS space. A userland scheduler is a crazy (but awesome) concept.
How easy/safe is it to interrupt v8 arbitrarily and then resume it later?
On Gaia I wrote a routine to listen on hardware interruptions in C and convert them to somewhat "events" in Python, and later dispatched functions registered on that function. Maybe we can have a dedicated isolate where to dispatch and manage that events...
We can run isolates in parallel on multiple cpus, they are like separate instances of VM.
I think my question was how do we provide synchronization when two isolates need to access the same data structure. These isolates may or may not reside on the same CPU, and may be interrupted because of the timer.
The best I can think is to have that data structure protected by a singleton and access it doing a request, so only the singleton can access to it.
Will there be a control isolate that gains control when the timer fires? I like the idea of being able to write the scheduler in JS space. A userland scheduler is a crazy (but awesome) concept.
No, I think scheduler in JS is too crazy :)
How easy/safe is it to interrupt v8 arbitrarily and then resume it later?
That's completely safe, isolates are designed to run in parallel. So we can pause one and resume another anytime.
I think my question was how do we provide synchronization when two isolates need to access the same data structure.
Runtime.js currently uses spinlocks for this.
I tried hacking on the kernel this week. I am close to the point where I understand what's going on, and can maybe help.
Speaking from an outside perspective, much of the source is very easy to follow. There are however a few hairy bits that I would love to help with. It looks like v8 requires lock and timer primitives to function, and I see that you've patched the v8 source. The locking is easy enough to follow, but the timer seems to delegate back to the Isolate
class via the GLOBAL_engines()
object.
I think the original idea was one isolate per cpu, but perhaps we should look at decoupling the Engine
object from Isolates in general.
I recognize you've probably thought about this a lot longer than I have, so if I'm missing something I would love to understand it better.
Sorry for the delay.
I think the original idea was one isolate per cpu, but perhaps we should look at decoupling the Engine object from Isolates in general.
Yea, check out this commit (24afac9dd28afaf0e29b6a3e093aa8bfa9f20c1b). Now it's v8 isolate per thread. Where thread is something that's possible to interrupt and preempt. And thread manager is per-cpu manager/scheduler.
Yea, check out this commit (24afac9). Now it's v8 isolate per thread. Where thread is something that's possible to interrupt and preempt. And thread manager is per-cpu manager/scheduler.
This is the definition of process... :-P
@iefserge how difficult would it be to drive this idea to completion, and separate v8 entirely from the micro-kernel layer?
I had a chat with @unixpickle on irc who has this project https://github.com/unixpickle/anarch which has the intention of running either v8 or the DartVM.
@groundwater, v8 is already separated from most of the low level services, but it's not a microkernel layer. Classic microkernels usually provide processes, address spaces, system calls etc.
The runtimejs idea is to optimize everything possible in a system so v8 can perform better, even if it means breaking some abstractions.
@unixpickle project looks interesting, but aren't they building true microkernel?
@iefserge my kernel design will provide scheduling (through an abstraction; you can change it easily), a dead-simple IPC mechanism, and a physical memory manager. However, a user-space (user-space is an abstraction, it could be kernel-space too) task will be responsible for handing out memory to other user-space tasks and will be able to page that memory to disk (so that all paging and most memory management as a whole is done by JavaScript or some other language running in a VM).
So, it is a microkernel in one sense, but it also places slightly more responsibility on user-space. My goal throughout has been to let you write as much of the OS in JavaScript (or Dart, Lua, etc.) as you want. That being said, I do not want to make the assumption that every language VM supports preemption or other OS responsibilities.
By the way, anarch is simply the hardware abstraction layer that I am currently working on. The actual kernel is called Alux.
So, it is a microkernel in one sense, but it also places slightly more responsibility on user-space. My goal throughout has been to let you write as much of the OS in JavaScript (or Dart, Lua, etc.) as you want. That being said, I do not want to make the assumption that every language VM supports preemption or other OS responsibilities.
That reminds me about the exokernel architecture, that I'm totally willing for. +1 to this :-)
http://wiki.osdev.org/Exokernel http://en.wikipedia.org/wiki/Exokernel
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
@unixpickle Runtimejs includes its own abstraction layer, but I think projects could collaborate and maybe even share some common parts.
Certainly they could share many common parts. Especially for the JavaScript layer: it would be cool if both projects could reach the same standard within JavaScript so that JS code written for one OS could work on the other one.
Isolates are temporary not supported to reduce project complexity.
After some research and experiments with contexts and isolates I think we should add isolates support for applications. This way we can put different programs into separate v8 isolates.
Pros:
v8::Unlocker
, but it's not supported by engine and often crashesCons:
I think this should solve many multicore/multitasking problems.