CODEWITHSUNDEEP
androiddalvik
Jon Shemitz
Jon Shemitz

Reputation: 1265

Get the loaded method count?

Dan Bornstein says

the bytecode instruction set doesn't have a way to refer to method numbers requiring more than 16 bits.

... which is a bit worrisome to anyone farting around with secondary dex loading because they're working on a big, sprawling app that hits the 64K methods per file limit. It sounds like, yes, you can have an app with hundreds of thousands of methods but that in doing so you've built a time bomb: sooner or later, some persistent user will exercise enough code paths that Dalvik loads enough classes that the loaded method count goes over 65,536, and your app will crash.

We are facing just this issue, and I've been asked to see if there is a way to find out how many methods have actually been loaded. I've poked around in the JavaDoc and done some Googling, and come up blank. Hence my question:

Is there any way to find out, at run time, how many methods have actually been loaded? (Without recompiling Dalvik to expose this info!)

Upvotes: 0

Views: 292

Answers (1)

fadden
fadden

Reputation: 52343

The 64K method limit isn't about how many methods are present in the VM at runtime. It's about how many methods are referenced within a single DEX file. Any failures due to excessive numbers of methods will happen during the "dx" conversion process.

(If you look at the bytecode format of the method invocation instructions, you'll see that they include a 16-bit index for the target method. This index is to a per-DEX-file table, not a VM-global table.)

The only relevant runtime limit is on the amount of memory required to store the metadata (vtables and such) for classes, fields, and methods. This is what Facebook hacked around to get their very large app working on older versions of Android.

Upvotes: 2

Related Questions