Skip to main content

Possible to make emulator faster?

6 replies [Last post]
captainfreedom
Offline
Joined: 2007-01-10
Points: 0

I was think now that sun made the wtk opensource would it be possible to make the emulator startup faster? At the moment it takes about 11sec from pressing the start button to the time the the game is loaded in the emulator.
11 sec may not seem a long time, but when you consider that it's normal to do it a few hundert times in the coarse of debugging your app that's quite a lot of time wasted.
I'm not sure how it works exactly, but there seems to be a hard-coded wait time for the KVM connection which seems to be highly inefficient.
Considering MPowerPlayer only takes 1 second to startup, so it must be fairly easy to improve.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
terrencebarr
Offline
Joined: 2004-03-04
Points: 0

Robin, correct, the setup instructions are here

https://meapplicationdevelopers.dev.java.net/how_to_run.html

Let me know if you run into problem. I haven't used Eclipse in a while but you should be able to automate the starting of phoneME from Eclipse.

About debugging:

I haven't used the WTK debugger lately so I can't comment. The debugging support in phoneME Feature *is* pretty complete and I know our engineering team spent a fair bit of time on it. I didn't use the phoneME debug support very extensively but it did work as expected for me, including evalation of static fields. I did notice that execution slows down significantly when in debug mode, probably because a lot of the normal optimizations must be undone by the VM in order to support full debugging capabilities.

I encourage you to try it out. If you find bugs we should file them and they will get fixed.

Code base and Java SE:

The phoneME code base may be large but only parts of it are used depending on the configuration of the stack and the platform. And remember, it includes many MSA features which are outside and beyond the scope of Java SE.

As for footprint and why not use Java SE in the first place? There is no easy answer. When Java on mobile devices became possible it was only because the Java VM and stack was pruned down dramatically to make it fit into the 64 K segments of a Palm Pilot (the first Java ME device). And still today, the vast majority of mobile phones are too whimpy for Java SE. phoneME Feature runs fine in 2 MB heap including most of the MSA APIs. Last I remember Java SE wouldn't run in anything less than 32 MB.

Also, keep in mind that security and UI model are very different between Java SE and the MIDP stack because mobile devices with limited screens and used by consumers have very different requirements and straight Java SE in many cases is not a good fit.

That said, will the world be moving to Java SE on mobile devices? Most likely, as devices become more powerful this is a natural evolution. Just like, say Windows 3.1 and Vista evolved over time as PCs became more powerful. But especially in developing countries like India and China the number of low-end to mid-range phones is still huge for years to come. Those devices are well-served by phoneME Feature.

I'm not sure I undestand your last question about emulating a ME VM stack. It is a very common development paradigm in the embedded world that your development platform != deployment platform. Therefore, having an emulation of your deployment platform makes development easier and quicker. By using phoneME which is the same basic code base for Windows and for embedded platforms you have the advantage of developing and deploying onto the same basic code base thereby minimizing surprises.

-- Terrence

If there are bugs then we should file them

Robin Chaddock

>From an application development point of view, all I care about is accurate
emulation of the various APIs sat ontop of the VM, rather than the entire VM
from the ground up.

However I can see how this desire is rather short-sighted, when the J2SE and
J2ME VMs have significantly different behaviour with regard to core
functionality such as how OutOfMemory and StackOverflow errors are handled.

I suppose what I am actually after is a J2ME simulator, rather than
emulator - that is based ontop of a J2SE vm.
Such a capability opens up many new avenues. (such as Applet based demo'ing,
and integration with many other SE tools)

Projects already exist that offer some of this behaviour, the most
significant I have come across is ME4SE.
However, I have raised issues regarding limitations of ME4SE, and have yet
to hear of a viable solution to them.
The primary concern is that J2SE is not a strict super-set of CLDC, for
instance, CLDC completely ommits some methods that are declared final in
J2SE. (which could lead to a valid CLDC based app. being unable to load into
a J2SE classloader.)

----- Original Message -----
From:
To:
Sent: Thursday, June 14, 2007 12:35 PM
Subject: Re: Possible to make emulator faster?

> Robin, correct, the setup instructions are here
>
> https://meapplicationdevelopers.dev.java.net/how_to_run.html
>
> Let me know if you run into problem. I haven't used Eclipse in a while but
> you should be able to automate the starting of phoneME from Eclipse.
>
> About debugging:
>
> I haven't used the WTK debugger lately so I can't comment. The debugging
> support in phoneME Feature *is* pretty complete and I know our
> engineering team spent a fair bit of time on it. I didn't use the phoneME
> debug support very extensively but it did work as expected for me,
> including evalation of static fields. I did notice that execution slows
> down significantly when in debug mode, probably because a lot of the
> normal optimizations must be undone by the VM in order to support full
> debugging capabilities.
>
> I encourage you to try it out. If you find bugs we should file them and
> they will get fixed.
>
> Code base and Java SE:
>
> The phoneME code base may be large but only parts of it are used depending
> on the configuration of the stack and the platform. And remember, it
> includes many MSA features which are outside and beyond the scope of Java
> SE.
>
> As for footprint and why not use Java SE in the first place? There is no
> easy answer. When Java on mobile devices became possible it was only
> because the Java VM and stack was pruned down dramatically to make it fit
> into the 64 K segments of a Palm Pilot (the first Java ME device). And
> still today, the vast majority of mobile phones are too whimpy for Java
> SE. phoneME Feature runs fine in 2 MB heap including most of the MSA APIs.
> Last I remember Java SE wouldn't run in anything less than 32 MB.
>
> Also, keep in mind that security and UI model are very different between
> Java SE and the MIDP stack because mobile devices with limited screens and
> used by consumers have very different requirements and straight Java SE in
> many cases is not a good fit.
>
> That said, will the world be moving to Java SE on mobile devices? Most
> likely, as devices become more powerful this is a natural evolution. Just
> like, say Windows 3.1 and Vista evolved over time as PCs became more
> powerful. But especially in developing countries like India and China the
> number of low-end to mid-range phones is still huge for years to come.
> Those devices are well-served by phoneME Feature.
>
> I'm not sure I undestand your last question about emulating a ME VM stack.
> It is a very common development paradigm in the embedded world that your
> development platform != deployment platform. Therefore, having an
> emulation of your deployment platform makes development easier and
> quicker. By using phoneME which is the same basic code base for Windows
> and for embedded platforms you have the advantage of developing and
> deploying onto the same basic code base thereby minimizing surprises.
>
> -- Terrence
>
> If there are bugs then we should file them
> [Message sent by forum member 'terrencebarr' (terrencebarr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=222106
>
> ===========================================================================
> 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".
>

________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

===========================================================================
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

Sorry for the slow reply. Actually, WTK is *not* open source and there are currently no plans to do so. WTK is a toolkit which includes a Java ME emulation. What Sun open sourced are the actual Java ME device implementations (the CDC and CLDC stacks) as project phoneME.

If you're concerned about start-up time of your Java ME implementation during development I can recommend you use phoneME rather than WTK. On Windows it starts up approx. 3 to 5 times faster than the WTK emulator (that is, in a few seconds). Try it by checking out

https://meapplicationdevelopers.dev.java.net/how_to_run.html

-- Terrence

captainfreedom
Offline
Joined: 2007-01-10
Points: 0

Thanks for the answer Terrence.
Unfortunately I use eclipse, but I did try phoneme from the dos prompt. My midlet would not run at all and it's a very awkward process to start up a midlet. I assume this is because it's still in beta. Hopefully, it will improve in the furure.

Robin Chaddock

There is a guide on the site explaining how to set it up in netbeans (in leu
of UEI support), the steps are likely almost identical to setting it up in
EclipseME.

One thing I'm interested to know (and havn't had time to check myself), is
the debugger support in phoneME any better than the WTK?

Does it support hot code replace?
Conditional break points with more than a the trivial "return
variable==integer literal", and that don't take 100+ms for each evaluation!!
Can static fields be watched/inspected without throwing an
UnsupportedOperationException being thrown.
The list continues... WTK debugger support is rubbish.

If it isn't any better, how easy would it be to fix it?
Looking at the vast codebase for the phoneME project, all I end up asking
myself is - why on earth didn't they simply build it to run ontop of a J2SE
VM....
Does anyone realy find the emulation of the ME VM stack a valuable feature?
Was it worth the sacrifice of them duplicating huge chunks of the VMs native
code (and consequently introducing 100s of bugs into the WTK that don't
exist in J2SE) ?

----- Original Message -----
From:
To:
Sent: Thursday, June 14, 2007 11:45 AM
Subject: Re: Possible to make emulator faster?

> Thanks for the answer Terrence.
> Unfortunately I use eclipse, but I did try phoneme from the dos prompt. My
> midlet would not run at all and it's a very awkward process to start up a
> midlet. I assume this is because it's still in beta. Hopefully, it will
> improve in the furure.
> [Message sent by forum member 'captainfreedom' (captainfreedom)]
>
> http://forums.java.net/jive/thread.jspa?messageID=222095
>
> ===========================================================================
> 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".
>

________________________________________________________________________
E-mail is an informal method of communication and may be subject to data corruption, interception and unauthorised amendment for which I-play, a trading name of Digital Bridges Ltd will accept no liability. Therefore, it will normally be inappropriate to rely on information contained on e-mail without obtaining written confirmation.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

(C) 2005. I-play is a trademark and trading name of Digital Bridges Limited. All Rights Reserved.
________________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

===========================================================================
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".

captainfreedom
Offline
Joined: 2007-01-10
Points: 0

> There is a guide on the site explaining how to set it up in netbeans (in leu
> of UEI support), the steps are likely almost identical to setting it up in
> EclipseME.
Most of those settings don't exist in eclipseme, so I don't think it's possible.