As we know, creating Java objects in a thread owned by C/C++ we are responsible to call DeleteLocalRef or Push/Pop LocalFrame as needed.
I have some code like
jbyteArray buffer = env->NewByteArray((jsize)requiredSize);
longTermBufferReference = (jbyteArray)env->NewGlobalRef(buffer);
where native code creates a byte array, which it re-uses across multiple threads/calls, once we are done with it, I call DeleteGlobalRef on the buffer.
The question is, must I call DeleteLocalRef on buffer when I'm done, or does the GlobalRef take complete ownership of the object?
In a garbage collected system, there is no such thing as object ownership. There are root object references and object references that are reachable directly or indirectly from the roots. (Weak references are not considered).
Both JNI local references and JNI global references are root references. Creating additional references does not affect existing references nor remove them from the list of root references.
So, yes, the local reference must be deleted (just as the global reference must be deleted). You already know that you can do it explicitly with DeleteLocalRef or PopLocalFrame, or, when a JNI native method returns, JNI effectively calls PopLocalFrame automatically.
To add to what #EJP has said: an object becomes eligible for garbage collection only when there are no (strong) references to it anymore. When you do NewGlobalRef you create a second reference to your object increasing the number of references to 2. The local reference will still be there.
It will be deleted by the runtime when your function exits, but suppose your function was a long one. If you called DeleteGlobalRef, you would delete the global reference, but the local reference would still be unaffected. Number of references: 1. Only after deleting this one too would the garbage collector be able to claim that object.
The question is, must I call DeleteLocalRef on buffer when I'm done
No, you can leave it to be deleted automatically when your JNI method returns, or by PopLocalFrame() if you use that. But local references are a scarce resource: if your JNI function uses a lot of them you should release them ASAP.
Related
I am a bit confused GC aspect when it comes to the instance variables, especially fields.
So, if an object holds references to its field objects, these won't be eligible for garbage collection until the object itself is. Since Threads are GC roots and every object must have been created on some Thread only, thread won't let go of any objects created on it and the entire object hierarchy from a Thread shall remain for a considerable time before getting garbage collected.
On the other hand, if an object lets go of the field objects, calling a getter for these objects will end up in returning null later.
So, what are the facts here?
Clarification for "field objects"(as asked in comments)
By field objects I mean, the field members of an object that are themselves objects
Edit 2: A bit more elaboration
So, you see Threads are execution units having representation in memory through the Thread object instance. Any code execution that is happening anywhere is happening on some Thread.
How would this execution happen?
Well, through the execution of some code in a method. What would that make this object created?
A Local variable
And, that would make it a GC root.
Btw, for a method call, there is a stack for that particular call and this is what I have been referring to here.
It ain't so simple as #louis-wasserman said - "Yes, naturally" or for that matter not that natural..(?)
I investigated some more and found the answer on...where you would expect it probably - Java Language Specification
2.7. Representation of Objects
The Java Virtual Machine does not mandate any particular internal
structure for objects.
In some of Oracle’s implementations of the Java Virtual Machine, a
reference to a class instance is a pointer to a handle that is itself
a pair of pointers: one to a table containing the methods of the
object and a pointer to the Class object that represents the type of
the object, and the other to the memory allocated from the heap for
the object data.
Yes, that settles it. Even though, JLS doesn't mandate on the internal structure of an java.lang.Object, it would be likely that a structure similar to Oracle's JVM might be used.
This has bigger implication that you might think. Imagine a very heavy object holding one very bulky member field object. Hmmm...a Bitmap maybe. A Bitmap of 10MB and the other object simply holds the image's title:
bulky_object = {bitmap, title}
If you create up this object as a local variable inside a method inside a nested scope(for example's sake), the container object is eligible for garbage collection after the scope gets over but if you decide to hold a reference to the bitmap(the field) object after the scope, the containing object won't have been collected fully:
void someMethod(){
// Outer block of the method
bitmap_ref;
// Nested block starts
{
some_object = new some_object();
// Hold a ref to the bitmap
bitmap_ref = some_object.bitmap;
}
// Nested block has ended. some_object is eligible for GC and is not accessible as a GC root
// anymore
// bitmap_ref shall remain available alive and well here as we are holding a ref to it
// Also, some_object garbage collection may have happened leaving bitmap_ref alive
}
This would seem like an object leak here.
I create a java object to query data from database. After I get the results and process then I no longer need the object. I also do not set the object reference to null in my code. Will Garbage collector considers this object for clean up? If the Garbage Collector do not clean up will this scenario create any kind of memory leak in the system?
We cannot tell with this much information.
If you have created a local variable, used it, and not done anything else with it, then it will be available for garbage collection as soon as it goes out of scope. If it's a variable within a method, for instance, then once the method returns, its reference is no longer counted as active by the garbage collector. (You could, of course, have another reference to the same object somewhere else).
If, on the other hand, you have an instance variable, then it will hold on to its object as long as that instance of that object is active. And, of course, if you have stored the reference in a static variable, then it is likely to just stay around as long as the program runs.
I encountered this question in an interview with following options:
How to destroy an object in java?
a. System.gc();
b. Runtime.getRuntime.gc();
c. object.delete();
d. object.finalize();
e. Java performs gc by itself, no need to do it manually.
The answer should be e?
what if e was not there? then ?
clearly c is not the answer. a and b will do gc for the whole application(question requires for one object).
I think it is d because finalize() is called just prior to gc(but is it necessary that after finalize gc is invoked ?) or I am wrong ? e must be there to answer this question ?
Answer E is correct answer. If E is not there, you will soon run out of memory (or) No correct answer.
Object should be unreachable to be eligible for GC. JVM will do multiple scans and moving objects from one generation to another generation to determine the eligibility of GC and frees the memory when the objects are not reachable.
To clarify why the other answers can not work:
System.gc() (along with Runtime.getRuntime().gc(), which does the exact same thing) hints that you want stuff destroyed. Vaguely. The JVM is free to ignore requests to run a GC cycle, if it doesn't see the need for one. Plus, unless you've nulled out all reachable references to the object, GC won't touch it anyway. So A and B are both disqualified.
Runtime.getRuntime.gc() is bad grammar. getRuntime is a function, not a variable; you need parentheses after it to call it. So B is double-disqualified.
Object has no delete method. So C is disqualified.
While Object does have a finalize method, it doesn't destroy anything. Only the garbage collector can actually delete an object. (And in many cases, they technically don't even bother to do that; they just don't copy it when they do the others, so it gets left behind.) All finalize does is give an object a chance to clean up before the JVM discards it. What's more, you should never ever be calling finalize directly. (As finalize is protected, the JVM won't let you call it on an arbitrary object anyway.) So D is disqualified.
Besides all that, object.doAnythingAtAllEvenCommitSuicide() requires that running code have a reference to object. That alone makes it "alive" and thus ineligible for garbage collection. So C and D are double-disqualified.
Short Answer - E
Answer isE given that the rest are plainly wrong, but ..
Long Answer - It isn't that simple; it depends ...
Simple fact is, the garbage collector may never decide to garbage collection every single object that is a viable candidate for collection, not unless memory pressure is extremely high. And then there is the fact that Java is just as susceptible to memory leaks as any other language, they are just harder to cause, and thus harder to find when you do cause them!
The following article has many good details on how memory management works and doesn't work and what gets take up by what. How generational Garbage Collectors work and Thanks for the Memory ( Understanding How the JVM uses Native Memory on Windows and Linux )
If you read the links, I think you will get the idea that memory management in Java isn't as simple as a multiple choice question.
Set to null. Then there are no references anymore and the object will become eligible for Garbage Collection. GC will automatically remove the object from the heap.
Here is the code:
public static void main(String argso[]) {
int big_array[] = new int[100000];
// Do some computations with big_array and get a result.
int result = compute(big_array);
// We no longer need big_array. It will get garbage collected when there
// are no more references to it. Since big_array is a local variable,
// it refers to the array until this method returns. But this method
// doesn't return. So we've got to explicitly get rid of the reference
// ourselves, so the garbage collector knows it can reclaim the array.
big_array = null;
// Loop forever, handling the user's input
for(;;) handle_input(result);
}
In java there is no explicit way doing garbage collection. The JVM itself runs some threads in the background checking for the objects that are not having any references which means all the ways through which we access the object are lost. On the other hand an object is also eligible for garbage collection if it runs out of scope that is the program in which we created the object is terminated or ended.
Coming to your question the method finalize is same as the destructor in C++. The finalize method is actually called just before the moment of clearing the object memory by the JVM. It is up to you to define the finalize method or not in your program. However if the garbage collection of the object is done after the program is terminated then the JVM will not invoke the finalize method which you defined in your program.
You might ask what is the use of finalize method?
For instance let us consider that you created an object which requires some
stream to external file and you explicitly defined a finalize method to this object which checks wether the stream opened to the file or not and if not it closes the stream. Suppose, after writing several lines of code you lost the reference to the object. Then it is eligible for garbage collection. When the JVM is about to free the space of your object the JVM just checks have you defined the finalize method or not and invokes the method so there is no risk of the opened stream. finalize method make the program risk free and more robust.
If I have a reference pointing to some some java object, and do something like:
myObject=null;
Will the "lost data" of the old object be correctly freed by the JVM Garbage Collector? Something similar in C (with a pointer, would result in trash and a possible memory leak).
I am using null attribution in a java program and would like to now if it is "safe".
If myObject only holds memory ( say large internal array ), then setting this reference to null is enough.
If, on the other hand, it holds some other kind of resource that you've allocated ( Closeable, Thread, ExecutorService, etc ), you must take care to properly shut down these resources.
Even though some of them may have finalize method they may be called too late ( or even never ) for your system to have a desirable effect.
It is a very common mistake for somebody switching from C++ to Java, and I am guilty as charged here. In my first real Java project I would periodically run out of file handle, because I was not calling close after being done with them. Needless to say with a 512MB heap, GC would never feel the need to start finalizing my IO objects before it was too late.
Assuming that there are no other references to the object, this is a good way to free memory up for the GC. (Actually, aside from weak references and the like, it's basically the only way: make the object unreachable from any live variables.) Note that there is no schedule for when an object might get garbage collected once it becomes unreachable.
EDIT: As others have pointed out, setting myObject to null is unnecessary if myObject is going out of scope anyway. When the variable itself is no longer available as a path to reach the object it references, then it doesn't matter to the GC system whether or not it contains a reference or null.
Your assumption is correct, but you don't usually need to specifically do that.
Let's say your "myObject" is used in another object. At some point in the lifetime of your application's execution, this object will stopped being referenced by any other object, and thus will be marked for deletion by the GC. Them myObject will be marked for deletion as well. As soon as all references to a given object disappear, the GC will eventually reclaim the memory.
There are (rare) exceptions, like event handling, where the dependency between two objects cannot be properly automatically ended, and you may end up with a memory leak: when you subscribe to an event on another class, then the subscriber cannot be collected even when there's no "direct" references to it. In that specific case, it might be interesting to clear the link manually.
Yes, that is the purpose of the garbage collector in the JVM. The JVM may at some later time call the finalize method of the object, and then it may discard the associated storage.
Yes, it's sometimes a GOOD idea to set Java object references (pointers) null. This may (if there are no other references to the object) "free" the object sooner than would otherwise occur. This is especially helpful when you have large "networks" of intertwined objects.
At worst case, you're costing one additional memory store.
Yes, The object the reference pointed to is eligible for garbage collection (if there are no other live references to the object) when:
The method returns - if it was initially created with method local scope
Immediately - if it is an instance or class variable
To implement a callback function from the native code to Java code, I have to create a global reference using NewGloabRef . From the memory profile , I found that ,once I called env->NewGlobalRef(weak_this), even it was a weak reference of the player object, the Player object will be available as Root Objects, which I think will prevent it from being garbage collected.
But my understanding is the weak reference won't prevent the object from garbage collected.
//java code
Player{
native_init(new WeakReference(this)),
}
//JNi code
//listener
Listener::Listener(jobject weak_this)
{
//will use mObject for callback
mObject = env->NewGlobalRef(weak_this);
}
xxxx_Player_native_init(xxxx. Object weak_this)
{
Listener l = new Listener(weak_this);
}
EDIT:
memory profile :
Root Object 0x2C820E10 <com/trident/tv/media/player/JniTPlayer>
com/trident/tv/media/player/JniTPlayer.trace : 0x2C83CC54 <java/lang/String>
com/trident/tv/media/player/JniTPlayer.listenerList : 0x2C820E64 <java/util/Vector>
log of JNI
[JNI] NewGlobalRef(0x2C820E10 [com/trident/tv/media/player/JniTPlayer]) : 0x2C820E10
A WeakReference is a Java object with an ordinary reference to it. It contains a reference to another object. It is the contained reference that is "weak", not the reference to the WeakReference itself.
So when you call env->NewGlobalRef(weak_this) (assuming weak_this is a WeakReference), the effect is the same as assigning weak_this to a static. It doesn't cause the object reference contained by the WeakReference to be strongly reachable.
I think you may be misinterpreting what the memory profiler is telling you. In particular, I would expect it to show the contained reference of a WeakReference to be reachable ... up until the GC decided to break the link. Try an experiment with an WeakReference in an ordinary static variable.
UPDATE
I'm starting to think that this is normal behaviour for JNI NewGlobalRef. The JNI documentation is (as always) very vague about the method's behaviour.
Note that there is also a JNI method called NewGlobalWeakRef; see http://java.sun.com/docs/books/jni/html/refs.html#27531. If nothing else, NewGlobalWeakRef provides an alternative way of doing what you are trying to do.