4 ms·

According to http://techcrunch.com/2013/03/04/facebook-google-dalvik/ http://techcrunch.com/2013/03/04/facebook-google-dalvik/ and http://venturebeat.com/2013/0

According to http://techcrunch.com/2013/03/04/facebook-google-dalvik/ http://techcrunch.com/2013/03/04/facebook-google-dalvik/ and http://venturebeat.com/2013/03/04/google-facebook-android/ 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.

pbiggar 14y ago
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.
zenocon 14y ago
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.
- fidotron 14y ago
  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.
  - Slizyboy 14y ago
    Thrift isn't used on the mobile apps, it is meant (and used for) communication between different services in their backend.
georgemcbay 14y ago
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.
- Xuzz 14y ago
  I think the actual number is 65536 or similar — the 3 million may have been a misquote by TechCrunch.
  - georgemcbay 14y ago
    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.
    - cpeterso 14y ago
      Trivial getters and setters shouldn't be a problem because the Facebook blog said they tried using ProGuard, which can inline Java methods.
- gubatron 14y ago
  I bet that having so many methods makes it impossible for them to reuse their methods, probably they have a shitload of repetition in there. I just can't stop laughing about these arrogant people, and the balls to think that no other developers have had their challenges. Must be hell working in that place.
mborsuk 14y ago
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 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 https://code.google.com/p/android/issues/detail?id=22586
smrtinsert 14y ago
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?

pbiggar 14y ago

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.

zenocon 14y ago

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.

fidotron 14y ago
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.
- Slizyboy 14y ago
  Thrift isn't used on the mobile apps, it is meant (and used for) communication between different services in their backend.

georgemcbay 14y ago

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.

Xuzz 14y ago
I think the actual number is 65536 or similar — the 3 million may have been a misquote by TechCrunch.
- georgemcbay 14y ago
  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.
  - cpeterso 14y ago
    Trivial getters and setters shouldn't be a problem because the Facebook blog said they tried using ProGuard, which can inline Java methods.
gubatron 14y ago
I bet that having so many methods makes it impossible for them to reuse their methods, probably they have a shitload of repetition in there. I just can't stop laughing about these arrogant people, and the balls to think that no other developers have had their challenges. Must be hell working in that place.

mborsuk 14y ago

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 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 https://code.google.com/p/android/issues/detail?id=22586

smrtinsert 14y ago

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?