On Thu, Mar 19, 2020 at 3:30 PM Yuanqi Li <[email protected]> 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.
>
>
Pekka gave you a few pointers. We have a bunch of Java versions already set
up to be built into OSv, e.g.,
scripts/build image=scripts/build modules=openjdk-zulu-9-and-above
Builds the OSv kernel, downloads the latest Azul JVM (binary), and builds
an image with the two of them.
The definition of this "openjdk-zulu-9-and-above" module is in
apps/opendjk-zulu-9-and-above/, and is slightly
complicated by the fact we have modules for a dozen different Java versions
and setup so there's a whole hierarchy
of them. You can find much simpler "modules" (instructions how to build
files to put in the Osv image) in apps/
> 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 agree. Historically, running the JVM was our primary goal for OSv, even
though technically it could run any Linux binary.
Three years ago I wrote this blog post on why I think OSv is a good match
for FaaS: http://blog.osv.io/blog/2017/06/12/serverless-computing-with-OSv/
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.
>
I don't think there's anything unrealistic about what you're trying to do,
but you should come with the right expectations.
One thing you shouldn't expect to happen is that OSv will give your
applications significantly better steady-state performance. We hoped this
would be the case, and in the paper we were able to demonstrate some
improvements, but these weren't huge improvements (e.g., 20%) and always
required heavy optimization sessions to find unoptimized parts remaining in
OSv and optimizing.
But you're right that startup time can be significantly better with OSv.
But this won't help with JVM startup time - for that you'll need to modify
the JVM itself. I'm not at all sure if OSv's single-address-space and
zero-overhead-system-calls will really be relevant or helpful for these
modifications, though. But definitely modifying the small OSv should be
easier than modifying the huge and fast-moving Linux.
>
> 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/CANEVyjvgntCVSOf3aQnDxTWu_KnO8TZ7xTceBqJ8F5H8Xbs68A%40mail.gmail.com.
