Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ELI5 connection between kernel and JVM? #2

Open
rusefillc opened this issue Mar 12, 2021 · 3 comments
Open

ELI5 connection between kernel and JVM? #2

rusefillc opened this issue Mar 12, 2021 · 3 comments

Comments

@rusefillc
Copy link

how coupled is the kernel part of this project with the JVM part of this project?

Please forgive me if I am completely missing the point of what this project is.

I am looking for a self-contained micro JVM implementation with minimal OS coupling - i.e. more or less malloc and free, and some basic IO interface whatever we consider to be the most basic IO interface.

in the end I am looking for a bare minimum GC implementation with bytecode execution I guess?

@seancfoley
Copy link
Owner

The coupling between kernel and JVM is small. It doesn't need to run as a kernel, it also runs in Windows.

The project was intended to be something that could be used in an embedded environment to run Java. So you could write Java code and run it on a device. This was before Android existed.

The kernel part is small. It can compiled to run as a kernel, or it can run as Windows application as well, for development and debugging primarily. So it has a ps (platform-specific) module that is one or the other. In there is one source file for basic I/O, one for initializing the Java heap with malloc, and one for some time functions. Also in the x86 port is some code to do basic threading, ie basic context-switching and sleeping and so on to support Java threads, some asm code to boot up, and a but more platform-specific stuff to support what is needed for Java CLDC bytecodes (such as timers). The windows version uses green threads. CLDC is an older but obsolete Java platform.

A lot of the rest is Java bytecode execution, garbage collection, etc, all of which is not platform-specific, the platform specific stuff was kept to a minimum. It does Java memory allocation from the one heap and has garbage collection.

So yes, this is indeed a "bare minimum GC implementation with bytecode execution".

As I said, the bytecode execution is for an earlier version of Java (cannot remember, maybe 5 or 6), so a bit of updating would be required for more recent Java bytecode, but not a huge amount of work since bytecode has not changed a lot.

@rusefillc
Copy link
Author

I am very interested :)

rusEFI is an embedded device (gasoline combustion engine control unit), we use stm32 MCUs under ChibiOS

https://forum.chibios.org/ is an amazing real time OS for embedded with an astonishing Hardware Abstraction Layer library. What's cool is that one can run chibios on Windows or unix see https://github.com/ChibiOS/ChibiOS/tree/master/demos/various/RT-Win32-Simulator https://github.com/ChibiOS/ChibiOS/tree/master/demos/various/RT-Posix-Simulator

I would love for user to paste .class files for custom strategies and our ECU to run that logic on the MCU

In my professional life I've touched the bytecode so 5 vs 6 vs 8 vs 11 does not bother me at all. worst case I am happy to help with migration from 5 to 8 if any migration would even be needed.

Any chance you would be interested to get your JVM running under ChibiOS on Windows? "running under ChibiOS on Windows" would really mean "running under ChibiOS" which would than directly translate into "running on stm32"

@seancfoley
Copy link
Owner

I've looked over your project sites, and your autoweek article, and I see what you are doing with your ECU - very interesting and ambitious. I will take a look at those links, I don't know much about chibios. At this time I'm spending my time on other projects but I will give this some thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants