Android RAM page size?

Question

I would like to optimize the reading of an InputStream, then I thought it would be nice to have a byte buffer [] with a RAM page size.

Is there a way (possibly static) to know its size?

EDIT:

Finally, I managed to use NDK and JNI, I wrote the following code in C:

#include <jni.h> #include <unistd.h> jlong Java_it_masmil_tests_TestsActivity_pageSize(JNIEnv* env, jobject javaThis) { return sysconf(_SC_PAGE_SIZE); } 

Where:

• it.masmil.tests is the name of the package
• TestsActivity is the name of the class.
• pageSize is the name of the method
• env and javaThis are two required parameters (useful in some cases)

I compiled this file with the NDK and then wrote the following code in Java:

 static { System.loadLibrary("clibrary"); } private native long pageSize(); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); long page = pageSize(); } 

Where:

• clibrary is the name of the library I created using the NDK
• pageSize is the name of the method declared in the C file

Answer 1

The page size is determined by Linux (the kernel), and you can get it through the JNI by calling libc ( bionic ) sysconf(_SC_PAGESIZE) . Since Android runs on Linux and mainly on ARM-systems, you can assume the size of 4 thousand pages.

 #include <unistd.h> long sz = sysconf(_SC_PAGESIZE); 

However, you cannot easily achieve such alignment from Java / C. Value, even if you request a 4k block, no one guarantees that it will be 4k aligned.

If you need a block with 4x alignment on Linux, you should use mmap , which is guaranteed to align to the size of the page.

Answer 2

You can usually assume that the page size is 4 KB or more (the MMU, which can handle smaller page sizes, has almost disappeared). Also, if you have no way to align the buffer to the exact page border, it will probably span two pages anyway.

Finally, all these efforts are completely lost - if the MMU suffers from one or two page skips, the actual cost of I / O will be overshadowed by many orders of magnitude. Its even unlikely that you can even recover the initialization value added, not to mention how much time you spent on its implementation.

You made a great example of over-optimization, you could spend all this time on a much higher income (for example) if you just profiled your application and shaved one or two cycles in the most commonly called method.

Answer 3

It's hard to believe that adding JNI, etc. really pay off the cost. Just use 4096 or 8192, like everyone else.