One more thing: OSv provides pretty sophisticated tracing, profiling and debugging tools - if you want to start playing with it more:
- https://github.com/cloudius-systems/osv/wiki/Debugging-OSv - https://github.com/cloudius-systems/osv/wiki/Trace-analysis-using-trace.py Waldek On Thursday, March 19, 2020 at 12:55:47 PM UTC-4, Waldek Kozaczuk wrote: > > Hi, > > On Thursday, March 19, 2020 at 9:30:30 AM UTC-4, Yuanqi Li wrote: >> >> Hi all, >> >> We are a system research group from UCLA focusing on managed runtimes. We >> have some experience in kernel/JVM codesign. In our last project we >> modified Linux kernel to expose virtual memory subsystem to JVM to improve >> its GC performance under resource disaggregated datacenters. It will be >> subimitted to OSDI this year. >> >> Recently we've been looking for new directions. One of the ideas is to >> merge JVM and kernel together, so that kernel can expose more system >> information (e.g., memory usage and layout, scheduling, network stack) to >> JVM. Some potential benefits may include better Java application >> performance, better GC performance, faster bootstrapping time, etc. The >> main target will be serverless functions (e.g., AWS Lambda) where most >> tasks are short lived function invocations. A slow start of JVM is >> prohibitive. An insight is that both the guest OS and JVM are virtual >> machines essentially, a lot of language and security checks in JVM may be >> redundant given that the guest OS is already well isolated. Memory >> allocation and reclaim may also work better since OS can see semantic >> information of memory pages. So our first try will be making JVM and kernel >> share the same memory management subsystem. >> >> For the new project, I am doing preliminary experiments to collect >> performance numbers and estimate potential benefits of the design. OSv is a >> very interesting and promising kernel that we'd like to dig more. Its boot >> time is blazing fast with Firecracker. I also saw from the original ATC >> paper and source code that it has a JVM ballooning mechanism. But I didn't >> see how it could work with unmodified JVM. In addition, if I want to >> compile both OSv and OpenJDK together from source into a single bootable >> image, is there any solutions or resources? I didn't see such documentation >> in OSv's github wiki. >> > > OSv supports both modified and unmodified JVM. Originally OSv required > special Java wrapper - OSv "friendly" version of bin/java - to boostrap > JVM. You can find more info about running Linux executables including JVM > in this wiki - > https://github.com/cloudius-systems/osv/wiki/Running-unmodified-Linux-executables-on-OSv > and > https://github.com/cloudius-systems/osv/wiki/OSv-Linux-ABI-Compatibility#executable-formats. > > We have many apps/modules examples as well - > https://github.com/cloudius-systems/osv/tree/master/modules/openjdk8-from-host > , https://github.com/cloudius-systems/osv-apps#osv-applications, all > openjdk* apps like > https://github.com/cloudius-systems/osv-apps/tree/master/openjdk-zulu-9-and-above > > As far as ballooning feature goes unfortunately it is broken at this > point, please see - https://github.com/cloudius-systems/osv/issues/1038 > and https://github.com/cloudius-systems/osv/issues/398. Please note that > ballooning requires java-wrapper as it relies on JNI integration. You also > need to uncomment some code - > https://github.com/cloudius-systems/osv/blob/master/modules/java-base/java.cc#L175-L188. > > Besides fixing ballooning it would be also nice to have it integrate with > JVM with mechanisms like JVMTI instead of JNI which I think would not > require java wrapper but an agent code instead. > > >> I know that OSv is designed to support arbitrary unmodifed Linux >> binaries. So our idea diverges from OSv's goal. But given the popularity of >> FaaS and microservices, a dedicated bootable JVM worths a try. Or we may >> later find some low-intrusive disign that doesn't conflict with OSv's goal. >> > I do no think your idea diverges from OSv goal. It is just OSv comes with > a dynamic linker which I think is a way more flexible mechanism than > compiling and linking both app and kernel into single executable. They > still share same memory space and system calls are replaced with local > function calls. > > For even faster startup have you looked into GraalVM native image - OSv > supports it as well - please see > https://github.com/cloudius-systems/osv-apps/tree/master/graalvm-example and > other graalvm-* examples? > >> >> I know that academic projects often sound unrealistic and not get >> concerned by open source communities and industrial level projects. But I'd >> like to hear your opionions and ideas in this design. >> > Lastly one thing that should help with faster JVM startup would be > speeding up loading JVM binaries from disk. For that we have been working > on virtio-fs DAX feature (please see https://virtio-fs.gitlab.io/) that > allows direct virtual memory mapping of files between OSv and Linux host. > >> >> Thanks, >> Yuanqi >> >> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/8127a04e-3a8b-4260-a75b-907900fc2862%40googlegroups.com.
