Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?

> Which additional resources could benefit from explicit cleanup methods?

Every jsr184 class that could perceivably have finite native resources
associated with it. (such as accelerated graphics memory)

Now the number of handsets with hardware acceleration support is increasing
I am curious how manufacturers are addressing this innate limitation of the
jsr184 api.

For example:-

[code]
while(true) {
   Loader.load("any.m3g");
}[/code]

Will cause a whole host of recent Nokia and SonyEricsson handsets to crash
with an OutOfMemoryError (though the heap is far from full), after a
relatively small number of iterations.
It doesn't appear to be memory leaks within the Loader class either,
replacing the use of the native m3g Loader with a java implementation (that
falls back upon api calls) does not circumvent the crashes on most
handsets - implying that programatic construction of jsr184 objects also
leaks some kind of finite system resource.

Given that Nokia was the Specification lead for jsr184, it is a little
disheartening to find most of their implementations are fundamentally broken
in such a way.

----- Original Message -----
From: "Joe Bowbeer" <[email protected]>
To: <[email protected]>
Sent: Tuesday, August 07, 2007 2:46 AM
Subject: Re: CLDC1.1+Jsr184+HW acc+reliable=impossible?


> On 8/3/07, Robin Chaddock <[email protected]> wrote:
>> I'm curious how the jsr184 api is designed to support underlying hardware
>> acceleration when built upon the cldc1.1 platform.
>>
>> a) CLDC implementations are not required to provide finalizer support; so
>> the platform cannot guarantee garbage collection of Java objects will
>> trigger the release of their native resources)
>> b) Very few of the Java classes (infact only Graphics3D?) have provision
>> for
>> explicit dispose()/destroy()/release() methods.
>>
>> These 2 limitations when coupled together make me think that providing a
>> reliable implementation of the jsr184 api when built upon a platform that
>> supports only the minimal feature set for CLDC1.1 compatibility is
>> fundamentally impossible.
>>
>> Obviously if the CLDC implementation went beyond it's needed minimum
>> specs,
>> such as offering an under-the-hood means of performing object
>> finalization,
>> or made the garbage collector aware of native graphics resources - then
>> implementing a hardware accelerated jsr184 api would not be so difficult.
>>
>> This observation appears to approximate reality, as a vast number of
>> handsets that 'support' jsr184 do so in very hap-hazard way - typically
>> leaking native resources from every proverbial orifice. (Nokias tend to
>> be
>> the primarily culprits, but SE and other manufacturers have their fair
>> share
>> of broken implementations too)
>>
>
> Java's finalize method has been much maligned in Java SE so I find it
> curious that you're advocating it for Java ME.  I view finalize as a
> last ditch cleanup hook that should be avoided in practice (by
> explicit cleanup).
>
> Which additional resources could benefit from explicit cleanup methods?
>
> MIDlets have a few finalize-like notifications already, such as
> Canvas.hideNotify(), MIDlet.pauseApp() and MIDlet.destroyApp().
>
> Is it possible for the cleanup methods to hook into one of these?
>
> If so, freeing the HW-acc resources on hideNotify and reacquiring them
> on showNotify is the most conservative approach.
>
> --
> Joe Bowbeer
>
> ===========================================================================
> To unsubscribe, send email to [email protected] and include in the
> body
> of the message "signoff KVM-INTEREST".  For general help, send email to
> [email protected] 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 [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".