• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 19 subscribers
  • Views 4035 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

I really don't want to write a JIT/AOT myself

Odin Zeno
Note: This was originally posted on 11th August 2010 at http://forums.arm.com

It seems that I have to raise the chip performance through this way, and I was acknowledged of Ubuntu recently got some from arm.
I don't want to spent time uselessly at writing the samething again(wasting your time or mine). But can that JIT/AOT work on a chip with less than 20 KB ram? Is there anyone know the detail? Some article said it boosts speed to 14X, is that true?
  • 0
    Note: This was originally posted on 12th August 2010 at http://forums.arm.com

    > But can that JIT/AOT work on a chip with less than 20 KB ram?


    Well it really depends doesn't it =)

    What are you jitting from, what do you want to JIT in to, how much code are you jitting, what kind of optimization are you after?

    How much support code does the language need?

    Can you do a 100% JIT, or will you have to fallback on an interpreter in some cases? [it is rare for a JIT to JIT everything]

    In all honestly 20KB of RAM is not much if you have a "typical JIT" - assuming you can load the bytecode from Flash, then you need space for: output JIT'ted code, the JIT itself, any interpreter support, two stacks (one for JIT/interperter and one for code), and then any data your program is actually using.

    If you can restrict the bytecode to something simple (relatively flat mapping to the hardware ISA), and have a design with a very limited support library then it could be done. This type of micro-bytecode has found use in some boot-strap type code in many devices (BIOS chipsets often run a bytecode). Assuming you want to JIT something like full Java, then probably not possible in 20K, but then I've never really tried either.
  • 0
    Note: This was originally posted on 13th August 2010 at http://forums.arm.com

    I see.
    I just want to measure the difficulty in making such a thing from none, besides, I'm not going to implement a full JIT/AOT.
    I also forgot to tell you that I'm working with a smart card but not some other HUGE mobile devices ---- I didnot expect to have a good result, but this worths a try.
  • 0
    Note: This was originally posted on 13th August 2010 at http://forums.arm.com

    In all honestly 20KB of RAM is not much if you have a "typical JIT" - assuming you can load the bytecode from Flash, then you need space for: output JIT'ted code, the JIT itself, any interpreter support, two stacks (one for JIT/interperter and one for code), and then any data your program is actually using.

    If you can restrict the bytecode to something simple (relatively flat mapping to the hardware ISA), and have a design with a very limited support library then it could be done. This type of micro-bytecode has found use in some boot-strap type code in many devices (BIOS chipsets often run a bytecode). Assuming you want to JIT something like full Java, then probably not possible in 20K, but then I've never really tried either.

    To be honest, It's harder to have a big ram than to have a big flash, isn't it?
    So taken in the trade off, we'd perfer some kind of mixed up codes, for better performance and for less money to spend.
    Even if we cannot really implement a fully functional AOT embeded, we could try to make something generate C code on PC. To understand this, I must tell you about some thing in our company...

    Our engineers provided the key system for our products in java form, so my group was focusing on the performance issues and some other things platform related. And, after several tests, we draw the conclusion ---- a native system could be faster. My leader choosed to hand-rewrite the system, while I choosed to make a AOT/JIT.

    That's the case. Isogen74, my working condition may limit the ram size to lower than 10 KB, how about that? :-)
  • 0
    Note: This was originally posted on 16th August 2010 at http://forums.arm.com

    To be honest, It's harder to have a big ram than to have a big flash, isn't it?


    From a cost point of view, yes, but that doesn't help avoid the fact that JITs tend to need a lot of RAM. I believe that most smartcards tend to stick to interpreters - in this case all of the code (interpreter itself, and the bytecode) can be stored in flash - so the lack of RAM is less critical.

    If you JIT from a byte code into ARM instructions you often increase the code size substantially:


    •     Simple 1 byte bytecode with implicit stack operands -> 4 byte ARM instruction with explicit register assigned operands.
    •     Complex "new" bytecode -> function call in to a library routine with any stack and branch instructions needed to achieve that.

    You need to write this native code somewhere. If you are JITing a few KB of code then OK, but if you JIT more than that you are going to run out of space in your RAM pool, OR you need to write it back in to Flash using AOT (flash writes are slow so you probably wouldn't want this in your JIT path).

    You idea of converting to native code offline is not a bad one. There are some tools which have tried this (GCJ, the GCC Java compiler (ARM support in v 4.3.0, but supports full Java running on top of Linux for library support, and ARM support is relatively recent, so not sure how stable it is).
  • 0
    Note: This was originally posted on 1st September 2010 at http://forums.arm.com

    It's an option. I'll try it.
  • 0
    Note: This was originally posted on 26th October 2010 at http://forums.arm.com

    Hello! Just want to drop by and say hello!