Here is what I think is left to do (besides the changes in my last 3
patches):
1. Remove httpserver-jolokia-plugin, httpserver-jvm-plugin and josvsym
as dependencies from module java-base (old java module) and either make it
an implicit dependencies of httpserver ONLY if java dependency is selected
during build OR make those 3 modules be added explicitly as needed.
2. Move java/jni/monitor.cc, java/jni/monitor.hh and java/jvm/java.cc to
module java-base and add corresponding Makefile to java-base and possibly
java-isolated and java-non-isolated so that it only compiles needed version
of java.so. Also modify main Makefile not to compile these artifacts.
3. Move modules/java-base/cloudius (maven module that generates
cloudius.jar) and java/jni/* except for monitor.* to mgmt project. mgmt
project does not depend compile any C++ nor it has dependency on osv build
tree I think so moving C++ files from java/jni/ there might not be
trivial or desired.
- another option would be to move only modules/java-base/cloudius
maven project to mgmt and move C++ files from java/jni to
modules/java-base
instead of mgmt so at least it does not get compiled by main Makefile.
On Fri, Dec 9, 2016 at 8:40 AM, Waldek Kozaczuk <jwkozac...@gmail.com>
wrote:
> I have just sent another related patch and I have not gotten much feedback
> about my previous 2 ones. Am I going into wrong direction?
>
> Waldek
>
> PS> I am sorry if I sound I nag too much :-)
>
> On Wed, Dec 7, 2016 at 1:11 AM, Waldek Kozaczuk <jwkozac...@gmail.com>
> wrote:
>
>> 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 <n...@scylladb.com> wrote:
>>>
>>>>
>>>> On Sun, Sep 4, 2016 at 7:55 AM, Waldek Kozaczuk <jwkozac...@gmail.com>
>>>> 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 osv-dev+unsubscr...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "OSv Development" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/osv-dev/q932_pFkV9Q/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> osv-dev+unsubscr...@googlegroups.com.
>>
>> 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 osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
