1

So my question is similar to this: Android: how to increase heap size at runtime?

However, since I'm not dealing with caching, the answer provided about a better caching implementation does not apply to me. My goal is allocate a large heap as a temporary solution to my timing issue that I believe GC_CONCURRENT is affecting and my goal is to allocate a heap such that GC_CONCURRENT doesn't happen. I would like to emphasize I do not have a memory leak as when GC_CONCURRENT runs it always frees up 15% and that number does not go down and I've since optimized my code such that I have no variable initializations in any loops and things are declared static and final where possible.

I've tried setting android:largeHeap="true" but it has had no visible effect so I'm looking for something that isn't a polite request to the OS and does effectively the same thing as the depreciated VMRuntime.getRuntime().setMinimumHeapSize(BIGGER_SIZE)

trincot
  • 317,000
  • 35
  • 244
  • 286
Kurt Wagner
  • 3,295
  • 13
  • 44
  • 71

2 Answers2

3

I'm looking for something that isn't a polite request to the OS and does effectively the same thing as the depreciated VMRuntime.getRuntime().setMinimumHeapSize(BIGGER_SIZE)

There is no means to do this in the Android SDK. Otherwise, every developer would think that they are a special snowflake and deserve 16GB of system RAM on a 512MB device.

I've tried setting android:largeHeap="true" but it has had no visible effect

You can use getMemoryClass() and getLargeMemoryClass() (on ActivityManager) to see what the difference is in your heap limit when using android:largeHeap="true". Also, bear in mind that android:largeHeap="true" is only available on API Level 11+ devices.

I've since optimized my code such that I have no variable initializations in any loops and things are declared static and final where possible.

You are certainly welcome to use the DDMS Allocation Tracker, heap dumps, and the like to determine the source of your memory usage that is triggering the GC.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • 1
    "Otherwise, every developer would think that they are a special snowflake and deserve 16GB of system RAM on a 512MB device" . I am creating an in house app for an android tablet with 12gb of ram, in react native. I cannot locally fetch(localuri) a 200mb mp4, to create a read Stream without fetch failing because of an OOM. This is with largeHeap=true. Certainly I 'deserve' more ram and the decision to do so. – JohnyClash Feb 21 '23 at 08:43
  • 1
    @JohnyClash: Your problems are more specific to your choice of environment (React Native) and/or some plugin for that environment. Amazon S3 on its own does not require reading 200MB into heap space to upload that 200MB, and you can [stream up the blob using the Java SDK](https://stackoverflow.com/q/51245535/115145). Your React Native issues are not Android's fault. – CommonsWare Feb 21 '23 at 12:17
  • "Otherwise, every developer would think that they are a special snowflake and deserve 16GB of system RAM on a 512MB device." is fallacious, you used a strawman fallacy to support your opinion that it is correct for there to not be an option to allocate heap size. I simply gave an example, in which its certainly realistic to expect the ability to allocate a specific heap size. Having an application running in foreground which requires 600mb memory on a device with 12gb of memory is simple and fully should be expected from any open source development environment. – JohnyClash Feb 22 '23 at 23:57
  • 1
    @JohnyClash: "fully should be expected from any open source development environment" -- you are welcome to build Android from its open source code and set the heap limit to be whatever you want. If you want to use an existing commercial build of Android from a device manufacturer, the device manufacturer will be in charge of the heap limit. That is because Android is primarily a consumer OS, and consumers want their devices to work, despite developers who want to abuse the system resources. – CommonsWare Feb 23 '23 at 00:05
  • @Commonwealth "despite developers who want to abuse the system resources." are you inferring that 600mb out of 12gb is representative of developer or abuse or are you referring once again to the original straw man? – JohnyClash Feb 23 '23 at 00:22
  • 1
    @JohnyClash: You do not want any heap limit. 600MB is *your* strawman, not mine. So, go build yourself some firmware for your tablet that raises the limit to be what you want, rather than what the device manufacturer felt was best, overall, for all users of that particular device. Or, poke around to see if you can raise the heap limit by rooting the device. Or, use the NDK, as native memory allocations (`malloc()` and things built atop it) are not subject to the heap limit. Or use multiple processes, etc. – CommonsWare Feb 23 '23 at 00:34
-1

If you want to avoid using largeHeap"true" there's another alternate option which is used for tweaking memory settings. All you have to do is add/replace the existing line in gradle.properties file

org.gradle.jvmargs=-Xmx1024m

TechInsect
  • 124
  • 1
  • 2