It also doesn't decompress all the bytes properly, but this is on purpose to gain speed, on average the decompression mangles about 1% of the file contents while gaining 3% of speed. You can even gain up to 7% of speed if you're OK with the decompression overwriting some parts of some near-by files, to enable this pass the "elephant-in-the-vessel-store" option. But since the project is in alpha the numbers aren't final yet.
Why backport btrfs features to ext4 when you could just work on getting btrfs mainstream-ready? (yeah, I know Android would never switch filesystem at this point). Also, I'm curious why Android isn't looking at f2fs considering Samsungs work to make it really good for the kind of internal flash phones use.
ehhhh it may have its uses, but modifying the kernel for your user app? really?
I don't have statistics, but I'd wager that the greater bulk of kernel contributions are made with specific use cases as the primary motivator. I don't think that just because this particular one targets improved performance for a single app makes it any less legitimate a reason for the work. This work has the potential to benefit a great deal more use cases than just the one that is trying to be improved through this effort.
UPX compresses executable binaries.
So UPX would be good, for example, to compress "/usr/bin/firefox" (or "/usr/libexec/firefox-bin", depending on your distro ;-) )
This is used to compress dynamically loaded libraries (.so files), which is not and can't be supported by UPX (due to the way libraries are loaded).
So this would be good, for exemple to compress "/usr/lib64/xulrunner/libxul.so"
Think of it as a UPX-for-SO-files, which need to be put into the kernel so it intercepts the necessary hooks.
(Like UPX, and unlike BTRFS' various Zlib/LZO/LZ4 compressors, files need to be compressed in advance offline
Also the decompression happens at a very last step in the file system when the .so file is being streamed into memory. It doesn't work with memory maps or seeks.
Only this time the decompressor is in the filesystem module and not embed inside the so-file (like upx on elfs) because that simply is technically impossible).
Note that, on windows, UPX *IS* able to compress DLL files, because they function completely differently.
(They are basically just a different type of executable, the same PE/COFF format as used in the .EXE files, and are loaded and executed the same).