Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dalvik patch for Facebook for Android

facebook.com

Post reply on HN
Print view View original

91–95 of 95 posts

Re: Dalvik patch for Facebook for Android

#91

Post by aredington »

ajtaylor wrote: post #15

I can't tell if I should be excited for the developers to have been so clever, or horrified with all the hacks they had to incorporate to make it work. Either way, the new FB app is definitely an improvement over the older version (lag central!). Is it reasonable for the OS to make such a low-level component configurable so this type of convolutions aren't required?

You should be angry that they have managed to persuade you that theirs was the only way out. The odds that properly modularizing their source tree such that they didn't provoke the limitations of the VM they were running on was impossible are vanishingly small, and the odds that they correctly hacked the VM are also vanishingly small.

Facebook's Android Engineers chose the ego stroking solution which involved clever hacks. This only reinforces my being happy to have uninstalled the FB android app 2 years ago.

Re: Dalvik patch for Facebook for Android

#92

Post by klewelling »

navpatel wrote: post #18

This issue has been a colossal pain in the ass! I need this! Are they planning on releasing this code to replace the buffer?

I am working on a product that may solve this problem for you. The product is designed for a different purpose but it should work for you as well. The only caveat would be the need to break your app into multiple pieces that run in separate processes. Give me a shout at kenneth@inappsquared.com if you are interested.

Re: Dalvik patch for Facebook for Android

#93

Post by MichaelGG »

zurn wrote: post #52
MichaelGG wrote: post #43

Earlier quoted context omitted.

For a shipped app it shouldn't be too hard to perform it across all packages involved, right?

The compiler would have to see all code that is linked with the app, including the Android runtime that calls into the app's code in various ways. In Java land these kinds of fancy optimizations usually happen in the JVM JIT at runtime. Would this help the size of those tables in Android's Dalvik/dexopt setup? In any case you can't ship a custom version of Dalvik with your app.

Maybe I'm not explaining well.

You've got class foo, with methods "DoBar" which calls "DoBazStep1(), DoBazStep2(), SomeHelper.CalcPosition()".

You use a Java bytecode toolkit and identify leaf functions, small functions, whatever the criteria needs to be. Then you check every callsite for those functions, and if found, remove the call, and inline the code, doing fixup on locals and parameters. Now, "DoBar" has a lot more bytecode in it, as the bodies of DoBazStep1 and the others are now contained in it. The small functions are completely removed.

This process can be done totally offline, on the compiled Java code. The runtime just sees that you wrote one big function, versus a bunch of small ones.

The only real work is making sure you got everything, and perhaps being clever with stack local allocations. As the FB team says they moved to a new style with lots of small functions, I'm assuming they aren't doing all sorts of metaprogramming and inheritance, but have just split things up at the function level.

Re: Dalvik patch for Facebook for Android

#94

Post by AnthonyMouse »

simula67 wrote: post #90
AnthonyMouse wrote: post #45

Earlier quoted context omitted.

>What if Y is closed-source? What if source for Y is not available for some other reason? What if your patch breaks Y's behavior on other platforms? Advantages of open source may not apply to closed source.

OK, let me elaborate. Unless you believe all software must be open source ( which is hopelessly unrealistic ) the question becomes how we can bring about most openness. Surely, closed software on an open platform is better than open software on a closed platform? But to do stuff like this takes a lot of resources. Group of volunteers may not have the resources to do so on their spare time. So we may all be better off…

Let's put aside that what you're saying is a red herring. (RedHat makes a lot of money and to do it they pay professionals to develop free and open source software. Samsung, Intel, Google, IBM and Oracle make a lot of money and to do it they pay professionals to develop free and open source software. "Open source running on open source" is entirely practical and just because closed source software exists doesn't mean you can't refrain from using it, see Debian et al.)

But let's address the original point. Suppose I want to run Steam on Linux. Some bug in Steam requires me to put an ugly hack in the kernel to address it. +1 ugly hack in the kernel, the same as it would be on Windows. Meanwhile in a hundred other cases where the thing with the bug was open source, I can fix it on the other end and it doesn't require an ugly hack to be put in the kernel. So the Linux kernel gets one ugly hack while the Windows kernel gets a hundred and one.

It doesn't stop being an advantage just because there are exceptions to the rule.

Re: Dalvik patch for Facebook for Android

#95

Post by anyfoo »

barbs wrote: post #13

I really love reading recounts like this. Seeing other developers try, fail, and try again to come up with creative solutions for difficult problems, and then finally arriving at a solution, is so satisfying. It really demonstrates how creativity is manifested in programming, and is truly inspiring. A favourite of mine is Jari Komppa's article on his process of porting Death Rally from DOS to Windows: http://sol.gfxi…

Thanks, that was indeed a great read. You might also enjoy this, which is fairly recent: http://fabiensanglard.net/duke3d/index.php

And the article links to other promising articles at the top, though I haven't checked them out.

The general question remains: how would we go about finding similar stuff?

Oh, one more thing, if you don't know yet, you will find great gems in Raymond Chen's blog, http://blogs.msdn.com/b/oldnewthing/

Not everything is archeological (a lot is still interesting though), but the articles often link to a whole bunch of other articles, which in turn do the same. I suggest, for example, http://blogs.msdn.com/b/oldnewthing/archive/2012/06/29/10325... . I deliberately chose a later article in the series, since it also links to previous ones.

Post reply on HN