Hacker News new | past | comments | ask | show | jobs | submit login

It's way more fucked up than that, Dalvik is limited to 65k invocable methods per dex file: https://medium.com/@rotxed/dex-skys-the-limit-no-65k-methods...

> 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.

> […] 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.




I have seen some big, important commercial products run up against this limit, but in all the cases I have seen, architectural and implementation approach alternatives that would not approach this limit would have resulted in better outcomes for both users and developers.

I can also understand why Google has to be responsive to developers who hit this limit. But if you are stating from a clean sheet, there's no reason to come close to having this bite you in the ass.


Is this limitation going away (or otherwise obviated) by ART?


Yes, but not just yet:

https://plus.google.com/107130354111162483072/posts/VEy3JChn...

Mentioned at about 27:55 in this podcast where a member of the ART team is interviewed: http://androidbackstage.blogspot.se/2014/08/android-develope...


You're talking about a similar but different issue: there's a fixed-size meta-information buffer, if you go above you crash. Increase the size of the buffer and you're good to go (which is what more recent android versions have done), the new ART might make the buffer dynamic instead of static (no idea).

The 65k method problem is a problem of the dex format itself, because method-invocation instructions take "the method" as a 16-bit index, it can't be fixed by the runtime, the dex format has to be changed to fix it (either by adding new opcodes or by changing existing ones).


I think you are mistaken - in the audio: http://storage.googleapis.com/androiddevelopers/android_deve...

Around 27:55 they discuss that they plan on lifting the limit. Indeed modifying the dex format is talked about and it is mentioned that it is a future goal.

They also speak about multidex, the interim backwards compatible fix which does not require modifying the dex format (but uses a hack) and will make modifying the dex format easier in the future.


> I think you are mistaken

The question was whether ART would fix the issue. The answer is not "yes but not yet", it's "no" because the runtime has no bearing on the issue.


Just so you know, your link lead to a 404


No it's not - the limitation is part of DEX file format (it only has 16-bit method counter). ART is a runtime which runs these DEX files so it can't help there.

To change this, Google would have to update the file format and somehow ensure dual format compatibility when running.


the article linked in parent addresses that directly:

> And yes, you got it right. This issue won’t disappear even when Android will switch to the new ART runtime, unless Google decides to “fix” the DEX format or ditch it for another one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: