Hacker News Reader

Comment by jmillikin | Hacker News Reader

According to http://techcrunch.com/2013/03/04/facebook-google-dalvik/ and http://venturebeat.com/2013/03/04/google-facebook-android/ , the specific limit being hit was a cap of three million methods per instance of the Dalvik VM.

Wisdom of a three-million-method app aside, I wonder why they didn't fix this in the compilation toolchain rather than by poking around in native memory areas during app startup. Facebook wrote a PHP->C++ compiler; changing the Dalvik compiler to more aggressively inline small methods seems trivial in comparison.

View on HN

I'll just paste the same thing here that I wrote in response to commenters on FB misunderstanding the problem:

"Even though I disagree with most of your comments (to the extent that it is any more than unrelated editorializing) and everyone talking about "too many methods" etc, the actual bug that was triggered is here and provides a test case: https://code.google.com/p/android/issues/detail?id=22586 showing that multiple interface inheritance triggers this easily."

Issue 22586 - android - Dexopt fails with "LinearAlloc exceeded" for deep interface hierarchies

https://code.google.com/p/android/issues/detail?id=22586

They mention in the article that they tried.

I have a small background in static analysis of Java, and between reflection, the class loader, and the huge amount of polymorphism that you find in java, it is very very difficult to inline basically anything statically.

Three million methods? Having both programmed for Android and having used the Facebook App for Android, I find it very difficult to believe that app has anywhere near 3 million methods, even if each one is basically a one-liner. If the number is correct, that really is some kind of crazytown code.

I think the actual number is 65536 or similar — the 3 million may have been a misquote by TechCrunch.

Still seems like a ridiculous number, though of course far less ridiculous especially for Java code with its legacy of setters and getters for even basic properties and FactoryOfFactoriesFactory classes.

Trivial getters and setters shouldn't be a problem because the Facebook blog said they tried using ProGuard, which can inline Java methods.

I really can't fathom how, Facebook (the mobile / client app) could be made up of 3 million methods. That's an enormous amount of code -- none of it adds up.

It's probably Thrift. It generates absolutely incredible amounts of code for even relatively small pieces of data. Quite unsuitable for the purpose of mobile dev.

Thrift isn't used on the mobile apps, it is meant (and used for) communication between different services in their backend.

iirc, one the primary reasons they they wrote the compiler was to not have to deal with legacy php code. Is this some sort of pattern at FB? If the code doesn't work, let's fix the OS/compiler instead?

Reply on news.ycombinator.com