Skip to main content

Java execution acceleration

12 replies [Last post]
hcucu
Offline
Joined: 2008-03-18
Points: 0

Hi,

I know that many have complained over the time that Java runs really slow on mobile devices (I also get bored sometimes to see the "Loading Java" message before I start to play games :P). I recently got into a project that aims to provide some kind of Java hardware acceleration. Do you think a hardware JVM could be a solution for the java execution slowness?

Our current tests show an encouraging speed increase, but I don't know if they are representative for the Java programs that run on mobile devices. Do you know where I can find some algorithmic benchmarks to test our prototype?

PS: if any of you is willing to see how the prototype works feel free to give me an e-mail.

Horia

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Hartti Suomela

What comes to HW acceleration, it needs the HW on the device.
That increases BOM, requires additional volume inside the device, needs
to be added in the designs really early, draws juice, etc.

Yes, SW solutions have issues as well, but I see an uphill battle for HW
acceleration in this case...

Hartti

-----Original Message-----
From: A mailing list for KVM discussion
[mailto:KVM-INTEREST@JAVA.SUN.COM] On Behalf Of ext
meinterest@MOBILEANDEMBEDDED.ORG
Sent: Wednesday, June 11, 2008 9:05 AM
To: KVM-INTEREST@JAVA.SUN.COM
Subject: Re: Java execution acceleration

Hi rriggs9000,

You're totally right! Maybe that's the main reason the previous Java
hardware accelerators failed (they focused only on optimizing individual
bytecodes).

I agree about the lack of flexibility of a hardware+software system, but
I don't see the need to modify the VM (GC, thread syncronization, etc)
very often. If a new system offers high execution speed (10x-20x) then
maybe it's a fair trade-off to change the software-hardware
interface(arhitecture) only on major revisions (every 12-24 months).

If such a case occurs the concept of arhitecture will be somehow moving
from the hardware-software interface (the IBM's ideea back in 60s) to
the VM-applications interface.

I'm not speaking about an Intel+Microsoft model where any change in the
hardware would imply changes in every application running on the
platform, but more like a phoneME + ARM (with Jazelle) where changes in
the Jazelle processor would imply some patches in the VM while all the
Java applications stay the same. That's the main advantage of
virtualization!

Regards,
Horia
[Message sent by forum member 'hcucu' (hcucu)]

http://forums.java.net/jive/thread.jspa?messageID=279737

========================================================================
===
To unsubscribe, send email to listserv@java.sun.com and include in the
body of the message "signoff KVM-INTEREST". For general help, send
email to listserv@java.sun.com and include in the body of the message
"help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

hcucu
Offline
Joined: 2008-03-18
Points: 0

Hartti,

We were thinking about integrating our hardware solution inside the SOC as an ARM co-processor so, in this case there will be no increase in the BOM, no additional volume inside the device, etc. In fact, for the mobile devices manufacturers there won't be any other differences (the SOC would have exactly the same pinout) besides the execution speed increase for all the Java applications obtained with a small increase of the SOC price (silicon area increase).

My guess is that the hardest battle will be given for a place in the SOC, but in that battle we expect support from the people that have a lot to win from this speed increase: mobile software developers (will write once, run anywhere), mobile devices manufacturers (will have better devices).

Regards,
Horia

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Sure, that's the method many ARM licensees choose with Jazelle. Many ARM-variants have Jazelle support - but, at least in the past, there was not only cost involved for the silicon but also for the Jazelle license. I don't know what the latest status on the Jazelle license cost is.

As I mentioned in my first answer, however, we have found the performance and memory benefits from using a technique such as a direct byte code accelerator marginal in most application scenarios. What we've also found is that there is a much higher payback in optimizing the VM software and stack as well as educating developers about designing applications for efficient execution.

Hardware acceleration is only a very small part of the overall equation. Topics like cost, features, design, integration are all much more important to most parts of the value chain than a minor performance increase for certain application corner cases.

-- Terrence

hcucu
Offline
Joined: 2008-03-18
Points: 0

Hi Terrence and all,

I submit to your opinion that the problem is very complex and I agree with you that additonals uphills may appear on the way. As for mobile software (and especially games) you're right too: they are all moving towards Java.

Software optimizations play an important role in this performance race, for now they actually work good enough and I'm sure that they will be needed by any hardware accelerator. All I am saying is we should raise the bar for both hardware and software in order to get even better performance.

I am also trying to find the best way to benchmark our solution in this complex environment and to find people who need and are interested in seeing better results.

Regards,
Horia

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Yes. Or to put it differently: The cost of hardware acceleration (hardware and addt'l software support) is non-null and non-negligible while the cost of software acceleration (a bit more dynamic memory) is becoming increasingly negligible. So if software acceleration is "good enough" (which it seems to be for most application scenarios on newer devices) hardware acceleration just doesn't seem very attractive.

-- Terrence

hcucu
Offline
Joined: 2008-03-18
Points: 0

Terrence,

If the software acceleration is "goog enough" how come most of the games I play on my mobile phone are written in C++ and compiled in native ARM code and not written in Java and compiled in bytecodes? From my knowledge the software development companies pay a huge price for porting their applications from one device to another, a price that would be negligible if the applications would be written in Java.

Regards,
Horia

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Ah, difficult question ;-)

I don't have hard numbers but I believe the majority of mobile games are actually written in Java. Sometimes it's hard to tell as they look like native apps - especially the built-in games. I've found performance on most of these satisfactory or even excellent. It depends a lot on how the game is designed, There a still quite a few mobile developers out there who just don't fully understand the limitations they are working under and make poor design choices.

Native games sometimes are necessary if you want to use platform features that aren't accessible through Java APIs ... this is probably the majority of cases why one would go native. No doubt, there *are* situations where just need to squeeze every ounce of performance out of the device and/or the Java stack is not optimized well and that's the reason you go native.

Porting is another story. Yes, fundamentally, moving Java apps from one platform to another should be easy - it depends a lot on the range of devices you target and the features your require your app to have. Best case is it just runs. Worst case is you have to modify a significant part of your app. There is just too much variation in the mobile space to have a "one-size-fits-all" approach - which, at the same time, is also a strenght.

Of course, porting from say, Symbian to Windows Mobile, is another story altogether ;-)

-- Terrence

Stephen Cheng

Software-based optimization works very well. Hotspot etc can makes use of
run-time context, and can perform some optimizations that cannot be easily
achieved by hardware or ahead-of-time optimization. On the other hand,
ahead-of-time software optimization can perform CPU-expensive optimizations
that could not be performed by Hotspot or hardware accelerometer. A high
quality optimizer that specialises in whole program optimization can
generate significant size reduction and/or performance boost. The three
techniques are complementary - however Terrance has a good point regarding
the economics. The economy of scale favours hotspot and ahead-of-time
software based optimization, unless you happen to be ARM :-)

Our alcheMo product family automates porting of J2ME applications/games to
native platforms. Our mBooster is the de-facto standard for J2ME app
optimization. They are both widely used, and therefore we are in a unique
position to be able to compare performance and other aspects with hard data.
Terrance is right - performance bottlenecks are typically not in bytecode
level. A good run-time library implementation or a better game/app design
are more likely to yield performance improvement, although without a doubt
native apps does generally run faster than J2ME apps. (I am not knocking
J2ME/JVM - any bytecode approach etc will have a performance penalty if
however slight in a typical mobile environment and there are significant
upsides to a bytecode approach too)

- Stephen

> -----Original Message-----
> From: A mailing list for KVM discussion [mailto:KVM-INTEREST@JAVA.SUN.COM]
> On Behalf Of meinterest@mobileandembedded.org
> Sent: Friday, 13 June 2008 8:33 p.m.
> To: KVM-INTEREST@JAVA.SUN.COM
> Subject: Re: Java execution acceleration
>
> Ah, difficult question ;-)
>
> I don't have hard numbers but I believe the majority of mobile games are
> actually written in Java. Sometimes it's hard to tell as they look like
> native apps - especially the built-in games. I've found performance on
> most of these satisfactory or even excellent. It depends a lot on how the
> game is designed, There a still quite a few mobile developers out there
> who just don't fully understand the limitations they are working under and
> make poor design choices.
>
> Native games sometimes are necessary if you want to use platform features
> that aren't accessible through Java APIs ... this is probably the majority
> of cases why one would go native. No doubt, there *are* situations where
> just need to squeeze every ounce of performance out of the device and/or
> the Java stack is not optimized well and that's the reason you go native.
>
> Porting is another story. Yes, fundamentally, moving Java apps from one
> platform to another should be easy - it depends a lot on the range of
> devices you target and the features your require your app to have. Best
> case is it just runs. Worst case is you have to modify a significant part
> of your app. There is just too much variation in the mobile space to have
> a "one-size-fits-all" approach - which, at the same time, is also a
> strenght.
>
> Of course, porting from say, Symbian to Windows Mobile, is another story
> altogether ;-)
>
> -- Terrence
> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=280120
>
> ==========================================================================
> =
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff KVM-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff KVM-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

hcucu,

Java hardware acceleration has been a long-time subject of investigations. In fact, I actually worked on Sun's picoJava hardware acceleration engine way back when. Also, phoneME has the hooks to support ARM's Jazelle technology.

However, I think the general experience has been that providing hardware acceleration is a loosing battle except for very specific and constrained applications. General purpose CPUs benefit from the rapid evolution of semiconductor technology and there is a lot of economy of scale for using the CPU for most, if not all, processing requirements in a system including Java execution - with the notable exception of graphics engines (this seems to be too demanding for even modern CPUs to support).

We have found over the years that Java hardware acceleration provides marginal and short-lived performance benefits in most real-world applications - although there are specific application scenarios in which it does provides tangible benefits.

As for benchmarks, we've been using www.grinderbench.org which is a well-designed benchmark covering many aspects of raw bytecode execution.

-- Terrence

hcucu
Offline
Joined: 2008-03-18
Points: 0

Hi Terrence,

Thanks for the hint on GrinderBench. It looks like it is exactly what we need to get started :). I guess we'll try to get a licence for the source code because our system is not CLDC-compliant yet, but it's a step forward anyway.

Concerning the hardware acceleration topic I tend to believe that Java will soon become the de facto standard in mobile software development, while the existing hardware doesn't satisfy its needs yet (phoneME has the hooks to support ARM's Jazelle, but in most of the cases it doesn't use them because the JIT version runs faster).

My point is that Java software development is already restricted by the execution speed and i guess none will say "no" to any kind of Java acceleration (whether it is JIT, AOT or hardware acceleration). The question is if the hardware acceleration is capable of giving better results or it has reached its peak.

Horia

rriggs9000
Offline
Joined: 2003-10-02
Points: 0

A broader range of optimizations is possible with JIT and HotSpot technologies than can
be achieved with hardware acceleration that focuses on optimizing evaluation of individual
bytecodes. Runtime optimization techniques can target optimizations to frequently used methods,
inline to avoid method calls, do subexpression
optimization/elimination, move common subexpressions out of loops, etc. just to name
a few simple ones. VM implementations are need flexibility in the representation of Objects,
flags and support for synchronization primitives to optimize performance and provide
alternatives in GC and synchronization. A combination of hardware and software could
have greater improvements but once a mechanism is embedded in hardware it ends up constraining
the possible VM design.

hcucu
Offline
Joined: 2008-03-18
Points: 0

Hi rriggs9000,

You're totally right! Maybe that's the main reason the previous Java hardware accelerators failed (they focused only on optimizing individual bytecodes).

I agree about the lack of flexibility of a hardware+software system, but I don't see the need to modify the VM (GC, thread syncronization, etc) very often. If a new system offers high execution speed (1000% - 2000%) then maybe it's a fair trade-off to change the software-hardware interface(arhitecture) only on major revisions (every 12-24 months).

If such a case occurs the concept of arhitecture will be somehow moving from the hardware-software interface (the IBM's ideea back in 60s) to the VM-applications interface.

I'm not speaking about an Intel+Microsoft model where any change in the hardware would imply changes in every application running on the platform, but more like a phoneME + ARM (with Jazelle) where changes in the Jazelle processor would imply some patches in the VM while all the Java applications stay the same. That's the main advantage of virtualization!

Regards,
Horia

Message was edited by: hcucu

Message was edited by: hcucu

10x -> 1000%
20x -> 2000%