Re: [android-developers] Re: Do we need to call System.gc() ?

[Mitesh Infocus]

http://www.infocuswebdesigning.com/

On Tue, Aug 17, 2010 at 9:23 AM, Bob Kerns  wrote:

> I recommend reading Effective C++ -- and then avoiding C++ entirely.
> You get the best of both worlds that way. :=)
>
> (As an experienced C++ programmer, I claim that if you advocate C++ as
> a primary programing language -- you don't know C++ as well as you
> think you do! But if you're going to use it at all, you'd better know
> it well. Myer's book is a good start.)
>
> Such cleanup-verifier finalizers are relatively harmless -- but the
> same result can be had using weak references, with the distinct
> advantage of doing the reporting in a more controlled time and
> environment.
>
> On Aug 16, 4:05 pm, fadden  wrote:
> > On Aug 11, 10:03 am, Indicator Veritatis  wrote:
> > FWIW, _Effective Java_ was written by Josh Bloch.  Myers wrote
> > _Effective C++_.  (I highly recommend both.)
> >
> > > Of course, it doesn't help that even those of us who should know
> > > better confuse the Java notion of 'finalizer' with the C++ notion of
> > > 'destructor'. They are not as close as they may seem; finalizers are
> > > only very occasionally useful since, as you point out, there is no way
> > > to be sure they are even called.
> >
> > They're useful when the primary content is, "assert(cleanup is done)".
> >
> > Some changes to the GC and the way Bitmaps work will appear in a
> > future Android release.  The best thing you can do right now is use
> > Bitmap.recycle() if you have knowledge of your Bitmap life span, since
> > that discards the pixel data buffer without needing to go through the
> > garbage collection mechanism at all.  (It still has to do the
> > finalizer dance, but the small native structs associated with every
> > Bitmap aren't counted against the VM heap limit.)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[Bob Kerns]

I recommend reading Effective C++ -- and then avoiding C++ entirely.
You get the best of both worlds that way. :=)

(As an experienced C++ programmer, I claim that if you advocate C++ as
a primary programing language -- you don't know C++ as well as you
think you do! But if you're going to use it at all, you'd better know
it well. Myer's book is a good start.)

Such cleanup-verifier finalizers are relatively harmless -- but the
same result can be had using weak references, with the distinct
advantage of doing the reporting in a more controlled time and
environment.

On Aug 16, 4:05 pm, fadden  wrote:
> On Aug 11, 10:03 am, Indicator Veritatis  wrote:
> FWIW, _Effective Java_ was written by Josh Bloch.  Myers wrote
> _Effective C++_.  (I highly recommend both.)
>
> > Of course, it doesn't help that even those of us who should know
> > better confuse the Java notion of 'finalizer' with the C++ notion of
> > 'destructor'. They are not as close as they may seem; finalizers are
> > only very occasionally useful since, as you point out, there is no way
> > to be sure they are even called.
>
> They're useful when the primary content is, "assert(cleanup is done)".
>
> Some changes to the GC and the way Bitmaps work will appear in a
> future Android release.  The best thing you can do right now is use
> Bitmap.recycle() if you have knowledge of your Bitmap life span, since
> that discards the pixel data buffer without needing to go through the
> garbage collection mechanism at all.  (It still has to do the
> finalizer dance, but the small native structs associated with every
> Bitmap aren't counted against the VM heap limit.)

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] Re: Do we need to call System.gc() ?

[Lloyd Mc Farlane]

fadden  wrote:

>On Aug 11, 10:03 am, Indicator Veritatis  wrote:
>> Indeed: there seems to be a consensus among certain very experienced
>> Java users, including Scott Myers ("Effective Java") and Bruce Eckel
>> ("Thinking in Java"). That consensus is that there are three
>> conspicuous mistakes in the design of Java: thread groups, classpath
>> and finalizers.
>
>FWIW, _Effective Java_ was written by Josh Bloch.  Myers wrote
>_Effective C++_.  (I highly recommend both.)
>
>> Of course, it doesn't help that even those of us who should know
>> better confuse the Java notion of 'finalizer' with the C++ notion of
>> 'destructor'. They are not as close as they may seem; finalizers are
>> only very occasionally useful since, as you point out, there is no way
>> to be sure they are even called.
>
>They're useful when the primary content is, "assert(cleanup is done)".
>
>
>Some changes to the GC and the way Bitmaps work will appear in a
>future Android release.  The best thing you can do right now is use
>Bitmap.recycle() if you have knowledge of your Bitmap life span, since
>that discards the pixel data buffer without needing to go through the
>garbage collection mechanism at all.  (It still has to do the
>finalizer dance, but the small native structs associated with every
>Bitmap aren't counted against the VM heap limit.)
>
>-- 
>You received this message because you are subscribed to the Google
>Groups "Android Developers" group.
>To post to this group, send email to android-developers@googlegroups.com
>To unsubscribe from this group, send email to
>android-developers+unsubscr...@googlegroups.com
>For more options, visit this group at
>http://groups.google.com/group/android-developers?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[fadden]

On Aug 11, 10:03 am, Indicator Veritatis  wrote:
> Indeed: there seems to be a consensus among certain very experienced
> Java users, including Scott Myers ("Effective Java") and Bruce Eckel
> ("Thinking in Java"). That consensus is that there are three
> conspicuous mistakes in the design of Java: thread groups, classpath
> and finalizers.

FWIW, _Effective Java_ was written by Josh Bloch.  Myers wrote
_Effective C++_.  (I highly recommend both.)

> Of course, it doesn't help that even those of us who should know
> better confuse the Java notion of 'finalizer' with the C++ notion of
> 'destructor'. They are not as close as they may seem; finalizers are
> only very occasionally useful since, as you point out, there is no way
> to be sure they are even called.

They're useful when the primary content is, "assert(cleanup is done)".


Some changes to the GC and the way Bitmaps work will appear in a
future Android release.  The best thing you can do right now is use
Bitmap.recycle() if you have knowledge of your Bitmap life span, since
that discards the pixel data buffer without needing to go through the
garbage collection mechanism at all.  (It still has to do the
finalizer dance, but the small native structs associated with every
Bitmap aren't counted against the VM heap limit.)

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[Indicator Veritatis]

Indeed: there seems to be a consensus among certain very experienced
Java users, including Scott Myers ("Effective Java") and Bruce Eckel
("Thinking in Java"). That consensus is that there are three
conspicuous mistakes in the design of Java: thread groups, classpath
and finalizers.

Of course, it doesn't help that even those of us who should know
better confuse the Java notion of 'finalizer' with the C++ notion of
'destructor'. They are not as close as they may seem; finalizers are
only very occasionally useful since, as you point out, there is no way
to be sure they are even called.

Now I am not sure this "image data management" was ever described in
enough detail for me to be sure the following is appropriate, but
there was a very good Google Android blog post on managing a cache for
images using "weak references".

It is 
http://android-developers.blogspot.com/2010/07/multithreading-for-performance.html,
though you might not guess it from the name;)

On Aug 11, 6:13 am, DanH  wrote:
> Of course, finalizers have been all but deprecated on "big" Java.  Too
> unreliable -- not guaranteed to run.  If the image data management
> scheme relies on finalizers it's broken by design.
>
> On Aug 10, 11:54 pm, Bob Kerns  wrote:> This has been discussed 
> a fair bit in the past, if you want to try to
> > look for more details, but the basic issue is that there's a cascade
> > effect...
>
> > (This was a couple releases ago; it's possible it has been improved
> > since).
>
> > You call System.gc(). Some finalizers run. This enables other stuff to
> > be GC'd in the next pass, which allows the bitmap data to be
> > collected.
>
> > Aside from looping forever until there's enough memory, or detecting
> > somehow that no changes have been made to the object graph, there's
> > really no way for a GC implementation to guarantee that one invocation
> > has actually achieved the absolute best-possible result, when
> > finalizers are involved.
>
> > This could be better -- but extreme low memory is not what most GCs
> > are optimized for, so a bit of manual help isn't all that abusive, in
> > my opinion. The NEED for the manual help is certainly unfortunate,
> > however, so I hope they do manage to improve the situation.
>
> > On Aug 10, 9:19 pm, DanH  wrote:
>
> > > It's kind of abusing the concept.  There should be a separate way to
> > > clean up the image data (and it seems to me it should be self-
> > > policing, vs having to manually do this).  But more obscene things
> > > have been done in many phones, certainly.
>
> > > On Aug 10, 5:16 pm, Streets Of Boston  wrote:
>
> > > > I agree with you, but since the dalvik-vm does not 'see' the raw
> > > > binary image data in Bitmaps, it may not kick of the garbage collector
> > > > when process memory gets low. Calling System.gc() explicitly does work-
> > > > around this problem and it seems to work, in my experience.
>
> > > > On Aug 10, 4:43 pm, DanH  wrote:
>
> > > > > I'll add that if you need to call System.gc to prevent an error then
> > > > > there's a bug in the JVM.  (Not saying that there's no bug and hence
> > > > > no need to call it, just saying that, per the Java spec, the system
> > > > > should automatically do a GC before raising any "hard" out-of-heap
> > > > > error.  The observations by the others above is presumably an
> > > > > Androidism, not proper Java behavior.)
>
> > > > > On Aug 10, 3:28 pm, TreKing  wrote:
>
> > > > > > On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  
> > > > > > wrote:
> > > > > > > I think calling System.gc() doesn't immediately trigger the
> > > > > > > garbage collection. So, relying on this all the time might not be 
> > > > > > > a good
> > > > > > > idea.
>
> > > > > >http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> > > > > > 
> > > > > > "When control returns from the method call, the Java Virtual 
> > > > > > Machine has
> > > > > > made a best effort to reclaim space from all discarded objects."
>
> > > > > > ---
> > > > > >  ­--
> > > > > > TreKing  - 
> > > > > > Chicago
> > > > > > transit tracking app for Android-powered devices- Hide quoted text -
>
> > > > > - Show quoted text -
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[DanH]

Of course, finalizers have been all but deprecated on "big" Java.  Too
unreliable -- not guaranteed to run.  If the image data management
scheme relies on finalizers it's broken by design.

On Aug 10, 11:54 pm, Bob Kerns  wrote:
> This has been discussed a fair bit in the past, if you want to try to
> look for more details, but the basic issue is that there's a cascade
> effect...
>
> (This was a couple releases ago; it's possible it has been improved
> since).
>
> You call System.gc(). Some finalizers run. This enables other stuff to
> be GC'd in the next pass, which allows the bitmap data to be
> collected.
>
> Aside from looping forever until there's enough memory, or detecting
> somehow that no changes have been made to the object graph, there's
> really no way for a GC implementation to guarantee that one invocation
> has actually achieved the absolute best-possible result, when
> finalizers are involved.
>
> This could be better -- but extreme low memory is not what most GCs
> are optimized for, so a bit of manual help isn't all that abusive, in
> my opinion. The NEED for the manual help is certainly unfortunate,
> however, so I hope they do manage to improve the situation.
>
> On Aug 10, 9:19 pm, DanH  wrote:
>
> > It's kind of abusing the concept.  There should be a separate way to
> > clean up the image data (and it seems to me it should be self-
> > policing, vs having to manually do this).  But more obscene things
> > have been done in many phones, certainly.
>
> > On Aug 10, 5:16 pm, Streets Of Boston  wrote:
>
> > > I agree with you, but since the dalvik-vm does not 'see' the raw
> > > binary image data in Bitmaps, it may not kick of the garbage collector
> > > when process memory gets low. Calling System.gc() explicitly does work-
> > > around this problem and it seems to work, in my experience.
>
> > > On Aug 10, 4:43 pm, DanH  wrote:
>
> > > > I'll add that if you need to call System.gc to prevent an error then
> > > > there's a bug in the JVM.  (Not saying that there's no bug and hence
> > > > no need to call it, just saying that, per the Java spec, the system
> > > > should automatically do a GC before raising any "hard" out-of-heap
> > > > error.  The observations by the others above is presumably an
> > > > Androidism, not proper Java behavior.)
>
> > > > On Aug 10, 3:28 pm, TreKing  wrote:
>
> > > > > On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  
> > > > > wrote:
> > > > > > I think calling System.gc() doesn't immediately trigger the
> > > > > > garbage collection. So, relying on this all the time might not be a 
> > > > > > good
> > > > > > idea.
>
> > > > >http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> > > > > 
> > > > > "When control returns from the method call, the Java Virtual Machine 
> > > > > has
> > > > > made a best effort to reclaim space from all discarded objects."
>
> > > > > ---
> > > > >  ­--
> > > > > TreKing  - Chicago
> > > > > transit tracking app for Android-powered devices- Hide quoted text -
>
> > > > - Show quoted text -

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[Bob Kerns]

This has been discussed a fair bit in the past, if you want to try to
look for more details, but the basic issue is that there's a cascade
effect...

(This was a couple releases ago; it's possible it has been improved
since).

You call System.gc(). Some finalizers run. This enables other stuff to
be GC'd in the next pass, which allows the bitmap data to be
collected.

Aside from looping forever until there's enough memory, or detecting
somehow that no changes have been made to the object graph, there's
really no way for a GC implementation to guarantee that one invocation
has actually achieved the absolute best-possible result, when
finalizers are involved.

This could be better -- but extreme low memory is not what most GCs
are optimized for, so a bit of manual help isn't all that abusive, in
my opinion. The NEED for the manual help is certainly unfortunate,
however, so I hope they do manage to improve the situation.

On Aug 10, 9:19 pm, DanH  wrote:
> It's kind of abusing the concept.  There should be a separate way to
> clean up the image data (and it seems to me it should be self-
> policing, vs having to manually do this).  But more obscene things
> have been done in many phones, certainly.
>
> On Aug 10, 5:16 pm, Streets Of Boston  wrote:
>
>
>
> > I agree with you, but since the dalvik-vm does not 'see' the raw
> > binary image data in Bitmaps, it may not kick of the garbage collector
> > when process memory gets low. Calling System.gc() explicitly does work-
> > around this problem and it seems to work, in my experience.
>
> > On Aug 10, 4:43 pm, DanH  wrote:
>
> > > I'll add that if you need to call System.gc to prevent an error then
> > > there's a bug in the JVM.  (Not saying that there's no bug and hence
> > > no need to call it, just saying that, per the Java spec, the system
> > > should automatically do a GC before raising any "hard" out-of-heap
> > > error.  The observations by the others above is presumably an
> > > Androidism, not proper Java behavior.)
>
> > > On Aug 10, 3:28 pm, TreKing  wrote:
>
> > > > On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  
> > > > wrote:
> > > > > I think calling System.gc() doesn't immediately trigger the
> > > > > garbage collection. So, relying on this all the time might not be a 
> > > > > good
> > > > > idea.
>
> > > >http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> > > > 
> > > > "When control returns from the method call, the Java Virtual Machine has
> > > > made a best effort to reclaim space from all discarded objects."
>
> > > > ---
> > > >  ­--
> > > > TreKing  - Chicago
> > > > transit tracking app for Android-powered devices- Hide quoted text -
>
> > > - Show quoted text -

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[DanH]

As I mentioned earlier, many JVMs disable System.gc by default, since
the function is so often abused, and since doing unnecessary GCs is a
major performance drag.  When inserting GC calls in your code you
should be sensitive to this and use only the bare minimum necessary to
achieve "correct' (in the Android sense) operation.

On Aug 10, 5:16 pm, Streets Of Boston  wrote:
> I agree with you, but since the dalvik-vm does not 'see' the raw
> binary image data in Bitmaps, it may not kick of the garbage collector
> when process memory gets low. Calling System.gc() explicitly does work-
> around this problem and it seems to work, in my experience.
>
> On Aug 10, 4:43 pm, DanH  wrote:
>
> > I'll add that if you need to call System.gc to prevent an error then
> > there's a bug in the JVM.  (Not saying that there's no bug and hence
> > no need to call it, just saying that, per the Java spec, the system
> > should automatically do a GC before raising any "hard" out-of-heap
> > error.  The observations by the others above is presumably an
> > Androidism, not proper Java behavior.)
>
> > On Aug 10, 3:28 pm, TreKing  wrote:
>
> > > On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  wrote:
> > > > I think calling System.gc() doesn't immediately trigger the
> > > > garbage collection. So, relying on this all the time might not be a good
> > > > idea.
>
> > >http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> > > 
> > > "When control returns from the method call, the Java Virtual Machine has
> > > made a best effort to reclaim space from all discarded objects."
>
> > > ---­--
> > > TreKing  - Chicago
> > > transit tracking app for Android-powered devices- Hide quoted text -
>
> > - Show quoted text -

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[DanH]

It's kind of abusing the concept.  There should be a separate way to
clean up the image data (and it seems to me it should be self-
policing, vs having to manually do this).  But more obscene things
have been done in many phones, certainly.

On Aug 10, 5:16 pm, Streets Of Boston  wrote:
> I agree with you, but since the dalvik-vm does not 'see' the raw
> binary image data in Bitmaps, it may not kick of the garbage collector
> when process memory gets low. Calling System.gc() explicitly does work-
> around this problem and it seems to work, in my experience.
>
> On Aug 10, 4:43 pm, DanH  wrote:
>
> > I'll add that if you need to call System.gc to prevent an error then
> > there's a bug in the JVM.  (Not saying that there's no bug and hence
> > no need to call it, just saying that, per the Java spec, the system
> > should automatically do a GC before raising any "hard" out-of-heap
> > error.  The observations by the others above is presumably an
> > Androidism, not proper Java behavior.)
>
> > On Aug 10, 3:28 pm, TreKing  wrote:
>
> > > On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  wrote:
> > > > I think calling System.gc() doesn't immediately trigger the
> > > > garbage collection. So, relying on this all the time might not be a good
> > > > idea.
>
> > >http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> > > 
> > > "When control returns from the method call, the Java Virtual Machine has
> > > made a best effort to reclaim space from all discarded objects."
>
> > > ---­--
> > > TreKing  - Chicago
> > > transit tracking app for Android-powered devices- Hide quoted text -
>
> > - Show quoted text -

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[Streets Of Boston]

I agree with you, but since the dalvik-vm does not 'see' the raw
binary image data in Bitmaps, it may not kick of the garbage collector
when process memory gets low. Calling System.gc() explicitly does work-
around this problem and it seems to work, in my experience.


On Aug 10, 4:43 pm, DanH  wrote:
> I'll add that if you need to call System.gc to prevent an error then
> there's a bug in the JVM.  (Not saying that there's no bug and hence
> no need to call it, just saying that, per the Java spec, the system
> should automatically do a GC before raising any "hard" out-of-heap
> error.  The observations by the others above is presumably an
> Androidism, not proper Java behavior.)
>
> On Aug 10, 3:28 pm, TreKing  wrote:
>
>
>
> > On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  wrote:
> > > I think calling System.gc() doesn't immediately trigger the
> > > garbage collection. So, relying on this all the time might not be a good
> > > idea.
>
> >http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> > 
> > "When control returns from the method call, the Java Virtual Machine has
> > made a best effort to reclaim space from all discarded objects."
>
> > ---­--
> > TreKing  - Chicago
> > transit tracking app for Android-powered devices- Hide quoted text -
>
> - Show quoted text -

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[DanH]

However, System.gc is so commonly abused that most implementations
ignore it.

On Aug 10, 3:28 pm, TreKing  wrote:
> On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  wrote:
> > I think calling System.gc() doesn't immediately trigger the
> > garbage collection. So, relying on this all the time might not be a good
> > idea.
>
> http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> 
> "When control returns from the method call, the Java Virtual Machine has
> made a best effort to reclaim space from all discarded objects."
>
> -
> TreKing  - Chicago
> transit tracking app for Android-powered devices

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[DanH]

I'll add that if you need to call System.gc to prevent an error then
there's a bug in the JVM.  (Not saying that there's no bug and hence
no need to call it, just saying that, per the Java spec, the system
should automatically do a GC before raising any "hard" out-of-heap
error.  The observations by the others above is presumably an
Androidism, not proper Java behavior.)

On Aug 10, 3:28 pm, TreKing  wrote:
> On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  wrote:
> > I think calling System.gc() doesn't immediately trigger the
> > garbage collection. So, relying on this all the time might not be a good
> > idea.
>
> http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.htm...()
>
> 
> "When control returns from the method call, the Java Virtual Machine has
> made a best effort to reclaim space from all discarded objects."
>
> -
> TreKing  - Chicago
> transit tracking app for Android-powered devices

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Re: [android-developers] Re: Do we need to call System.gc() ?

[TreKing]

On Tue, Aug 10, 2010 at 3:22 PM, Kumar Bibek  wrote:

> I think calling System.gc() doesn't immediately trigger the
> garbage collection. So, relying on this all the time might not be a good
> idea.
>

http://download.oracle.com/javase/1.4.2/docs/api/java/lang/System.html#gc()


"When control returns from the method call, the Java Virtual Machine has
made a best effort to reclaim space from all discarded objects."

-
TreKing  - Chicago
transit tracking app for Android-powered devices

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[Kumar Bibek]

I think calling System.gc() doesn't immediately trigger the garbage
collection. So, relying on this all the time might not be a good idea.

-Kumar Bibek
http://techdroid.kbeanie.com

On Aug 11, 1:09 am, Streets Of Boston  wrote:
> Yep, it works for me too. But i only use it when dealing with bitmaps
> just to be sure that the garbage collector will release raw binary
> image data for unreferenced Bitmaps.
>
> Actually, i call System.gc() before creating a new bitmap. This makes
> the code in your 'catch' clauses obsolete:
>
> 1. Call System.gc() to make sure that raw binary data is released in
> case the dalvik-vm didn't realise memory gets low.
> 2. Create a new bitmap.
>
> On Aug 10, 1:46 pm, Greg Donald  wrote:
>
> > On Mon, Aug 9, 2010 at 11:16 PM, Alex Xin  wrote:
> > > Hi,
> > > Do we need to call System.gc() to indicate that system should do a garbage
> > > collection or just let system to choose when to collect garbage and free 
> > > it?
> > > Because my app will random FCs on certain phones, but if I add some calls 
> > > to
> > > System.gc(), then there were no FCs.
>
> > I do the same thing.  Blocks of code like this are very common in my apps:
>
> > try
> > {
> >   cards = BitmapFactory.decodeResource( resources, R.drawable.cards );}
>
> > catch( Error e )
> > {
> >   System.gc();
> >   cards = BitmapFactory.decodeResource( resources, R.drawable.cards );
>
> > }
>
> > It's not pretty, but it works great.
>
> > --
> > Greg Donald
> > destiney.com | gregdonald.com

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

[android-developers] Re: Do we need to call System.gc() ?

[Streets Of Boston]

Yep, it works for me too. But i only use it when dealing with bitmaps
just to be sure that the garbage collector will release raw binary
image data for unreferenced Bitmaps.

Actually, i call System.gc() before creating a new bitmap. This makes
the code in your 'catch' clauses obsolete:

1. Call System.gc() to make sure that raw binary data is released in
case the dalvik-vm didn't realise memory gets low.
2. Create a new bitmap.


On Aug 10, 1:46 pm, Greg Donald  wrote:
> On Mon, Aug 9, 2010 at 11:16 PM, Alex Xin  wrote:
> > Hi,
> > Do we need to call System.gc() to indicate that system should do a garbage
> > collection or just let system to choose when to collect garbage and free it?
> > Because my app will random FCs on certain phones, but if I add some calls to
> > System.gc(), then there were no FCs.
>
> I do the same thing.  Blocks of code like this are very common in my apps:
>
> try
> {
>   cards = BitmapFactory.decodeResource( resources, R.drawable.cards );}
>
> catch( Error e )
> {
>   System.gc();
>   cards = BitmapFactory.decodeResource( resources, R.drawable.cards );
>
> }
>
> It's not pretty, but it works great.
>
> --
> Greg Donald
> destiney.com | gregdonald.com

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en