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

Remove java wrapper altogether or mostly #1169

Open
wkozaczuk opened this issue Jul 13, 2021 · 3 comments
Open

Remove java wrapper altogether or mostly #1169

wkozaczuk opened this issue Jul 13, 2021 · 3 comments

Comments

@wkozaczuk
Copy link
Collaborator

This is the next and controversial step after we address #1168. For a long time, we have been able to run unmodified java from a host including bin/java regardless if it is a PIE or position dependant executable. Given that, the only reason to have OSv specific java wrapper (see modules/java-base/java.cc and modules/java-base/runjava-*) after we address #1168, is to support java ballooning once we fix it :-) (see #1038). Well, the other tiny issue is that we have to add ! to force terminating lingering Java threads.

I believe we can eliminate all java code ( modules/java-base/runjava-*) and either delete java.cc AND use alternative mechanism to pass -Xmx to java OR change java.cc to be a tiny front-end app that would calculate the value of -Xmx and launch native bin/java with -Xmx. Currently, the java.cc parses all arguments and calls JNI_CreateJavaVM directly, which creates many problems for modern Java as many arguments have changed since Java 7/8 or become obsolete. More "pass-through" tiny wrapper would better work.

The only complication is that the ballon C++ code relies on OSv java code - modules/java-base/runjava-common/src/main/java/io/osv/OSvGCMonitor.java (see https://github.com/cloudius-systems/osv/blob/master/modules/java-base/balloon/jvm_balloon.cc#L417-L443). But maybe that would not be a big deal, as OSvGCMonitor.java seems to be a standalone Java code that does not depend on other run-java java code.

Finally doing this would help us close many java-wrapper-related issues - java-wrapper .

@nyh
Copy link
Contributor

nyh commented Jul 15, 2021

I agree that if the Java executable works, we should use that (or a small executable which runs it) and not the shared library. I agree that since the balloon code is not in a working situation, and nobody wants to work on it, we don't need to worry about it. Moreover, I think that even if we run the unmodified Java executable, and in the future we'll want to return the ballooning stuff, there is probably/hopefully still a way to do this from another thread, using JNI.

@kmahapatra530
Copy link

Hi, my name is Koshik and I am a student at UT Austin. I'd like to work on this issue as part of my virtualization class assignment.

@wkozaczuk
Copy link
Collaborator Author

Hi, @kmahapatra530.

Welcome to the OSv community! You are very welcome to work on this issue. Please bear in mind it depends on #1168.

Solving this one and #1168 will require solid knowledge of Java and Python and makefile. I do not think we want to delete all relevant code but mostly disable it where necessary.

I would suggest you study this issue and #1168 and Java-related modules and come up with a more detailed strategy. I can help you with then.

BTW reading this 5-years old comment might help as well - #953 (comment).

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

No branches or pull requests

3 participants