##(see the SpecSpec for an explanation) * '''Launchpad Entry''': UbuntuSpec:foundations-o-java-on-arm * '''Created''': 2011-05-12 * '''Contributors''': * '''Packages affected''': openjdk-7 see as well: https://wiki.linaro.org/OfficeofCTO/OptimizedJavaVM == Summary == == Release Note == This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. == Rationale == == User stories == == Assumptions == == Design == You can have subsections that better describe specific parts of the issue. == Implementation == This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: === UI Changes === Should cover changes required to the UI, or specific UI that is required to implement this === Code Changes === Code changes should include an overview of what needs to change, and in some cases even the specific details. === Migration === Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. == Test/Demo Plan == It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. This need not be added or completed until the specification is nearing beta. == Unresolved issues == This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. == BoF agenda and discussion == {{{ http://openjdk.gudinna.com/benchmarks/ Currently a different setup on ARM than the rest of platforms We have an older OpenJDK for ARM as the new ones don't work HotSpot not available on ARM We use the Zero-VM which is an interpreter and is unacceptably slow but for which ARM did some optimization of Zero 2 years ago 16K lines of handoptimized ARM asm in Zero Alternatives to HotSpot - Cacao and JamVM - not feature complete Shark - LLVM based JIT for JVM Plan to target OpenJDK7 for at least the other archs for Ubuntu 12.04 ARM implementation is not a one time effort, but needs to follow HotSpot development closely Some benchmark results: http://openjdk.gudinna.com/benchmarks/ DaCapo benchmark suite may be better reflect majority of real world server uses than numerical benc hmarks initial DaCapo benchmark results (real world applications) http://jamvm.sourceforge.net/ at the end of the page. Implementations were tested on SMP platforms as well In general, all implementations aren't as stable; for instance, some will run into NPEs when runnin g certain benchmarks The GC used is also particularly important; for instance some implementations use the Boehm GC whic h can cause some memory fragmentation OpenJDK MIPS port; added MIPS flavors to the hotspot code; not merged yet (on its own branch); not sure how fast it is. Based on earlier UltraViolet port, added a JIT to it. First appeared about a year ago. The Zero based implementations have superior startup: warmup time is much shorter than with pure JI Ts. HotSpot internals keeps being changed by Oracle all the time. LLVM + Shark is a higher risk as there are two moving targets. When Ubuntu switches to OpenJDK 7, the workarounds wont be available anymore. The openjdk builtin testsuite takes some 4 hours to run on x86 during package build (with JIT); on ARM, it's been running for 6 days and counting (no JIT). Does JamVM run with OpenJDK 7? - needs porting; some interfaces were removed like HPI, but that doesn't affect JamVM, but new byte codes were added and need to be supported Cacao worked on OpenJDK7 at some point, but doesn't work anymore, and JamVM does everything that Ca cao does, so is likely to work with some porting Eclipse debugger wont work unless JVMTI support is implemented Need to run automated tests more frequently; Jython benchmarks are good to discover bytecode interp reter crashes Lusearch and Tomcat benchmarks also good torture tests Cacao isn't maintained anymore Can still use old HotSpot with newer classes, but only within OpenJDK 6 builds Proper solution would be either a proper port of HotSpot like the MIPS guys are doing; MIPS people probably spent at least some 4 man-years on it, and it's not up-to-date and we don't know how well it performs Is JamVM stable over longer term workloads? - some have been running for weeks Possible improvements for JamVM would be C code calls improvement or bytecode level optimizations like moving non-loop-dependent code out of loops etc. [ACTION] For correspondance use Ubuntu Server and IRC channel [ACTION] Identify a workingplan to implement the Best long-term proposal - Develop a server JIT ARM backend that can slot into hotspot and be merged upstream. - Need formal job proposal for this with money on the table (students/community do not have experience/expertise. Anybody who has the expertise will already have a job working on compilers/JIT, and they won't be interested in promises of payment or short-term contracts). list of requirements - get better or equal performance than the current oracle prop ARM J2SE - pay close attention to SMP - next generation of Cortex-A15 contains LPAE and have access to 40bit memoryspace - armv7 - restriction used by the 11.10 release - soft support in the kernel [ACTION] find someone who can estimate how much work it takes to implement a proper server jit. rough esimation: ??? Q: do we know who to contract to make this estimation? X86 port contains 86941 lines of code Switching from current default of ARM interp/T2 JIT to JavmVM or Cacao will lose functionality more notes below... Big debate about when to switch default. info below... Test jamvm before switching to have confidence it will work info below... Switch now and see what problems occur, and fix them, revert if a blocker appears info below.. [ACTION] implement JVMTI debugging interface in JamVM for OpenJDK6+7 [ACTION] implement JSR232 new invoke dynamic bytecodes in JamVM for OpenJDK7 [ACTION] start testing using JamVM as default Testing of jamvm as default: make a build with jamvm as default run the built in tests of the build run known applications that we want to run on this jamvm. test Tomcat. Hadoop are a excellent choice for testing. [ACTION] if tests are positive then switch to use JamVM as default in about 3weeks conditions for stop button: - if it breaks the build in a way thats nontrivial to fix +1w fix then its probably a non starter. - jvm should not crash on pure java code. - regressions in jtegtests (ok list below) "ok" build failures - build expects different jvm -version output and stops the build - jvmti tests. What platform should we start on: pandaboard Arm server image packages? use the java X86 java packages as the base for testing. build packages, if so then make the switch before debian import freeze date. Debian import freeze date: [todo] Consern are that most multiarch packages do not get build by the arm builder. [doko] can we turn on building all packages on arm? if sbuild package knows whats its building then we could abuse it into doing it, it would not be pretty but it can be done. If necessary use Zero as the fallback option. Start now using JamVM as default in PPA Can we make the PPA build arrn packages? There are a sanity check that will prevent building on arm. To be done for 11.10 release: [ACTION] choose a OpenJDK ARM port maintainer - register a ARM port in OpenJDK part of the OpenJDK porters group To be done for 12.04: To be done for 12.04++: }}} ---- CategorySpec