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

Robin,

I've had the following from Tomi Aarnio the M3G spec lead at Nokia that
I've been asked to pass on:

"I can confirm that there is indeed a VM integration issue in S60 3rd
edition devices that causes memory leaks when using M3G. S40 and the
more recent versions of S60 (i.e. from 3rd Ed Feature Pack 1 onwards)
are not affected."

Mike
--
Dr. Michael K. Steliaros
Chief Engineer, Superscape Ltd
Web: www.superscape.com
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 Michael Steliaros
> Sent: 07 August 2007 19:57
> To: [email protected]
> Subject: 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".

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