• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Dalvik VM Fully 100% Explained & How to improve memory usage

Status
Not open for further replies.
D

Deleted User

Guest
So what is Dalvik VM?

Dalvik VM is a unique Java Virtual Machine Runtime used to distribute the amount of memory each application is given such as the following that you see in your "build.prop"

dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=192m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m

As you can see each line is important for dalvik vm to work and without a single one makes your system unbootable.

"dalvik.vm.heapsizestart=" this line is based upon how dalvik will start in the size it is set in your build.prop file, depending how much it's given will determin how fast of a rate dalvik will read think of this as it's percentage of rate transfer when setting this, the default value is "8m" you can set it beyond the default value but becareful depending on your heapsize limit can break and make your os unbootable, we recommend you not to set it above "10m" if you want you can go up to the max 16m as your starting point but this can cause instability and prevent apps to load requiring you to restart your device to fix it!.

Let's talk about "dalvik.vm.heapgrowthlimit=" this value is the about of memory given to each app depending how the application is coded it may override this to use the full amount of memory needed to run the application. For example say your limit is "128m" but your heapsize is 256m though "128m" is half of 256m this.means apps are given 128m out of 256m to use and lowering the amount of physical ram to be used. We recomend to always use half of your Dalvik VM in order to get the best optimal config for your device.

Let's talk about ”dalvik.vm.heapsize=" this line is your primary amount of memory dalvik is given to the OS this is improtant because it uses the amount to reserve in your Physical ram usage, for example say your device has 3GB of physical ram and your heapsize is set as "512m" no matter how your heapgrowth limit is set dalvik will always reserve 512MB extra ram in case of an emergency when ram is needed for operations that uses dalvik VM this can be useful for app performance but utilizes more ram and giving you less free ram for you to use. If you want to free more ram you can set this to a lower dalvik vm size but not too low and don't go under 128m as dalvik has a requirement witch is currently unknown and is unsure if its safe.

Let's talk about "dalvik.vm.heaptargetutilization=" many devices uses this to give a delay when dalvik vm start on device boot. The default value is "0.75" the higher the value the longer dalvik has to be delayed to start, but the lower you set the value at the faster the post process will be!

Let's now talk about "dalvik.vm.heapminfree=" & ”dalvik.vm.heapmaxfree=" these are important however what these lines do is force dalvik vm to clear and keep a certain amount of memory free in case of an emergency but does nit affect how ram is utilized it's just there to save a certain amount when needed!. The default for the min is "2m" and the max is "8m".

So if you have a device that has lessthen 4GB of ram and want to save a good amount of ram for you to use use these values below:

dalvik.vm.heapstartsize=10m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=128m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m

Just ensure your wipe dalvik and cache when you apply these values!

Keep in mind that all devices use dalvik differently, for safety do not change your "dalvik.vm
heapsize=" below 512m as it can cause a bootloop unless your system has a vlue preset for you. Their are some cases when you need to alter your heap size depending on how you change your dalvik VM values

If your device has 3GB or higher ram your values.to get the best performance is show below:

dalvik.vm.heapstartsize=16m
dalvik.vm.heapgrowthlimit=256m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m

If your planning to alter the heap size ensure you have half of the heapsize given to the heapgrowthlimit for exampler 512m÷2=256m, 128m÷2=64m, 256m÷2=128m & 64m÷2=32m

Never give less or higher amounts of your heapsize to your heapgrowthlimit this can cause system instablilty

Here is a chart showing what heapsize your device(s) should have based on your device(s) ram:

Remember you can increase the heapstartsize to 16m if you wish the higher itis the better performance you will receive, but the con about this is you may run out of memory quicker then normal so we recommend not to go above 16m.

1). For devices with 1GB of RAM
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=128m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m

2). For device(s) with 2GB of RAM
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=128m
dalvik.vm.heapsize=256m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=2m
dalvik.vm.heapmaxfree=8m

3). For Devices with 3GB or higher or RAM
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=256m
dalvik.vm.heapsize=512m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m


Remember the more ram you have the higher the heapsize will be keep in mind not all device(s) with higher ram go above 512m do your research on your device if your device has more then 3GB to see if your heapsize is bigger then 512m.

Additional info:

For those who are wondering the difference between 512m & 512k is the 512m is bigger than 512k.

512k is similar to what 512m is, but the big difference is since 512k is not 512m it is measured in KB (Kilobytes) compared to 512m witch is measured by MB (Megabytes) the 512k value is only used in the heapminfree value witch declares how much free dalvik memory should be reserved if in case the space is needed, it can also be used in heapmaxfree as long as the value in heapminfree is NOT higher then what is placed in heapmaxfree
 
Last edited by a moderator:
  • Like
Reactions: MrJavi and ocnbrze
Are you sure about those configs? The way I've understood those parameters is as follows:
  • dalvik.vm.heapstartsize is the amount of RAM given to Dalvik/ART virtual machine for normal apps at the app start. If the app actually uses more than dalvik.vm.heaptargetutilization of the RAM, the heap size is increased during each GC (Garbage Collect) cycle. The dalvik.vm.heapgrowthlimit sets the maximum limit for the amount of RAM given to Dalvik/ART virtual machine for normal apps. If you set dalvik.vm.heapgrowthlimit too low, normal apps will be killed when the virtual machine runs out of memory. Setting dalvik.vm.heapgrowthlimit slightly too low causes apps to run slower than normal because GC cycles need to be too often. If you set dalvik.vm.heapgrowthlimit too high, the system can run only a few apps at once. Note that this may cause high battery drain because if your workload requires running total of 6 apps (e.g. you have multiple instant message apps running) but the system can only run 5 apps because you set dalvik.vm.heapgrowthlimit too high.
  • The dalvik.vm.heaptargetutilization setting also works the other way around. If an app uses less actual memory than dalvik.vm.heaptargetutilization times current heap size then Dalvik/ART will try to compress the memory and free some RAM. You can think dalvik.vm.heaptargetutilization as a setting how accurately the RAM should be used. If you set this to 0.25, you tell the system that up to 75% of RAM can be wasted as a tradeoff to reduce CPU usage. If you have a device where you have more CPU power than actual RAM, it might make sense to increase this setting.
  • The dalvik.vm.heapminfree setting defines minimum amount of RAM inside a virtual machine for each app regardless of dalvik.vm.heaptargetutilization. You can think this as amount of RAM that VM tries to keep free to be ready for any allocation in the near future. When app asks for more RAM, it will take RAM directly from this free memory block and continue processing if this block was big enough. The VM will increase up to dalvik.vm.heapgrowthlimit in the background to keep dalvik.vm.heapminfree free while the app keeps going if possible. Setting this too high will waste RAM all the time. Setting this too low will cause any RAM allocation to always ask for RAM from the linux kernel which is slower than using the preallocated block.
  • The dalvik.vm.heapmaxfree setting defines maximum amount of RAM inside a virtual machine for each app regardless of dalvik.vm.heaptargetutilization. You can think this as maximum amount of RAM that VM is wiling to waste at all times.
  • The dalvik.vm.heapsize is extra max limit for apps that are marked as Large in the app manifest.
 
Last edited:
Upvote 0
Are you sure about those configs? The way I've understood those parameters is as follows:
  • dalvik.vm.heapstartsize is the amount of RAM given to Dalvik/ART virtual machine for normal apps at the app start. If the app actually uses more than dalvik.vm.heaptargetutilization of the RAM, the heap size is increased during each GC (Garbage Collect) cycle. The dalvik.vm.heapgrowthlimit sets the maximum limit for the amount of RAM given to Dalvik/ART virtual machine for normal apps. If you set dalvik.vm.heapgrowthlimit too low, normal apps will be killed when the virtual machine runs out of memory. Setting dalvik.vm.heapgrowthlimit slightly too low causes apps to run slower than normal because GC cycles need to be too often. If you set dalvik.vm.heapgrowthlimit too high, the system can run only a few apps at once. Note that this may cause high battery drain because if your workload requires running total of 6 apps (e.g. you have multiple instant message apps running) but the system can only run 5 apps because you set dalvik.vm.heapgrowthlimit too high.
  • The dalvik.vm.heaptargetutilization setting also works the other way around. If an app uses less actual memory than dalvik.vm.heaptargetutilization times current heap size then Dalvik/ART will try to compress the memory and free some RAM. You can think dalvik.vm.heaptargetutilization as a setting how accurately the RAM should be used. If you set this to 0.25, you tell the system that up to 75% of RAM can be wasted as a tradeoff to reduce CPU usage. If you have a device where you have more CPU power than actual RAM, it might make sense to increase this setting.
  • The dalvik.vm.heapminfree setting defines minimum amount of RAM inside a virtual machine for each app regardless of dalvik.vm.heaptargetutilization. You can think this as amount of RAM that VM tries to keep free to be ready for any allocation in the near future. When app asks for more RAM, it will take RAM directly from this free memory block and continue processing if this block was big enough. The VM will increase up to dalvik.vm.heapgrowthlimit in the background to keep dalvik.vm.heapminfree free while the app keeps going if possible. Setting this too high will waste RAM all the time. Setting this too low will cause any RAM allocation to always ask for RAM from the linux kernel which is slower than using the preallocated block.
  • The dalvik.vm.heapmaxfree setting defines maximum amount of RAM inside a virtual machine for each app regardless of dalvik.vm.heaptargetutilization. You can think this as maximum amount of RAM that VM is wiling to waste at all times.
  • The dalvik.vm.heapsize is extra max limit for apps that are marked as Large in the app manifest.
You've understood by what others posted on xda etc I did a lot of testing with this and did my research properly to make this post
 
  • Like
Reactions: ocnbrze
Upvote 0
OP, you say you've done the research and that the first comment has merely "copied" XDA thread points, yet his comment made more sense and was more detailed than yours. Your post reads like you have little to no idea what these parameters actually do. And it's riddled with conflicting statements!

Like, don't set heapsize below 512 or it'll cause instabilities, then you go on to suggest low RAM devices can go ahead and use 128 or 256.

Your pasted values for 3gb or higher RAM devices aren't consistent, with heapstartsize set to 8m on one and 16 the other, why are they different if they're for the EXACT SAME 3GB+ devices???

Heaptargetutilization has ABSOLUTELY NOTHING to do with time delay. None at all. It clearly says it in the name itself that it is a TARGET UTILIZATION value, meaning a set defined value for a determination based on utilized memory, we are talking VM aren't we? As in VIRTUAL MEMORY, it's not called Virtual Time, is it? Any sort of delay or lack thereof would account for nothing in terms of performance.

Please just delete this post, for crying out loud. If you need to fulfill the urge to make yourself an authority for expertise in a subject you have no basis except for modifying build.prop on your friends 2016 Alcatel, do yourself a favor and spend the time actually researching the source code documents and man pages that currently exist and are accessible to anyone regarding VM and other GNU/Linux utilities and avoid posting this garbage misinformation.

Because as much as you meant well, this is just a poorly written collection of information that misleads and can further damage devices for those who are inpatient enough to apply these modifications without much thought or further research on the topic. Especially if you're gonna call out others for copy/posting from XDA when it is your very own post containing that characteristic.
 
Upvote 0
The member in question has left the forum permanently (that's what "deleted user" means, and why if you try to look for their profile you won't find anything). So I'm afraid that even if they do read your message they no longer have the ability to respond or do anything with their posts.
And to avoid further confusion, I'm closing this thread. :)

If anyone thinks there is a reason to reopen it, please send me a PM. :)
 
  • Like
Reactions: ocnbrze
Upvote 0
Status
Not open for further replies.

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones