Dima:
Thanks for your reply.
Sorry for my unclear description about the managed heap, I mean the heap
managed by GC and unmanaged heap is just the ordinary native runtime heap.
I may be wrong, so please correct me if my understanding is incorrect. I
have collected some runtime information of the maps application by the proc,
and from the trace, i categorize the [heap] as native runtime heap, and the
/mspace/dalvik-heap/2 as the my interested GC managed heap. Here is my
collected information, i did some pan around in the wole process:
Name Size Rss
[heap] 4916K 4916K
[dalvik-heap] 1476K 1476K
...
[heap] 5876K 5876K
[dalvik-heap] 1504K 1504K
...
[heap] 6748K 6748K
[dalvik-heap] 1920K 1920K
...
[heap] 4924K 4924K
[dalvik-heap] 1504K 1504K
...
[heap] 7400K 7400K
[dalvik-heap] 2080K 2080K
...
[heap] 7056K 7056K
[dalvik-heap] 2384K 2384K
Yes, I have observed the logcat showed a lots of GC activities. But it
doesn't increase the dalvik heap much. The largest heap seems to be 3MB or so.
It seems that even the application is all in dalvik, it is still possible to
allocate memory in native heap, at least the dalvik vm needs allocation for VM
related data structures in it, some native libaries that dalvik VM utilizes may
also need, etc.
--
Chen
________________________________
From: [email protected]
[mailto:[email protected]] On Behalf Of Dima Zavin
Sent: Friday, January 02, 2009 2:22 PM
To: [email protected]
Subject: [android-porting] Re: 128MB runtime heap for Asus eee target
I'm not sure I understand the what unmanaged heap you are talking about. AFAIK
maps is all dalvik, so there are no native components allocating memory.
You should look at logcat to see when the maps vm does garbage collection.
Also, when you start maps, pan around a lot, in all different directions.
Maps is a proprietary application and there are no plans to open source it.
--Dima
On Wed, Dec 31, 2008 at 1:08 AM, Yang, Chen
<[email protected]<mailto:[email protected]>> wrote:
Dima:
Thanks for your explanation. It looks reasonable.
Would you like to give some more information on the scenarios(applications)
that demand large memory in managed heap? I am interested to know.
I have tried the maps application got from the emulator and put under
resolution of 800x600, and found the managed heap increased not so much as the
unmanaged heap. And from my evaluation the managed heap only increases to 3MB
or so. While from my similar evaluation on the default emulator, it consumes
about 2MB, it also showed large consumption in unmanaged heap. I am guessing
mainly it is due to the screen resolution difference.
Has the source code of maps application been open sourced or does google plan
to do so? Thanks.
--
Chen
________________________________
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Dima Zavin
Sent: Wednesday, December 31, 2008 3:28 AM
To: [email protected]<mailto:[email protected]>
Subject: [android-porting] Re: 128MB runtime heap for Asus eee target
The primary reason this was chosen was due to larger screen size on the eeepc
compared to HVGA on the dream. The maps application would cache a certain
number of tiles, and when the screen got big, it blew REALLY fast through the
standard 16mb heap and then the vm crashed because it couldn't gc to free up
memory for more objects. The 128 was most certainly a swing towards the other
extreme (there was no pressing need for me to find the "best" number, just one
that worked). I'm sure a smaller number would work just fine. Feel free to
experiment.
--Dima
On Mon, Dec 29, 2008 at 10:44 AM, Yang, Chen
<[email protected]<mailto:[email protected]>> wrote:
I noticed that the maxium heap size for Asus eee was set to be 128MB, would
some one give some hints on the rationale behind? Thanks.
--
Chen
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
