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

Robin,

I don't see this as a limitation of the M3G spec. It is purely a VM/JSR
integration issue. I don't think that it should be down to the app
developer to explicitly manage resources in this way; this is Java after
all :)

Having said that, all VMs I've seen do support (native) finalizers, and
this is typically how native resources are managed.

I do not pretend to understand why SE & Nokia M3G implementations behave
in the way you describe, especially as this is done on load(). I can
only guess that it is related to Image2Ds and texture memory as no
rendering is taking place.

In most M3G implementations GL calls would be handled by native code. If
the OpenGL driver decides it's run out of memory and you are deep in the
middle of a load, you could theoretically call gc() from the native side
and hope that some garbage collected objects release enough resources in
their finalizers to try again. In some cases gc() would have to be
called multiple times, so when do you stop? Also although initiating a
gc() from the native side is possible, it does not mean that the OEM
will permit it... So I can certainly sympathise if the M3G
implementation just gives up and throws OutOfMemory, although admittedly
it is not ideal.

Out of curiosity, does the behaviour go away if you explicitly call gc()
from your loop or is this an actual leak?

Mike
--
Dr. Michael K. Steliaros
Chief Engineer, Superscape Ltd
Terms and conditions for email usage: www.superscape.com/email/

> -----Original Message-----
> From: A mailing list for KVM discussion
[mailto:[email protected]]
> On Behalf Of Robin Chaddock
> Sent: 07 August 2007 10:31
> To: [email protected]
> Subject: 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".

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