see as well:


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.


User stories



You can have subsections that better describe specific parts of the issue.


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.



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 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
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:
DaCapo benchmark suite may be better reflect majority of real world server uses than numerical benc
initial DaCapo benchmark results (real world applications) 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
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:
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++:


FoundationsTeam/Specs/JvmOnARM (last edited 2011-06-15 13:27:06 by doko)