Based on my further investigation java/cloudius produces a cloudius.jar
that is uses by https://github.com/cloudius-systems/mgmt project (per
module.py). Also all java/jni/*.cc files except monitor.cc (used by
balloning) is only used to implement native method in java/cloudius
classes.
Ideally both java/cloudius folder and most java/jni/*.cc should also be
moved to mgmt project. On other hand java/jni/monitor.* and
java/jvm/java.cc can be moved to modules/java-base.
Remaining java/jvm/* should stay where they are as they are necessary to
link with core OSv image.
Does it seam reasonable?
Waldek
PS. BTW do my latest patches I sent look correct to you - ([PATCH2] Moved java
files from ./java folder to new modules/java-base and modules/java-tests]
and [PATCH2] Added openjdk8-zulu-compact3-with-java-beans app and modified
jdk apps to remove any duplication] ?
On Monday, November 28, 2016 at 7:28:08 AM UTC-5, Waldek Kozaczuk wrote:
>
> Hi,
>
> I just submitted 2 patches that are addressing moving java stuff from
> java/ to modules/java-*. There is still some work to do as far as moving
> jolokia-agent and cloudius modules from java-base and however I am not sure
> what is the role of each module listed below (apart from jolokia) to know
> if it is optional or essential and what it really is:
>
> cat modules/java-base/module.py
> from osv.modules import api
>
> api.require('fonts')
> api.require('ca-certificates')
> api.require('libz')
> api.require('josvsym')
> api.require('httpserver-jolokia-plugin')
> api.require('httpserver-jvm-plugin')
>
> Also locally I have tried to remove all java c++ stuff from Makefile and
> move it to modules/java-. However after I adjusted these 3 cc files
> (core/mempool.cc, core/mmu.cc, libc/mman.cc) to point to the new location
> of modules/java-base/jvm/jvm_balloon.hh I came across the linker errors:
>
> Building into build/release.x64
> GEN gen/include/osv/version.h
> LINK loader.elf
> build/release.x64/bsd/porting/mmu.o: In function `vm_throttling_needed':
> /home/wkozaczuk/projects/osv/bsd/porting/mmu.cc:41: undefined reference to
> `memory::throttling_needed()'
> build/release.x64/core/mmu.o: In function
> `mmu::jvm_balloon_vma::fault(unsigned long, exception_frame*)':
> /home/wkozaczuk/projects/osv/core/mmu.cc:1555: undefined reference to
> `jvm_balloon_fault(std::shared_ptr<balloon>, exception_frame*,
> mmu::jvm_balloon_vma*)'
> build/release.x64/core/mempool.o: In function `memory::on_alloc(unsigned
> long)':
> /home/wkozaczuk/projects/osv/core/mempool.cc:445: undefined reference to
> `memory::jvm_balloon_adjust_memory(unsigned long)'
> build/release.x64/core/mempool.o: In function
> `memory::reclaimer::_do_reclaim()':
> /home/wkozaczuk/projects/osv/core/mempool.cc:1031: undefined reference to
> `jvm_balloon_voluntary_return()'
> /home/wkozaczuk/projects/osv/core/mempool.cc:1011: undefined reference to
> `memory::throttling_needed()'
> build/release.x64/libc/mman.o: In function `mmap':
> /home/wkozaczuk/projects/osv/libc/mman.cc:145: undefined reference to
> `memory::return_jvm_heap(unsigned long)'
> Makefile:1796: recipe for target 'build/release.x64/loader.elf' failed
> make: *** [build/release.x64/loader.elf] Error 1
>
> It seems to be that building loader.elf relies on stuff in
> java/jvm/jvm_balloon.o, java/jvm/java_api.o and java/jvm/jni_helpers.o.
> Based on my very shallow understanding of what is going on it seems that
> JVM ballooning logic is pretty entangled with the core of OSv memory
> management logic. How easy is it to untangle that and make it somehow more
> pluggable?
>
> It seems that moving compilation of java.cc to modules/java-base should be
> easy but apart from that the rest does not seem trivial.
>
> Any further advice?
>
> Waldek
>
>
> On Tue, Sep 20, 2016 at 8:43 AM, Nadav Har'El <[email protected]> wrote:
>
>>
>> On Sun, Sep 4, 2016 at 7:55 AM, Waldek Kozaczuk <[email protected]>
>> wrote:
>>
>>> I believe at some point somebody started reorganizing java folder
>>> content to move it to modules/java and modules/java-tests but it was never
>>> completed.
>>>
>>
>> Indeed. The comment in commit df0fd92cc3a713f11874af369eb5f54c560d8b1f
>> and "TODO" in Makefile make this intention clear.
>>
>>
>>>
>>> I am willing to finish this process but I would like a little bit of
>>> guidance as far as:
>>> - possible major challenges to such restructuring (somebody stated that
>>> changing Makefile might be most challenging)
>>> - elimination of possible dead code (for example so called ballooning
>>> was disabled in java.cc and there seems to be a lot of relevant C++ and
>>> Java code to support it)
>>> - what to avoid
>>> - general guidelines
>>>
>>
>> One thing we need to do is to move the java-targets, java, jdk, etc.,
>> stuff out of the main Makefile and into modules/java/Makefile.
>> The challenge here is to get the right compilation line with the OSv
>> headers. You can take examples from other modules like modules/tests, which
>> also uses OSv headers.
>>
>> Second thing it would be nice to figure out is if we can get rid of the
>> "jdkbase" setting in Makefile and build/script. For example, perhaps the
>> "java" module can set up a link in its own directory, and the modules
>> requiring the java module can just use that link.
>>
>> After both changes, grepping for "java" or "jdk" should come up empty.
>>
>> Finally it would be nice to move the remaining stuff in java/ to
>> modules/java.
>>
>> Commit d9a7eba6e3f0a92074b579c0c181663e6c1d5e46 also points out that the
>> modules/java/Makefile currently runs "maven" to compile a lot of Java code
>> which isn't actually needed by all Java applications but just with some
>> specific modules (e.g., jolokia-agent); We could move some of this
>> compilation to the modules that needed them. I was always too afraid of
>> Maven to actually go ahead and do this :-)
>>
>> Finally, please do not remove the Balloon stuff. I just added a
>> bug-tracker issue that one day we need to bring it back - it was a nice
>> feature, and unique to OSv (and we even explained it in the OSv paper). So
>> I'd like to continue compiling it, even if it is currently disabled.
>>
>> Thanks,
>> Nadav.
>>
>>
>>
>>>
>>> Any thoughts?
>>>
>>> --
>>> 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].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
--
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].
For more options, visit https://groups.google.com/d/optout.
