Proposal to set dalvik-vm optimizing all code

Search This thread

hunderteins

Senior Member
Sep 7, 2009
192
349
dalvik.vm.dexopt-flags=v=n,o=a,u=y,m=y (testing now with register optimization)

I thought m=y has only an effect when v=a. There is a comment in analysis/DexOptimize.h that says "generate register maps during verify".

Evertheless I've found another problem with optimized dalvik-cache. The app Privacy Inspector sometimes goes down with the error: "This dex file has a link section, which is not supported". But Privacy Inspector was never really stable, so this could have nothing to do with o=a.
 
  • Like
Reactions: alispeedsport

_n0p_

Senior Member
Apr 9, 2009
2,560
1,833
47
Kyiv
n0p.8bit.fm
hunderteins, you're right. Setting v=a results in failing cache build. I wonder will we benefit from register mapping?
 

sinan33

Senior Member
Mar 29, 2010
680
143
Tarsus
@Hunderteins
These settings make the DS5 works faster but after applying these settings some applications don't able to see superuser and can't get root permissions (like Lucky Patcher,Titanium Backup...)
 
  • Like
Reactions: hunderteins

hunderteins

Senior Member
Sep 7, 2009
192
349
@Hunderteins
These settings make the DS5 works faster but after applying these settings some applications don't able to see superuser and can't get root permissions (like Lucky Patcher,Titanium Backup...)

I can confrm this for LuckyPatcher. Also adbWireless is not using root anymore. On the other hand DroidWall is working with su/root.
 

_n0p_

Senior Member
Apr 9, 2009
2,560
1,833
47
Kyiv
n0p.8bit.fm
I didn't succeed so far with reodexing framework, and i'm just dying to try register maps. If anyone remembers old Mophun VM for SE T300/310/610 - it was really fast, and I suggest it was using similar techniques (but C language might be better optimized comparing to Java).
 

hunderteins

Senior Member
Sep 7, 2009
192
349
turned verify on, didn't took longer to boot

LuckyPatcher and other programs have a problem with optimized dalvik-cache for classes that aren't verified. So I set up

dalvik.vm.dexopt-flags=v=a,o=v,u=y,m=y

it is like: verify=all dexopt=verified uniprocessor=yes registermaps=yes

Now LuckyPatcher works again, the boot takes not really more time, cache-size is the same as before and this uses register mapping. I'll give it a try a week or two.

have a nice weekend,
hunderteins
 

_n0p_

Senior Member
Apr 9, 2009
2,560
1,833
47
Kyiv
n0p.8bit.fm
Impressive

128-1344, ondemand.
 

Attachments

  • shot_000035-1.jpg
    shot_000035-1.jpg
    53 KB · Views: 762

_n0p_

Senior Member
Apr 9, 2009
2,560
1,833
47
Kyiv
n0p.8bit.fm
Quite simple.
Code:
 #CPU
echo "conservative" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 70 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/up_threshold
echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/down_threshold
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_down_factor
echo 128000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
#echo 245760 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 998400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/freq_step
in postboot.

Change "conservative" to "ondemand", 998400 to 1344000.
Reboot.
Note that I personally find overclock more stable with undervoltage on.
Refer to Phoenix Universal kernel in DSC thread on enabling UV manually.
More, kernel sets high frequencies using 384 and 768 MHz as middle values, so it may be safe using ondemand - TPS chip should handle it.

Also, let's move this discussion elsewhere, as it's off topic here. Thank you.
 
Last edited:

sinan33

Senior Member
Mar 29, 2010
680
143
Tarsus
Quite simple.
Code:
 #CPU
echo "conservative" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 70 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/up_threshold
echo 30 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/down_threshold
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_rate
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/sampling_down_factor
echo 128000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
#echo 245760 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 998400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/conservative/freq_step
in build.prop.

Change "conservative" to "ondemand", 998400 to 1344000.
Reboot.
Note that I personally find overclock more stable with undervoltage on.
Refer to Phoenix Universal kernel in DSC thread on enabling UV manually.
More, kernel sets high frequencies using 384 and 768 MHz as middle values, so it may be safe using ondemand - TPS chip should handle it.

Also, let's move this discussion elsewhere, as it's off topic here. Thank you.

Thank you Sergei,i was using these settings :) Just changed 1267200 to 1344000 :)
 

(InsertNameHere)

Senior Member
Jan 11, 2010
997
319
LuckyPatcher and other programs have a problem with optimized dalvik-cache for classes that aren't verified. So I set up

dalvik.vm.dexopt-flags=v=a,o=v,u=y,m=y

it is like: verify=all dexopt=verified uniprocessor=yes registermaps=yes

Now LuckyPatcher works again, the boot takes not really more time, cache-size is the same as before and this uses register mapping. I'll give it a try a week or two.

have a nice weekend,
hunderteins

Thanks for all your work, is this now confirmed as a definitive tweak that doesn't break anything?
 
  • Like
Reactions: herc2k

Top Liked Posts

  • There are no posts matching your filters.
  • 8
    Hello,

    I played with the dalvik.vm.dexopt-flags in /system/build.prop. Basically you control the class-loading and dalvik-vm there.

    streakowner proposed in http://xdaforums.com/showpost.php?p=18111740&postcount=644 the setting v=n,o=v. But disabled this with #, in DSC v1.0 the setting is active.
    That means: do not verify and optimize mode verified. Found that info in dexopt/OptMain.c

    I did some performance measurement with smartbench 2011 and got the value 553 in the first round, and 465 in the second round. That is very bad for an one ghz powered device. Good would > 1000. /data/dalvik-cache takes 74 MiB with this setting.

    At the moment I'm running with

    dalvik.vm.dexopt-flags=v=n,o=a,u=y

    That means: do not verify, optimize all classes and optimize for uniprocessor.

    First I was not impressed, because rebooting with a cleaned dalvik-cache took more than double the time span of the o=v setting. logcat is full off lines telling me what can't be optimized and how much time the load took. But after booting I got the impression the system went faster. With smartbench 2011 I get the value 1036 in the first and 1110 in the second round. /data/dalvik-cache takes 74 MiB with this setting.

    Can someone confirm my finding?

    I don't say you will double the speed of the streak with this setting. But I think you will notice the change. The trade off is the time for the first boot. But I think that is worth is.
    So I propose to use the above setting in all gb-based roms for the streak 5.

    Have a nice weekend,
    hunderteins
    7
    turned verify on, didn't took longer to boot

    LuckyPatcher and other programs have a problem with optimized dalvik-cache for classes that aren't verified. So I set up

    dalvik.vm.dexopt-flags=v=a,o=v,u=y,m=y

    it is like: verify=all dexopt=verified uniprocessor=yes registermaps=yes

    Now LuckyPatcher works again, the boot takes not really more time, cache-size is the same as before and this uses register mapping. I'll give it a try a week or two.

    have a nice weekend,
    hunderteins
    4
    Tested on miui and it's not working i get into a boot loop.

    Ouch! Sorry to hear that. I hope you didn't get in serious trouble.

    getprop | grep dexopt
    [dalvik.vm.dexopt-flags]: [v=n,o=a,u=y]

    Well, same ~950 in Quadrant (CPU/mem only)

    998400

    Quadrant shows 1048 with o=a and 1065 with o=v. Thats not helping either. At least smartbench shows nearly the same "Games Index". But what do they test with ther productivity index? Calculating PI and mandelbrot is so different?
    And there is opera. Its definitly faster with o=a. I'll try to find a web page rendering test.

    o.k. I get more mixed signals here. Numion tells me that rendering a real world web-page is about 30% faster with o=a (10.5 vs. 14,6 sec). Scragz is 10 % slower with o=a ( 9.7 vs. 10.5 sec).

    I'll file it under works for me, but don't try this with miui. Thanks for your help.

    Reg. hunderteins
    3
    getprop | grep dexopt
    [dalvik.vm.dexopt-flags]: [v=n,o=a,u=y]

    Well, same ~950 in Quadrant (CPU/mem only)

    998400

    --
    Sergei.
    2
    It works with MIUI too but you have to delete the another line that contains

    dalvik.vm.dexopt-flags=m=y

    i guess this lines value is overlapping with the other lines "u=y" value.

    ---------- Post added at 08:11 AM ---------- Previous post was at 08:03 AM ----------

    The result of first test is:
    Productivity index=716
    Gaming index=981

    with smart bench 2012

    ---------- Post added at 08:20 AM ---------- Previous post was at 08:11 AM ----------

    The result of second test is:

    Productivity index=1074
    Gaming index=1569

    with smart bench 2011

    Ok so i need to change only the entry dalvik.vm.dexopt-flags. Below is my buildprop part where the dalvik entries are so just confirm as to what all needs to be changed

    #streakOwner's recommended
    dalvik.vm.startheapsize=48m
    dalvik.vm.heapsize=48m
    dalvik.vm.execution-mode=int:jit
    dalvik.vm.dexopt-flags=v=n,o=v
    dalvik.vm.dexopt-data-only=1
    dalvik.vm.lockprof.threshold=150
    davlik.vm.verify-bytecode=false
    ro.android.kernel.checkjni=0
    #wifi.supplicant_scan_interval=120
    windowsmgr.max_events_per_sec=80
    keyguard.no_require_sim=true