Wow you are a fast-paced coder indeed. I guess you have a hot keyboard
Please take your time, and stick to your plan, which is already beyond my expectation.
Yes I acknowlege that threading support from OS-level is not a mandatory requirement for JVM, however I prefer to have one, and delegate the hard work to it
Some of the benifits are:
- It will make non-VM but supportive facilities like debugging a lot easier to implement
- Fewer work to do to port JVM to different platforms (yes i AM lazy)
- Applications can choose among different scheduling algorithms (preemptive, round robin, cooperative ..), without JVM invoved. Chances are most OSes can provide one or more of them, despite Prizm OS doesn't?
Surely the bottom line is we can always implement threading ourselves, directly in the fetch-decode-execution procedure, and base any further requirements of threading on that. Why not GC with a JAVA thread, just like we need not to create eggs ourselves if we have created chicken?
Looks like Yatis've done the CPU related hard work. I hate (or lack a brave heart) to read the datasheet, study the asm instructions and calling conventions of a new processor.. However higher level facilities such as synchronization locks are hardware neutral thus more feasible for me -- at least we already have FreeRTOS out there!
I will definitely do it on the shoulder of gint -- if I will ever finish it, I hope so.. -- either with your near future release or the (Yatis's + FreeRTOS) combination. This is my thought for now.
Once again, take your time!! You needn't do it for me! In the meantime gint API & CMake will keep me busy for quite awhile I'm afaid.
Cheers!