ARM Java Porting ..help!!

Smiley 4321 ssmile03 at gmail.com
Sat Sep 15 19:44:26 PDT 2012


All,

Let me express my appreciation to the excellent group OpenJDK what we have
and support provided to it's members.

I am looking for some clue/documentation for Java Runtime (JRE) support for
custom RISC/ARM based 32-bit (typical Load/Store architecture with INT,
Single FP and double FP) and Linux (-v2.4), Memory configurable processor.

To start with, simply I wish to know -

   - What are the things to be done to setup a Java Development environment
      for this processor?
      - This would include ...
      - Host Side:


   - A JDK environment, Editors, Java compiler (generating Bytecode),
         Debuggers, ...etc.


   - Device Side:


   - A JRE which includes JVM, Java libraries, ...etc.


What are the major items that need to be done ...

   - Example, using existing Eclipse tools for development (IDE, ...etc.)
   - Determining which Java version we will support
   - Which existing JVM implementation one should use? Or should one be
   implemented from scratch?
   - What parts of that JVM are C++ code which will work without any change
   (just would need re-compilation)?
   - What parts of the JVM are native code, which will have to be
   implemented for the ARM Processor?
   - Boot Image – Will this be needed to boot ARM based JVM?
   - Optimized ARM Java Compiler tool-chain – These ARM JVM tool-chain that
   generates optimized machine code from byte code through -
   (a) Supporting JVM backend to ARM board
   (b) Supporting Integer, Floating-point and Thumb instructions sets with
   test suites.
   (c) Optimizing Memory Management Unit (MMU) and Garbage Collector (GC)
   as whole performance of Anurag JVM would depend on this two critical
   parameters.
   (d) Supporting Java Multi-threading and POSIX capabilities
   (e) Application Binary Interface (ABI)
   (f) Porting and executing parallel based algorithms
   (g) Power saving – Using trade-off between Thumb code and ARM code.
   - Porting interfaces for the GUI alternatives - To meet product
   requirements for speed and cost/resource constraints. In some cases, to
   provide GUI interoperability that would allow AWT based applications to
   cooperate with native applications.
   - Profiling – To profile explicitly both from application (hotspots,
   etc.) and system (pipeline, events, cache, branch mis-predictions, context
   threading, etc) end.
   - Benchmark (Dhrystone, SpecJVM2008, etc)


I know I have asked tons of questions but would really appreciate a
direction to KICK START. I have a x64 bit machine with Ubuntu-12.04 loaded
on it.

Looking forward.

----- Thanks!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20120916/cf687bd8/attachment.html 


More information about the distro-pkg-dev mailing list