Den 2020-03-19 kl. 15:13, skrev Pekka Enberg:
On Thu, Mar 19, 2020 at 4:05 PM Pekka Enberg <penb...@scylladb.com> wrote:
Hi,
On Thu, Mar 19, 2020 at 3:30 PM Yuanqi Li <yuanqili1...@gmail.com> wrote:
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.
Yeah, I think this is an interesting direction! Merging the JVM and
the OS was one of the things we were looking to do with OSv, as you
can see from the JVM memory balloon feature.
It is not "the" JVM. It is "a" JVM named hotspot. And a terrible one at
that. :-)
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.
I don't remember if we ever built JVM from sources (I'm CC'ing Calle
for this), but it shouldn't be too hard to do.
(Really CC'ing Calle this time....)
We (OSv) did not. Up until jdk10 or so, building the JDK was massively
horrible. Now it is just prohibitively so. The ballooning was iirc just
some JNI coupled with native agent to create objects that could be
partially unmapped. I can't remember if we simply detected memory access
to determine if HS was trying to move it, or if Glauber tried using
JVMTI. The latter would have been potentially expensive...
The way it works in OSv is that you pass the "image" option to
"./scripts/build" to build an image with OSv and some applications:
https://github.com/cloudius-systems/osv#building-osv-kernel-and-creating-images
What you need to do is define a OSv "module" or "application" that
builds JVM from sources. You can find an example of Python being built
from sources here:
https://github.com/cloudius-systems/osv-apps/tree/master/python27-fromsource
Please note that OSv still consumes the applications as ELF
executables and shared libraries, and not combine them into one binary
like other unikernels like Mirage do.
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.
We wanted to run Linux executables out-of-the-box, but did not rule
out OSv-specific APIs. If you allow yourself to modify the JVM
sources, then there's really no problem in adding more OSv "system
calls" (they're really functions) to do what you need to do.
Hope this helps!
- Pekka
--
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 osv-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/51d5dbf7-3a9a-e2e9-199b-7a6386260208%40scylladb.com.
