ARM interpreter

Uncategorized 1 Minute

I just discovered that the ARM-specific interpreter stuff that Ed Nevill wrote last year has a hack that disables it when run with -XX:+PrintCommandLineFlags. I guess this is one problem when you have 6,000 14,000 lines of assembler nobody understands: you don’t know what secret weird shit is buried in there.

Published by gbenson

I make things // he/him

Published

8 thoughts on “ARM interpreter”

  1. A little history on the optimized ARM interpreter:
    The optimized ARM interpreter was created starting in 2008 in order to speed up OpenJDK on ARM.
    http://blogs.arm.com/software-enablement/182-how-do-you-make-java-fast-answer-go-down-the-pub/
    http://blogs.arm.com/software-enablement/187-how-do-you-make-java-fast-answer-go-down-the-pub-part-2/

    The latest IcedTea6 version that contain it are IcedTea6 1.8.x.

    Some initial work to update the ARM ASM interpreter for later IcedTea6 and OpenJDK versions have been made:
    http://www.senecass.com/projects/OpenJDK-ARM/
    http://labb.zafena.se/arm-asm-patches/

    If you want to help updating the ARM ASM interpreter to work in combination with the latest Zero and Shark Hotspot then feel free to join the #OpenJDK IRC channel on the OFTC IRC network irc://irc.oftc.net:6667.

    Cheers
    Xerxes

  2. What is the current status of the ARM ASM interpreter and Shark JIT for ARM? I’ve read all the links that Xerces posted, so I think I understand the background of the interpreter, but I can’t find which repository it’s in.

    Is there a stable way to cross-compile OpenJDK for ARM, with or without the optimized interpreter or Shark?

    I’ve tried to follow these instructions for OpenEmbedded:
    http://icedtea.classpath.org/wiki/CrossCompileFaq
    However, it dies after an hour or so trying to overwrite my system-wide glibc headers (e.g. /usr/include/limits.h).

    Debugging the OE build seems daunting, with it’s 3000+ steps that try to download and rebuild the world. This document implies that it’s possible to build manually, but has TODOs for all the meaty parts:
    https://evolvis.org/plugins/mediawiki/wiki/jalimo/index.php/CrossCompilingOpenJDK

    Despite what that page says, cross-compiling the LLVM trunk (pre-2.9) for ARM JIT turned out to be pretty easy. Does that get me anywhere near an OpenJDK+Shark build for ARM?

    Thanks for any guidance,
    Trevor

  3. Now that Microsoft is making an ARM port of Windows 8 and NVidia is planning a desktop and server line of ARM CPUs, what are the plans for official ARM support in [Open]JDK?

    If Hotspot gets a C1 and C2 for ARM, there’s not much point in using Zero/Shark.

  4. Trevor:
    The Shark JIT are inside the the main OpenJDK repository and you can easily build it by using IcedTea6!
    hg clone http://icedtea.classpath.org/hg/release/icedtea6-1.10
    cd icedtea6-1.10
    ./autogen.sh
    ./configure –enable-shark
    make

    I have updated the CrossCompileFaq today to use the latest available tools.
    The org.openembedded.dev branch changes rapidly, the glibc header issue that you experience are most likely a new bug that got introduced recently when someone are working on updating glibc in the the org.openembedded.dev git tree. Try update the tree and restart the build.

    IcedTea and OpenJDK still cant cross compile out of the box. We have plans in the Jalimo project to upstream the patches and know-how from OpenEmbedded into IcedTea, but it takes time to turn quick hacks into nice solutions.
    see: http://elinux.org/images/4/40/Cross-compiling_OpenJDK.pdf

    For a proof of concept of what you get when combining Zero, the fast ARM ASM interpreter addon
    with the Shark LLVM JIT then feel free to check out this about a year old Shark on ARM build:
    http://labb.zafena.se/shark-testing/armv5/7may2010/

    As mentioned in the 7may2010/readme.txt you have to apply a workaround for IcedTea PR399 against the LLVM codebase (2.9 as well) to make the LLVM JIT run stable on ARM. For more background information of this bug see:
    http://llvm.org/bugs/show_bug.cgi?id=5201
    The LLVM people are currently doing a total redesign of the LLVM JIT so in the future this bug might go away by itself when the new FOO-JIT/MC-JIT are ready. see:
    http://markmail.org/message/ugsotgzqc57tc3vq#query:+page:1+mid:dlqtqwmx3yarljqj+state:results

    Damjan:
    Oracle are currently selling a proprietary ARM C1 and C2 Hotspot but they do not show any signs for what i know to release under GPL and push it out into OpenJDK.

    While the work of updating the ARM ASM port are hard, I found it quite easy and quick to polish the current CACAO and JamVM projects to run fast on ARM in combination with OpenJDK. Also Pure Zero and Shark without the ASM ARM interpreter addon runs very stable on ARM.

  7. Damjan asked about “plans for official ARM support in [Open]JDK”. Since Xerxes (tusen tack!) provided extensive information on the state of the various ARM backend combinations for OpenJDK, it fell to me to provide a pointer to information about the non-F/OSS rest… :)

    Dalibor Topic, Java F/OSS Ambassador, Java Products Group, Oracle

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.