16MB heap limit

[David Sauter]

Has anyone figured out a way around this that's reliable yet?

--
------
David Sauter

[Gnathonic]

Nexus one is 24MB limit... still, knowing how to exceed the 16 would
be useful for deving for older devices.

[Jack Palevich]

You might try using mmap to map a file on the SD card. Sort of a poor-
man's swap file. I did that for the texture cache in my GLESQuake port
and it worked fine on G1, etc.

See the class textureStore in this file for details:

http://code.google.com/p/glesquake/source/browse/quake/src/WinQuake/gl_draw.cpp

[David Sauter]

On Wed, Jan 6, 2010 at 8:26 PM, Jack Palevich <jack.p...@gmail.com> wrote:
> You might try using mmap to map a file on the SD card. Sort of a poor-
> man's swap file. I did that for the texture cache in my GLESQuake port
> and it worked fine on G1, etc.
>
> See the class textureStore in this file for details:
>
> http://code.google.com/p/glesquake/source/browse/quake/src/WinQuake/gl_draw.cpp

Given that my project is well over 200MB in data alone I'd already
intended on using the SD card for data storage. The problem is that
we really do need 30+ MB of ram.

Is anyone working on a real swap system for Android? There's some
things that could get swapped out until they're needed to get us under
the 24MB limit of the Nexus but the real goal is the Droid at 16 MB.

Or is the Droid going to get the 2.1 update and thus the 24MB limit?

David Sauter

[Kevin Duffey]

I apologize for asking this noob question..but what 16MB limit are you referring to? I thought an app had up to 256MB ram available to it? I know android can shut down apps if it needs memory for other activities/services, but I thought you could theoretically go up to that much memory. If I were to make a music app that loaded in 64 samples, and each was 256KB, I am essentially out of room to store music information? What happens.. an out of memory error is thrown? 

Wow, these are things I am not finding out in the various books I've read. These types of details should be put into a book.. or perhaps they are so scattered throughout a book that I am just not remembering them. 

What sort of ram does the iPhone give it's applications?

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

[Jack Palevich]

I don't understand why using mmap won't help you. mmap allows you to
map a file into your application address space, whereupon you can read
and write the contents of the file using ordinary memory operations.

You can't use malloc, but you can use your own memory allocators to
manage the mmapped memory.

On Jan 7, 12:12 pm, David Sauter <del...@gmail.com> wrote:

> On Wed, Jan 6, 2010 at 8:26 PM, Jack Palevich <jack.palev...@gmail.com> wrote:
> > You might try using mmap to map a file on the SD card. Sort of a poor-
> > man's swap file. I did that for the texture cache in my GLESQuake port
> > and it worked fine on G1, etc.
>
> > See the class textureStore in this file for details:
>

> >http://code.google.com/p/glesquake/source/browse/quake/src/WinQuake/g...

[Dianne Hackborn]

All high density devices, including Droid, have a limit of 24MB in the Java heap because of the additional memory they have and the need for more space for high density images.

This limit was very specifically chosen as a reasonable amount of memory to provide to the app without it causing bad out of memory conditions for the rest of the system.  Please don't significantly exceed it.  For some perspective: on older devices with 16MB, the web browser can grow to using 24MB or a little more, but when these happens it greatly restricts what can run in the background and thus the user experience -- for example causing the home app to be tossed from memory, so the next time the user goes to it they need to wait for it to be restarted.

Also given that this is the NDK list, the limit is actually not imposed on you, because it is only on the Java heap.  There is no limit on allocations in the native heap...  that said, if we start to see applications take advantage of this to allocate significantly more memory above the value returned by http://developer.android.com/intl/fr/reference/android/app/ActivityManager.html#getMemoryClass() then we will probably be forced to make the platform more aggressive about finding and killing such apps to keep everything running well.

On Wed, Jan 6, 2010 at 8:12 PM, David Sauter <del...@gmail.com> wrote:

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

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[David Sauter]

On Thu, Jan 7, 2010 at 3:27 AM, Dianne Hackborn <hac...@android.com> wrote:
> All high density devices, including Droid, have a limit of 24MB in the Java
> heap because of the additional memory they have and the need for more space
> for high density images.

We also need the memory for higher density geometry and textures.

> This limit was very specifically chosen as a reasonable amount of memory to
> provide to the app without it causing bad out of memory conditions for the
> rest of the system.  Please don't significantly exceed it.

The problem is that this limit cripples the OS for use as a gaming platform.

> For some
> perspective: on older devices with 16MB, the web browser can grow to using
> 24MB or a little more, but when these happens it greatly restricts what can
> run in the background and thus the user experience -- for example causing
> the home app to be tossed from memory, so the next time the user goes to it
> they need to wait for it to be restarted.

Older devices don't have the GPU to handle modern games so that's not
an issue. Droid and Nexus One do.

> Also given that this is the NDK list, the limit is actually not imposed on
> you, because it is only on the Java heap.  There is no limit on allocations
> in the native heap...  that said, if we start to see applications take
> advantage of this to allocate significantly more memory above the value
> returned
> by http://developer.android.com/intl/fr/reference/android/app/ActivityManager.html#getMemoryClass() then
> we will probably be forced to make the platform more aggressive about
> finding and killing such apps to keep everything running well.

Which means there's no use even trying to get real gaming working on
Android. Even if we can manage to get things working right now you've
just threatened to come along with an OS update later that will kill
any process running above your arbitrary limit.

If memory is so much a bottleneck why doesn't Android have a real swap
built into the OS? Why do Nexus and Droid have the same limits when
the Nexus has twice the RAM of the Droid? Why is Droid's limit only
50% above th G1 when it's got 75% more RAM?

Unless Android 2.0 is significantly more memory intensive than 1.6 the
Droid should have 28MB heap and the Nexus a 56MB limit. At those
numbers we might be able to do something with the Droid and we can
code to the Nexus with few issues - but trying to get production
quality gaming on lower memory counts means we'll be looking like
Dreamcast era games not XBox era which is where the iPhone is.

Is there any chance we can get some OS functionality to request a
larger than getMemoryClass() value of memory and have the kernel reply
if this is possible? We can ask the user to shut off other apps
running in order to free up enough memory then make the request again
if the kernel replies in the negative. That would solve everyone's
problems.

I don't mind warning the user that a given game is going to mostly
take over the phone but I do mind it getting killed by the kernel out
from under us in a future OS update.

--
------
David Sauter

[Kevin Duffey]

Agreed with David.. although I would love to hear if the iPhone has a similar limitation. I am also concerned that any sort of decent quality music app is possible with such limits. My favorite app on iPhone is BeatMaker. There are some other very goods ones as well which I haven't tried. To make a sort of quality MPC drum machine app like BeatMaker, each sound at 24-bit audio, or even 16-bit audio, that could be several seconds in length, is going to severely limit how much can be loaded at one time. I'd hate to write this great killer drum machine app and then have it pop up on the user "Ooops..that sample is too big, and you can't load any more.. sorry to limit your experience with our otherwise very good music app". If keeping the sounds on the SD card is possible.. such that as the user strikes a pad we could load and play the sound instantly, that would be fine. But I am guessing the SD card read speed is way too slow for real-time playback.

What would be really helpful is some sort of specific developer forum that google and other android team developers can talk with those of us that are looking to build next-gen iPhone comparable (or better) applications. In my opinion, it's these types of apps that will really take Android to the level of iPhone and possibly help surpass iPhone market share. I think right now, like myself, most developers gearing up for Android development have these grandiose plans for great applications and don't know some of these limitations. With little audio capabilities, too high latency, very limited memory footprint and probably some other things I've not yet learned, right now it sounds like Android is really good for basic apps, but the big two, media and gaming, sound like they are very restricted and we're going to be waiting quite a while before we can build these level of applications. I am not saying it's not possible.. I've heard there is a quake port on Android, and I've seen some decent games, but nothing that comes close to what we're seeing on iPhone. It's a shame because all of the devices coming out right now for Android easily have the cpu/gpu capabilities to be every bit as good.

I still have high hopes for Android, I trust that the google/android team will get enough requests/forum posts from us developers and speed up the development of these areas so that Android can truly be the best platform out there (even if that isn't the initial goal). I think it might be difficult at best for Android to surpass iPhone if it won't support the gaming and music (and media..such as video players with the various decoders) that iPhone currently has. 

[Lucas]

In the company i work for (gaming one), we develop for iPhone and we limit ourselves to not more than 35mb of heap ussage, even if in our tests the phone handled up to 60mb without problems. That was suggested by apple (it seems that it can have some impact in the OS stability if all apps want to use more than 35mb each. And here i am talking about big games (100mb and more of size).

So i think Android should allow a workaround, may be having a permission that lets the app grow the memory bounds, and then for all apps that use that permission, the OS can present the user a warning screen, and even if there is not enough free memory to run it, bring to the user a task killer like app to free some space.

just me 2 cents.

--
Lucas Shrewsbury
----------------------------------------------------
Open Your Mind, Use Open Source

[Jack Palevich]

Again, you could and should be using mmap to avoid having to create a
huge heap in the first place.

For a game, unless you're doing something seriously unusual, most of
the data you have in RAM is going to be textures, geometry, animation
data, sound. All of this can be stored in files and mmapped.

Keep the heap free for dynamic data and data that is allocated by
libraries.

Mmapped data is not going to count against your heap limit, and it's
not going to negatively affect the system performance, so it's
unlikely to cause your application to be killed for using too much
system resource.

> >> On Thu, Jan 7, 2010 at 3:27 AM, Dianne Hackborn <hack...@android.com>

> >>http://developer.android.com/intl/fr/reference/android/app/ActivityMa...()<http://developer.android.com/intl/fr/reference/android/app/ActivityMa...>

> >> android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>

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

> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>

[David Sauter]

> Mmapped data is not going to count against your heap limit, and it's
> not going to negatively affect the system performance, so it's
> unlikely to cause your application to be killed for using too much
> system resource.

No, but unless that SD card is a lot faster than any other I've seen
you're going to hammer your frame rate by putting any data that's
being used in the rendering pipeline on it. That data alone can be
well over 20-30 MB even for small games.

The GPU on these is using that same 16/24MB heap for it's assets too.
Even if you could get the game itself (without rendering assets) to
live in 2-4 MB when was the last time you saw a 3D game that had less
than 14MB in rendering assets on the screen at once?

Not to mention the Droid is more than 2x the resolution of the iPhone.
That means you need 2x the texture resolution minimum for something
to look the as good or better than it's iPhone counterpart. You can
blow a dozen megs in texures before your artists have even blinked.

If Android is going to be taken seriously as a gaming platform we need
some way to request the system give us a much larger chunk of memory
than normal apps live in.

David Sauter

[Dianne Hackborn]

On Thu, Jan 7, 2010 at 5:08 PM, David Sauter <del...@gmail.com> wrote:

No, but unless that SD card is a lot faster than any other I've seen

you're going to hammer your frame rate by putting any data that's
being used in the rendering pipeline on it.  That data alone can be
well over 20-30 MB even for small games.

If there is enough RAM, the data will be kept in RAM.  If not...  well, you still run.

And your suggestion of swap would have exactly the same problem...  actually worse, because swap couldn't be on the SD card, and internal flash is often slower than the SD card.

 

The GPU on these is using that same 16/24MB heap for it's assets too.
Even if you could get the game itself (without rendering assets) to
live in 2-4 MB when was the last time you saw a 3D game that had less
than 14MB in rendering assets on the screen at once?

Did you read what I wrote??  The heap limit is ONLY for the Java heap.  Not the native heap, and certainly not the GPU.  It doesn't even make sense to have this discussion in a group for the NDK, since the limit doesn't apply there at all.

Though, again, you do need to be careful about your memory usage or you are going to cause problems and in the future we may need to do something about that in the platform.

[David Sauter]

> Did you read what I wrote??  The heap limit is ONLY for the Java heap.  Not
> the native heap, and certainly not the GPU.  It doesn't even make sense to
> have this discussion in a group for the NDK, since the limit doesn't apply
> there at all.

Why yes I did. I was going to quote it here but you reiterated
yourself in the next paragraph.

> Though, again, you do need to be careful about your memory usage or you are
> going to cause problems and in the future we may need to do something about
> that in the platform.

That right there is the problem. I'm looking at 6-7 digit budgets for
Android titles. There's no way in this world I can pour that kind of
money into a title when you've already stated that you "may need to do
something about that."

Your attitude that applications only need to use a fraction of the
power of the device when iPhone apps get to use almost all of it means
that Android will never be able to compete with iPhone as a gaming
platform.

That's the core of the problem.

Interestingly the solution is actually fairly simple. The permissions
platform already requires apps to request what resources they will
need. Adding a new one that turns off the ability of the kernel to
kill the process due to low resources but instead puts a pre-requested
hard limit on it. The rest of the phone can operate normally with
total - requested RAM until the app closes for other reasons
(obviously manual force terminate and terminate on fatal error would
have to be immune from the kernel shutoff).

At that point we can determine what phones are capable of running the
games (likely 2.0 or greater) and then go from there.

--
------
David Sauter

[Jack Palevich]

Have you actually developed for iPhone, or are you just assuming that
iPhone gives you more resources than Android because it only runs one
application at a time?

While I'm not an iPhone developer, I have read discussions in public
web forums that lead me to believe that iPhone app limits are actually
pretty similar to Android app limits. See this thread, for example,
where iPhone developers say they should limit their iPhone heap to
10-20MB of RAM:

http://www.iphonedevsdk.com/forum/iphone-sdk-development/6606-limit-ram-usage.html

And in this very thread you can read an iPhone developer is limiting
their apps to 32 MB of RAM.

[Dianne Hackborn]

On Thu, Jan 7, 2010 at 11:04 PM, Jack Palevich <jack.p...@gmail.com> wrote:

And in this very thread you can read an iPhone developer is limiting
their apps to 32 MB of RAM.

And 32MB of RAM is certainly fine for Droid/Nexus One class devices.  It is a little over the top for lower-end devices, but you can probably get away with it though causing most things in the background to stop running for the duration.  (Note something you want to do to the user experience, since sync and other things may no longer run, but you'll survive.)

[Lucas]

I was the one who talked about iPhone development, and we are limiting ourselves to 35mb (heap, not counting GPU here), but that is a limit impossed by us in order to let ours games run without problems in any iPhone device (this restriction mainly is because jailbreaked devices ussually have custom themes running that consume lot more heap than the standard one, and in the company we aim to run our games in every single iPhone out there from 1G to 3GS).

From what Dianne points about GPU not counting, i think we can aim at lest for Droid/Nexus to make some games similar to iPhone quality. But we must take really care on how we write our resource loading routines, because in iPhone during loadings (while textures are being passed to GPU), it is common to exceed the 35mb limit in some peaks. Also i think it must be key to make a good use of NDK when we need some extra mb's in our game.

regards,

Lucas

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[David Sauter]

On Fri, Jan 8, 2010 at 12:04 AM, Jack Palevich <jack.p...@gmail.com> wrote:
> Have you actually developed for iPhone, or are you just assuming that
> iPhone gives you more resources than Android because it only runs one
> application at a time?

We've got three iPhone games on the market and two more that will be
released in the next month or so. Our memory footprint on the iPhone
(with less than half the resolution to deal with) is 40+ MB.

--
------
David Sauter

[David Sauter]

So we won't be seeing future OS updates that will apply the Java limit
to NDK allocations or if we do the limit will be >= 32MB for Android
2.X phones? If we can't get a game mode in the kernel that guarantee
will still give us enough room do to slightly stripped down versions
of our iPhone games for Android as well as move forward with Android
first run titles.

--
------
David Sauter

[Doug Schaefer]

I keep coming back to Dianne's previous comment that native code does not have these limits. Successful game developers are going to have to figure out how to do as much in native versus Java as possible. Yes/no?

[David Sauter]

>> So we won't be seeing future OS updates that will apply the Java limit
>> to NDK allocations or if we do the limit will be >= 32MB for Android
>> 2.X phones?  If we can't get a game mode in the kernel that guarantee
>> will still give us enough room do to slightly stripped down versions
>> of our iPhone games for Android as well as move forward with Android
>> first run titles.
>>
>
> I keep coming back to Dianne's previous comment that native code does not
> have these limits. Successful game developers are going to have to figure
> out how to do as much in native versus Java as possible. Yes/no?

Yes.

On top of that it was the vague 'but if you use too much we'll change
the OS to put in limits' that scared the daylights out of me.

Dainne has stated that 32MB 'should' be OK on the Android 2.X phones
(Droid and Nexus). While it'll take some retooling of our engine to
put more pressure on the CPU to take pressure off memory (since the
old iPhones had the exact opposite problem - high memory low
processor) we should be able to bring our iPhone titles to Android so
long as that 32MB soft limit is real and we don't get busted back to
24MB in a future update.

... that brings a question to mind. If 32MB is OK for NDK apps on
Droid/Nexus why isn't that the JDK limit?

--
------
David Sauter

[Sean Hodges]

On Fri, Jan 8, 2010 at 4:02 PM, David Sauter <del...@gmail.com> wrote:
> On top of that it was the vague 'but if you use too much we'll change
> the OS to put in limits' that scared the daylights out of me.

Seems a fair point to me. The user is not going to want their phone
running like a dog because all their apps are evading the platform
limits and placing large amounts of data in RAM just so they load up
more quickly.

I think what people should really be asking for is a method of putting
the phone into a "gaming mode" profile, where the memory allocation is
more favourable to the running app, but other services and apps are
suspended to ensure the phone is not left in an unstable state.
Really, the only thing that should be active at this point is the
telephony service. This will mean no in-game SMS, email, or Web
browsing; but we are talking about maximising resources for game
performance, right?

[Doug Schaefer]

On Fri, Jan 8, 2010 at 11:02 AM, David Sauter <del...@gmail.com> wrote:

>> So we won't be seeing future OS updates that will apply the Java limit
>> to NDK allocations or if we do the limit will be >= 32MB for Android
>> 2.X phones?  If we can't get a game mode in the kernel that guarantee
>> will still give us enough room do to slightly stripped down versions
>> of our iPhone games for Android as well as move forward with Android
>> first run titles.
>>
>
> I keep coming back to Dianne's previous comment that native code does not
> have these limits. Successful game developers are going to have to figure
> out how to do as much in native versus Java as possible. Yes/no?

Yes.

On top of that it was the vague 'but if you use too much we'll change
the OS to put in limits' that scared the daylights out of me.

Well, hopefully Dianne et al won't insult the intelligence of their community by doing that. I really like the discussion in this thread as it's pointing out what I've thought for quite a while and why I see the NDK as critical to the success of Android. Android needs gaming to challenge the iPhone and the Android Java SDK is very poor for that.

 

Dainne has stated that 32MB 'should' be OK on the Android 2.X phones
(Droid and Nexus).  While it'll take some retooling of our engine to
put more pressure on the CPU to take pressure off memory (since the
old iPhones had the exact opposite problem - high memory low
processor) we should be able to bring our iPhone titles to Android so
long as that 32MB soft limit is real and we don't get busted back to
24MB in a future update.

... that brings a question to mind.  If 32MB is OK for NDK apps on
Droid/Nexus why isn't that the JDK limit?

Well, the main reason I could see is that, since Java takes care of memory for you, i.e. garbage collection, Java developers rarely worry about memory. They are much more likely to accidentally allocate too much memory than native developers. One of my motos: "Java makes you dumb." Tongue and cheek, of course ;).

[David Sauter]

I've asked for something similar but I don't think a full lockout is
needed. The phone/wifi/bluetooth radios are required for any kind of
multiplayer and geolocating is required for targeted advertisement.
If all you do is allow suspend or swap out any apps that the one
requesting game mode doesn't publish intents for and the phone itself
(since you don't want to miss calls just because you are playing a
game). People aren't going to be annoyed that there's a few second
delay for the phone to come back up to speed after being in a game so
long as critical real time functionality (I.E. the phone) is still
responsive.

That combined with a promise that the kernel won't be killing your
process unless it really does run out of RAM should be more than
enough to free up the kinds of room modern top tier games need.
Especially in the Nexus with it's 512 MB of RAM.

--
------
David Sauter

[Mike Kedl]

I'm just wondering which way we would want to go?

1) Specify apps that should be stalled while "high performance application" is running? (stall k-9, gmail, IM notifications, SMS/MMS notifications, calendar sync, contacts sync, Touchdown, etc)  Is this somehow how the existing "disable sync" is supposed to work but it doesn't?

2) Specify apps that should NOT be stalled while "high performance application" is running (DON'T stall phone, wifi, gps, bluetooth, receiving of SMS/MMS/IM (just don't display), etc)

I had thought about this before and I think a way to go into "high performance" mode will be useful.  I just wonder if "disable sync" is the way to do this.

[Kevin Duffey]

This is possibly off topic of the OP.. I apologize, but it seems those discussing this in this thread would have the best possible chance of answering this.

Couple questions regarding memory differences between devices... First..is there any way for an app to specify a minimum amount.. thus allowing it to only show up on the market of those devices that could actually support it? I can imagine a support nightmare when a G1 users downloads a Nexus aimed game and it wont run. I also imagine the app feedback ruining the chance of this game even being looked at when all those G1 users give it a 0/1 start and bad comments. That is one thing that scares the hell out of me.. with all these different platforms, memory footprints, cpu/gpu speeds, screen sizes, etc that Android will run on, how do we control the users that can actually see the app on the market in the first place? I don't even want a G1 users seeing my Nexus bound game.

Second, maybe I am way off on this as I have yet to do any NDK development, but from the various threads, it seems as if there are several limitations passing things like sound, image tiles, and such to the NDK since it can't fully use the audio/video hardware directly.. did I misread this.. I read that OpenCL may be coming soon for sound, and some sort of OpenGL or something like it for video/games.. but is that going to be reachable by the NDK such that I could use the Java portion of my game to start things up, do highscore screen, menus, etc.. but the bulk of the game is in the NDK/C code including rendering to the screen, moving animations, mixing audio channels for SFX and music, and all that? Or is that currently not possible and we don't know when we will be able to put the bulk of the game into the native code without having to pass it back thru JNI to the Java layer to render it, play it, etc?

As for the high-performance mode.. count me in. In fact, as I've shown my phone to many iPhone users.. most run in fear. Trying to explain multiple apps running at once, having to kill "badly written battery offending apps" manually, and so forth.. I am going out on a limb here, but I would guess the #1 support issue for all android devices is "why did my battery die so fast.".. because they are going to install some app that starts a service and doesn't stop it properly, or something.. and the battery is going to drain. I'd opt for perhaps rather than a high-performance mode a sort of iPhone like mode.. little bit more tho. That is.. a single app can run while core phone functions like sms, phone, etc can run in the background, with some sort of options for users to indicate what they are willing to live without (configure the one-app mode). I notice a LOT of games that have no exit. You hit home/back and you simply go there. I have no clue if the game is still running or not. I can pull it up on the Advanced Task Killer and see it's still running..but is it just paused, is a background game loop thread running, what? Hardly any games catch the back button (or in the onPause() or what have you) to properly stop everything and literally close the game. There are some, but most seem to at least be still running. I would rather see a single app mode like I said and when you hit back/home, it kills the app, just like iPhone does.

[NoAngel]

Most of game developers are using compressed and/or encrypted game resources to protect ther IP.

So no easy way with mmap.

2010年1月7日木曜日 12時26分14秒 UTC+9 Jack Palevich: