-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Balazs,
Balazs Michnay wrote:
> Somewhere I read that the GC can only collect objects that were
> instantiated with the "new" keyword.
That's an odd way of putting it. The garbage collector only works with
the heap. Since in Java nearly everything is on the heap (or, rather, it
appears that everything is on the heap, which is all you really need to
know), the garbage collector basically cleans up everything.
> Does it mean the the following two String creations differ when it
> comes to garbage collection?
>
> 1) String myString = "This is my string";
> 2) String myString = new String("This is my string");
>
> If the second one can only be garbage collected, this would explain
> my uncollectable char[] objects, because mostly I simply use the 1)
> version.
>
> If you say this really does count when it comes to garbage
> collection, I'd rewrite my code and see what happens.
Well, you're introduced an odd concept into the discussion: the Java
class file constant pool. When you compile a string into a class file
(in this case, "This is my string"), the compiler puts the UTF-8
representation of it into a part of the class file itself. When line 1
of your code executes, no constructor is called... the java bytecode
primitive "ldc" (load constant) is called which returns the String
object directly.
In the case of line #2, a new String object is allocated, the constant
is loaded, and then the constructor String.<init>(String) is called.
You can see this yourself by compiling this simple class and then
decompiling it:
$ cat StringTest.java
public class StringTest
{
public void s1()
{
String s1 = "This is a String";
}
public void s2()
{
String s2 = new String("This is a String");
}
}
$ javac StringTest.java
$ javap -c StringTest
Compiled from "StringTest.java"
public class StringTest extends java.lang.Object{
public StringTest();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public void s1();
Code:
0: ldc #2; //String This is a String
2: astore_1
3: return
public void s2();
Code:
0: new #3; //class java/lang/String
3: dup
4: ldc #2; //String This is a String
6: invokespecial #4; //Method
java/lang/String."<init>":(Ljava/lang/String;)V
9: astore_1
10: return
}
In the examples you have given, I'm not entirely sure what the role of
the GC is when it comes to constants loaded from the constant pool. The
class file format contains only the UTF-8 representation of the String,
so at some point a String object /must/ be constructed in memory. You'd
have to do some more research into the JVM specification to see how
constant Strings are handled.
You probably shouldn't have lots of string constants that contain a
/lot/ of text. Maybe 400 characters or so ought to be fine (say, a
semi-complex SQL query), but if you are talking about tons of text, you
might want to read that kind of thing out of a file.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGf73U9CaO5/Lv0PARAvsGAJ97ZDUpN4bhtfjE1w+/sm8tNxYp6gCgtxGt
CCIkTDuPsGGgMFmYfnh5nz0=
=DdN4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
