Is Dalvik's Memory Model the Same as Java'S

Is Dalvik's memory model the same as Java's?

As of 4.0 (Ice Cream Sandwich), Dalvik's behavior should match up with JSR-133 (the Java Memory Model).

As of 3.0 (Honeycomb), most of the pieces were in place, but some minor things had been overlooked that would be difficult to encounter in practice (e.g. some edge cases in finalization).

As of 2.3 (Gingerbread), Dalvik was generally correct on uniprocessors, but some key features required for proper behavior on SMP hardware (e.g. proper final field handling) was missing.

Pre-Gingerbread, there were no memory barriers at all, and basic stuff like volatile long was broken.

What is Dalvik and dalvik-cache?

Dalvik is the virtual machine that is used by Android. It is generally thought of as a Java virtual machine, although this is not precisely correct. It uses an object model that is identical to Java, and its memory model is also nearly equivalent. But the dalvik VM is a register based VM, as opposed to Java VMs, which are stack based.

Accordingly, it uses a completely different bytecode than Java. However, the Android SDK includes the dx tool to translate Java bytecode to dalvik bytecode, which is why you are able to write Android applications in Java.

When you say "dalvik-cache", I assume you mean the /data/dalvik-cache directory that can be found on typical Android devices. When you install an application on Android, it performs some modifications and optimizations on that application's dex file (the file that contains all the dalvik bytecode for the application). It then caches the resulting odex (optimized dex) file in the /data/dalvik-cache directory, so that it doesn't have to perform the optimization process every time it loads an application.

Kotlin versus android java in terms of working on Dalvik VM

Kotlin compiles to Java bytecode, and for the purposes of Android, the .class outputs of both of these compilers are transformed to .dex files in the same way, at that point in the process, their source languages are completely irrelevant.

Here is a part of a talk by Jake Wharton where he explains the intricacies of actually resolving references so that interop can work both ways between Java and Kotlin, for example.

a compiler that compiles down to dalvik bytecode?

It seems that the only way to write an android app is by using java

You are welcome to use C/C++ as well.

Apps run in a virtual machine called the "dalvik virtual machine"

Only on Android 4.4 and older. Newer devices use a new runtime environment called ART.

then wouldn't it be possible to create a C/C++ (or any other compiled language for that matter) compiler that can compile down to dalvik bytecode?

Can you craft other languages that compile to Dalvik bytecode? Sure. Can you compile some existing language to Dalvik bytecode? Only if the language features of that language can be implemented (reasonably) in Dalvik bytecode.

Finding the memory address of a Java local variable on the Dalvik Stack from native code

It looks like you're trying to open /proc/[pid]/task/[tid]/maps, walk through the map, and manually scan through every address range for a magic number. Setting aside the fact that you're opening the task directory rather than the maps magic file in that directory, this approach has a few problems:

1. You're not guaranteed that the value is unique. If it appears somewhere else in memory -- perhaps because the value was stored in two different Dalvik registers -- you'll be in the wrong place. If the JIT compiler has compiled this stretch of code, you don't know if the "active" value will be on the managed stack or in a spilled register on the native stack.
2. You're searching for 0x14, which isn't part of your magic number.
3. You're scanning for the local variable on the thread that created it. Even if you find it and can change it, once the findMagicNumber method returns, the stack-allocated variable will disappear. It's not guaranteed to be in the same place if the method is called again.
4. If you were hoping to find related variables nearby, you will again have trouble if the JIT compiler rearranges things.
5. ART compiles almost everything ahead of time, so this is even less likely to be useful there.

I'm also not sure why you're calling mprotect(), rather than simply skipping the segments that aren't readable. You're forcing the permissions to read-only, disabling write and execute permission, which will cause you to crash when execute permission is disabled for the chunk of code that's executing, or when a thread tries to execute and touches its stack.

The access() system call takes a filename, not a memory address, and reports file permissions. I don't think there's an "is this address valid" call, but since you just sscanf'ed the map entry you shouldn't need one.

The only reliable way to find and change the value of a local variable is to use the JDWP debug interface. The compiler and debugger support work together to make reliable read-write access to local variables possible.

To sum up: the code is seriously broken, the approach is unsound. What problem are you trying to solve?

Dalvik and out-of-order writes

The Dalvik interpreter does not reorder anything. The JIT compiler might.

Where things really get wacky is on devices with multiple CPUs, because the ARM memory consistency model is pretty weak. In such an environment you could observe out-of-order memory accesses even with just the interpreter.

If the JSR-133 (JMM) docs say you can't rely on something, don't rely on it. :-)

android dalvik memory limit? out-of-memory exception

5M of vertex data is quite a lot for a mobile environment. If you are also loading textures, consider loading only compressed textures. You can also free some resources once they have been moved to the GPU driver. I would prepare your vertex data offline and only load the required data during runtime. Another option is to compute part of the data, or expand it directly at the vertex/fragment shaders (for example generate bitangents at GPU side).

---

Related Topics