The android documentation for the java.lang.Runtime class makes multiple reference to the JVM, for example calling the freeMemory() method:
Returns the amount of free memory in the Java Virtual Machine.
Yet in recent versions of android there is no virtual machine. What exactly does this method, and other similar methods, return?
If I'm not mistaken, this is what gets call at the platform level from the Runtime::freememory() method: https://android.googlesource.com/platform/art/+/refs/tags/android-9.0.0_r51/openjdkjvm/OpenjdkJvm.cc#297 which then calls https://android.googlesource.com/platform/art/+/refs/tags/android-9.0.0_r51/runtime/gc/heap.h#548.
You can keep digging if you want to get to the very bottom of it, but it seems the ART is trying to provide a valid value to the calling app.
Related
I have a C shared library that is used from a Java application via JNI. I need to store some expensive-to-calculate data which will be valid for the lifespan of a JavaVM. I would like to store this in a static variable in C, so that it gets calculated exactly once.
Of course, this will fail if it is possible for my library to be used from multiple JavaVMs in the same process. My static values would only be valid in the first JavaVM. If my library is being loaded from Java via System.loadLibrary in a static block on a class, is it ever possible for said library to be used across multiple JavaVMs without having to completely unload my C shared library?
Yes. Most popular JVM implementations, in particular, HotSpot JVM and its derivatives, allow only one Java Virtual Machine per process.
In fact, an implementation allowing multiple VMs in one process, will not be compliant with the JNI specification, as the documentation to JNI_CreateJavaVM and JNI_GetCreatedJavaVMs explicitly says that
Creation of multiple VMs in a single process is not supported.
I am new to Java & JNI. This question maybe very newbe. I have C++ library and Java application which interns call the C++ function using JNI concepts.
As per my understanding, JVM loads the C++ dll/SO in JVM space before calling a native function call.
If my understanding on the JVM is correct on JNI. Can someone tell me which/who is going to execute the C++ library function which is loaded inside the JVM.
Let say for C++, there is standard dynamic linker-loader present to handling the dynamic execution part of the C++ and executes all the machine instructions.
In case of JVM loaded JNI Libs (in this case C++ libs), does JVM executes the those libs ? If so does it uses its memory to execute the native function?
Thanks in advance.
The Java language allows you to mark certain methods as native. The Java Native Interface allows you to link these Java methods to a function address in native code.
When you System.loadLibrary a library that contains native code, the JVM will do two things:
Look for specifically named functions such as Java_pkg_Cls_f_ILjava_lang_String_2 and link this to the function f in class pkg.Cls.
Call JNI_OnLoad, if it exists in the library. This can perform initialization and optionally link more native methods using registerNatives.
After this point, the native library indeed resides in the process' memory space like any other library (say, libcurl or libssl). When you actually call one of the native methods, the JVM will find the function address and use a native call instruction to jump into the function. The function will execute as part of the stack trace of that thread and will show up as such in both the JVM and native stack traces.
In more advanced cases, the library might spawn additional native threads. These work like regular threads in native code and are invisible to the JVM. If these threads need to talk to the JVM as well, the developer can attach them.
My app users can change app language from app's setting page so I developed it with Resources.updateConfiguration() and Context.createConfigurationContext() (For deprecating). However almost developer used with Locale.setDefault() but I don't know why. My app can support multi language without Locale.setDefault(). I read document, but it seems like too dangerous. Is changing JVM's locale safe for system settings or other app? What is changing JVM locale for? And I think it's enough that using Resource.updateConfiguration() and Context.createConfigurationContext() but why developers use Locale.setDefault() method?
I assume that "safe" means "does not affect other apps"
As far as I know android starts a new JVM instance for every started apk/app. Hence Locale.setDefault() should not influence other android apks/apps. So it should be safe.
I have done it here and saw no effects on other apps.
According to Locale.setDefault() documentation. What setDefault() does is that it
Sets the default locale for this instance of the Java Virtual Machine.
This does not affect the host locale.
The host locale here references the Android OS locale. And the Java Virtual Machine (JVM) instance would translate into an Android Runtime (ART) instance in Android terms, with this information we can deduce that since each Android application process runs its own independent ART instance, it means that setDefault() would only affect that one Android app process, and not the whole OS, or any other app process.
I'm using a library that calls the JNI_CreateJavaVM function inside the library code. However, I also need some JNI Wrappings and I need to call the same function JNI_CreateJavaVM to get the JNIEnv* to my application.
But the second call is failing.
is there any way to do this?
The library does not support getting or setting the JNIEnv* created inside the library.
You cannot create more than one JVM from the same process:
As of JDK/JRE 1.2 , creation of multiple VMs in a single process is not supported.
You may be able to attach your current thread to the existing JVM though using AttachCurrentThread function. See the docs for the Invocation API. The equivalent document in Java 15 simply states:
Creation of multiple VMs in a single process is not supported.
You will need a pointer to the JavaVM object. See if JNI_GetCreatedJavaVMs() can help you, I'm not sure if this is per-process (in which case it will only ever be a single element list) or per machine. In either case the JavaVM will have to be the one that the library is using or you probably will not be doing what you want. If you can access that then you should be able to make invocations on other objects in your Java application, but make sure that it is thread-safe.
Is there any way to find that a specific object is still in the memory or not? For example I have a JFrame called GuiSearch. When I called some method it will be disposed. I want to find is it still in the memory or disposed. I am new to java. Please help me.
Edit: What I want to do is find that the specific object is still in the memory or not and if it is in the memory, I want to call a method and if it is not, call another method.
I assume disposed cleans up resources hidden by the object.
As long as you have a reference to it, the object is still in memory. Depending on what disposed does, you could have an object which is "disposed" and still in be memory as you still have a reference to it.
I am assuming you want to do this for debugging and not via the code. If that's the case, what you want to is dump the heap memory and check it via tools such as Eclipse Memory Analyzer.
This is a bad programming practice and you never do it. To see objects in memory you can use jvisualvm - which comes Sun JDK it self. This provides a visual interface for viewing detailed information about Java application while they are running on a Java Virtual Machine.