44

Does the Android ART runtime have the same method limit limitations as Dalvik? Currently, there's a limit of 64k methods in the primary dex file

Charles
  • 50,943
  • 13
  • 104
  • 142
ajma
  • 12,106
  • 12
  • 71
  • 90

2 Answers2

75

The issue is not with the Dalvik runtime nor the DEX file format, but with the current set of Dalvik instructions. Specifically, the various method invocation methods, which look like this:

invoke-kind {vC, vD, vE, vF, vG}, meth@BBBB

B: method reference index (16 bits)

You can reference a very large number of methods in a DEX file, but you can only invoke the first 65536, because that's all the room you have in the method invocation instruction.

I'd like to point out that the limitation is on the number of methods referenced, not the number of methods defined. If your DEX file has only a few methods, but together they call 70,000 different externally-defined methods, you're going to exceed the limit.

One way to fix this is to add additional instructions that take wider method references. An approach called "jumbo opcodes" was implemented and released in Android 4.0 (ICS), but was never fully put into action, and was later removed from the tree. (I occasionally see posts here with error messages from "dx" that reference jumbo ops, or from developers who stumbled over them.)

Note this is not the problem solved by the Facebook hack. That's due to a fixed-size buffer for holding class/method/field meta-data. There's no method-specific limit there; you can blow out the buffer by having lots of fields.

My understanding is that the current implementation of ART handles the same set of instructions that Dalvik does, so the situation will be no different.

Community
  • 1
  • 1
fadden
  • 51,356
  • 5
  • 116
  • 166
  • 1
    "but together they call 70,000 different externally-defined methods, you're going to exceed the limit" -- what qualifies as an "externally-defined method"? (Android framework classes? Anything else of note?). Thanks! – CommonsWare Jan 31 '14 at 23:58
  • 2
    I mean a method defined in a separate DEX file. For most apps this would just be framework and core library / uses-library stuff. FWIW, this is why splitting your DEX file in two with a multi-dex solution (http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html) doesn't leave you with two DEX files that each have exactly half the number of method references. – fadden Feb 01 '14 at 00:09
  • I did a quick patch a while back that converts the rather obscure "dexdeps" tool into a command-line utility for dumping the full set of external method references from a DEX file. You can find it at http://bigflake.com/0001-method-count.patch . No guarantees. :-) – fadden Feb 01 '14 at 00:13
  • 5
    I came across the same `dexdeps` tool and wrote a more complete `dex-method-counts` tool that uses it to output (per-package/class) method counts: https://github.com/mihaip/dex-method-counts – Mihai Parparita May 18 '14 at 22:51
  • 2
    @fadden You say that the limitation is not on the number of methods defined, yet if you take an empty Android project and add a class with 65536 empty methods and don't invoke any of those, you will still get the exception. Am I missing something or were you wrong to say that? – cdroid Oct 27 '14 at 13:24
  • ^^ said regardless of the actual 16 bit limitation with the argument of the invoke instructions. – cdroid Oct 27 '14 at 15:21
  • 2
    @cdroid Locally-defined methods are implicitly referenced whether or not they're invoked locally. I was trying to make the point that defining more than 64K methods in a single DEX wasn't the only path to failure. There can be some "dead space" in the table. (Vaguely related: at one point I tried to reduce the memory footprint of the VM's parallel resolved-entity table by "garbage collecting" the indices, but the results weren't good enough to merit the additional complexity. See the vast comments in https://android.googlesource.com/platform/dalvik/+/froyo/vm/analysis/ReduceConstants.c .) – fadden Oct 27 '14 at 16:14
  • 1
    Has anything changed in the last 4 years? – Dima Tisnek Jun 14 '18 at 01:10
5

Anwar Ghuloum told in this Android Developers Backstage episode that they're not going to fix the bytecode in the near future.
Instead, starting from Android L they will natively support multi-dex by collapsing all the dex files (from an APK) into a single oat file.

Alex Lipov
  • 13,503
  • 5
  • 64
  • 87