Live data from Hacker News

Dalvik patch for Facebook for Android

facebook.com

21–30 of 95 posts

Re: Dalvik patch for Facebook for Android

#21

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 wr…

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.

Re: Dalvik patch for Facebook for Android

#22
This seems like it will paint the Android core developers into a corner, supporting this particular hack for years to come, like the way Microsoft had to for Windows. If I were android core developers, this would not be a good day.

Re: Dalvik patch for Facebook for Android

#23
post #7

Earlier quoted context omitted.

I thought of that, then the pragmatic engineer in me observed that they only discovered this after cracking their app into so many small methods. Given the time choice of 1. uncracking their app into small methods (which presumably wasn't atomic, so now that's all mixed in with other development, so it's not like it can just be reverted) or 2. hacking the system to handle more methods, I am forced to admit that choic…

I think GP meant something like a build process that inlines the bytecode, not the source code itself. I don't see why this is unreasonable, especially compared to what they actually did.

For as nasty as the hack is, it still boils down to twiddling with a few numbers.

Also, inlining is probably easier said than done. It's not enough to inline the methods, you need to make them entirely disappear, and ISTR reading within the last few days somebody else commenting that Java still has to keep the metadata about the methods around (which is the problematic part, not the methods themselves, if I'm reading this right) because reflection may demand them. You'd need something more sophisticated to do it at the source level, and with an imperative language with unrestricted side effects, while that is certainly possible, it's also very much easier said than done. That's not a weekend hack either.

Re: Dalvik patch for Facebook for Android

#24
post #3

It's interesting to see the parallels between Android and Windows in this regard. Here's a story from my past, copied from a blog post I wrote last year: My first job at Microsoft was providing developer support for the early Windows SDKs. To do my job well, I spent hours studying the Windows SDK documentation, the Windows source code, and writing sample applications. I then spent hours poring over customers’ (such a…

Funny, mirror-image story. In the early 1990s I was writing utility software for Macintosh, then on the 68K platform. The utility basically had to patch the OS as it was running, a common practice back then. To figure out where to place the patches, I spent lots of time looking at disassembled 68K code in MacsBug, stepping through the OS as it ran.

One day, I was tracing through the OS code that handled a context switch and was surprised to find a bit of code that looked up the 32-bit creator code of the current application and compared it to 'WORD'. What the heck is this? I wondered. Turns out it was a hack added by the OS engineers at Apple to keep some other hacks in Microsoft Word working. If I recall correctly, they had to determine if Word was getting switched in or out so they could enable or disable the necessary hacks. So, in effect, they had a hack that would live-hack the OS to add hacks for Word's hacks and then live-unhack the hacks for everything else.

I mean, when you're hacking the system to hack the system on behalf of someone who already hacked the system but for an older version of the system that's no longer there, now you're doing some hacking.

Oh, yeah. And then I basically had to add my hacks to that mess.

Good times.

Re: Dalvik patch for Facebook for Android

#25
"choose between cutting significant features from the app or only shipping our new version to the newest Android phones (ICS and up)"

The ICS move wouldn't have been a bad option. It would've helped a lot of users convert to ICS+ devices, which Google probably would've loved.

The APIs from 4+ are much more robust than pre-ICS, and it probably would've saved more headaches while building the new version in addition to the one already described in the post.

Re: Dalvik patch for Facebook for Android

#26
post #22

This seems like it will paint the Android core developers into a corner, supporting this particular hack for years to come, like the way Microsoft had to for Windows. If I were android core developers, this would not be a good day.

I think the limitation is only on older versions, so they would probably only do the hack if it was pre Gingerbread. They mention that ICS works as expected, so I would be more than a bit mortified if they did this hack for new working versions too.

Re: Dalvik patch for Facebook for Android

#27

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 wr…

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.

Re: Dalvik patch for Facebook for Android

#28
post #22

This seems like it will paint the Android core developers into a corner, supporting this particular hack for years to come, like the way Microsoft had to for Windows. If I were android core developers, this would not be a good day.

This hack is specific to ancient versions of Android, and is not used on current or future versions. So there is no need to deal with it in any codebase that isn't completely dead.

Re: Dalvik patch for Facebook for Android

#29

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 wr…

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.

Re: Dalvik patch for Facebook for Android

#30
post #8

The first paragraph is just rampant self praise. Basically these engineers decided to be really clever, painted themselves into a corner, smashed a hole in the wall so as to escape from said corner, and then bragged about how great they are.

Welcome to Facebook engineering.
Post reply on HN