• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 18 subscribers
  • Views 4489 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?
Parents
  • 0 Arm Employee Badge
    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).
Reply
  • 0 Arm Employee Badge
    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).
Children
No data