Handling of String objects in java is different from other objects. JVM does this to improve the performence.
If u create a String as String s = new String("Hello"); then it creates a new String object and it is no way different from the other objects with respect to GC.
But if u create String like String S = "Hello"; Then the handling will be different. JVM checks weather this string already exists in the String pool(don worry. i'll explain). if it doesn't exists then it will create a new String object entry in the String pool and assign that reference to the reference S. now if u execute something like String S1 = "Hello"; it doesn't create new String object, it will assign the already created objects reference to S1. means both S and S1 are pointing to same object.
Now comming to GC, it won't garbage collect the oject even both S and S1 are out of scope. u can that object will be garbage collected only when JVM shutsdown. Now u can say String pool is a place holder for the String objects.
I hope it cleared some of ur doubts... if u still have a doubt, am ready to explain it further...
It sounds to me like your question is kind of security oriented. Is this correct?
If you program in C, memory that's been allocated and then freed will still hold its data until it's used again.
Here's a scenario where this could be useful... some program is running on your machine with sensitive information. You want to find out some of this information, so you allocate a big chunk of memory and then scan the memory for strings. You *might* be able to get some of the data in the memory that was freed by the other program, if the OS gives you a chunk of memory that was previously used by that program.
Is this what you are asking about, but in Java?
Joined: Mar 13, 2004
Your right, this is about security. I have a password that is in a String. The String is created with new, so it is an object. The String is global, so it is on the heap. Once the class the String is in goes out of scope, the String is eligible for gc. I was wondering if the password text would be erased in memory when it is gc.
My questions are: Using the Sun 5.0 JVM, will this String be erased when it is gc, like with the generation and compacting algorithms which I believe are default gc for that JVM?
How often will the gc run? The class I have the password doesnt last long, so I believe this is sent to the youth generation gc.
There is quite a lot of misinformation in this thread so far - I urge you (the OP) to ignore it for fear of being misled.
Having recently worked for IBM Tivoli (security) and also on the Java/JCE implementation, there was some heated debate about your exact issue and my position remains unmoved - that there is no value whatsoever in attempting to "erase memory" in a Java context. If anything at all, it opens the potential for exploitation. In short, the best case scenario is nil value and the worst case scenario is adverse consequences (less than nil value).
I'll omit the contents of the debate since it is quite lengthy, but if you wish to pursue the matter, it would first help if you truly understood the garbage collector and how it relates to Strings first - I will explain this if you like, but be aware that you will likely have to abandon a lot of what you have taken as face value (Ernest usually pipes up when a newbie is being led into falsehood - where is he?).
Uh oh, Tony. Is what I said about memory allocation and freeing in C inaccurate?
I'm not at all challenging you if so; actually, I'd like to know so that I can learn something if I've made a mistake.
Joined: Sep 24, 2003
Hello Bryan, Here are some comments that are blatantly incorrect:
Then the handling will be different. JVM checks weather this string already exists in the String pool(don worry. i'll explain). if it doesn't exists then it will create a new String object entry in the String pool and assign that reference to the reference S.
the answer would be: that's not specified, and as such vm-implementation dependent.
GC just collects the memory for reuse but I do not think it will earse any things in the memory.
I don't think there is much point debating what is correct in C in the given context, so I won't contest what you have said anyway.
The premise for the OP is that there is sensitive data. There are two points at hand. One is how the garbage collector behaves with respect to this data. The other point - which may or may not be related to how the garbage collector behaves - is related to the protection of that sensitive data. The assumption that the garbage collector is in some way related to the actual objective (protection of sensitive data) is an understandable mistake by the OP, but it can be covered anyway (as it has been done many times before on this forum with diminishing amount of error).