basic GC question related with String objects

[krislioe]

Hi All,

As we know, dynamic String assigment will cause ineffecient resources
usage, eg :

String sample1 = new String(“Builder.com”);
sample1 += “ is “;
sample1 += “the place “;
sample1 += “to be.”;

There are 4 objects created while only one needed for use.

The question is :

When is the 3 unused objects will be garbage collected ?

Is this the case that will cause GC done often ? and resulting to high
CPU utilization (99.9 %)

Thank you for youe help,
xtanto

 

[Arne Vajhøj]

As we know, dynamic String assigment will cause ineffecient resources
usage, eg :

String sample1 = new String(“Builder.com”);
sample1 += “ is “;
sample1 += “the place “;
sample1 += “to be.”;

There are 4 objects created while only one needed for use.

The question is :

When is the 3 unused objects will be garbage collected ?

Whenever the GC is told to free some memory by the JVM.

Is this the case that will cause GC done often ?

Dot it once: no. Do it a trillion times: yes.

and resulting to high
CPU utilization (99.9 %)

Not for long.

Arne

 

[krislioe]

When is the 3 unused objects will be garbage collected ?

Whenever the GC is told to free some memory by the JVM.
Dot it once: no. Do it a trillion times: yes.
Not for long.

Hi,
Thank you for your reply.

So, if we suffer from CPU utilization (99.9 %), quite long, most of
the time, the application is still running, and when user number get
more & more, the application gets very slowly, that we have to restart
the application server.

Beside the String concatenation, what could possibly cause the that
High CPU usage ??

Can it be because we allocate 3GB for Heap memory causing the CPU more
busy to do the GC ?

Thank you very much,
xtanto

 

[Arne Vajhøj]

So, if we suffer from CPU utilization (99.9 %), quite long, most of
the time, the application is still running, and when user number get
more & more, the application gets very slowly, that we have to restart
the application server.

Beside the String concatenation, what could possibly cause the that
High CPU usage ??

Can it be because we allocate 3GB for Heap memory causing the CPU more
busy to do the GC ?

Are you sure that the stuff running is not just CPU intensive ?

(besides creating objects for GC the code you posted also moved
data around)

Arne

 

[Lew]

Hi All,

As we know, dynamic String assigment will cause ineffecient resources
usage, eg :

String sample1 = new String(“Builder.comâ€);
sample1 += “ is “;
sample1 += “the place “;
sample1 += “to be.â€;

There are 4 objects created while only one needed for use.

The question is :

The String constants will be interned into the constant pool, and likely never
GCed.

However, the concatenation could be Hotspot-optimized into something very fast
and compact, maybe, just possibly.

 

[Roedy Green]

String sample1 = new String(“Builder.com”);
sample1 += “ is “;
sample1 += “the place “;
sample1 += “to be.”;

There are 4 objects created while only one needed for use.

The question is :

When is the 3 unused objects will be garbage collected ?

have a look at the generated code. You may be surprised.

see http://mindprod.com/jgloss/decompiler.html
http://mindprod.com/jgloss/disassember.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

We are almost certainly going to miss our [global warming] deadline.
We cannot get the 10 lost years back, and by the time a new global agreement to
replace the Kyoto accord is negotiated and put into effect, there will probably
not be enough time left to stop the warming short of the point where we must not
go. ~ Gwynne Dyer

 

[Roedy Green]

When is the 3 unused objects will be garbage collected ?

See http://mindprod.com/jgloss/garbagecollection.html

garbage collection won't happen until space gets tight.
--
Roedy Green Canadian Mind Products
http://mindprod.com

We are almost certainly going to miss our [global warming] deadline.
We cannot get the 10 lost years back, and by the time a new global agreement to
replace the Kyoto accord is negotiated and put into effect, there will probably
not be enough time left to stop the warming short of the point where we must not
go. ~ Gwynne Dyer

 

[krislioe]

Are you sure that the stuff running is not just CPU intensive ?

(besides creating objects for GC the code you posted also moved
data around)

Hi Mr Arne,

The code I paste is not actual code that run in the apps server, that
is the simplified form.
(it is 150 - 200 user at peak load)

Btw, I notice in the console, there are 3 times of GC in 5 minutes,
before : 2800MB, after 1000-1750 MB.
Could this cause the CPU utilization ?

Will it help if I add more Heap (4000MB) ? or will it cause CPU work
harder if more heap ?

Thank you,
xtanto

 

[Daniel Pitts]

Hi Mr Arne,

The code I paste is not actual code that run in the apps server, that
is the simplified form.
(it is 150 - 200 user at peak load)

Btw, I notice in the console, there are 3 times of GC in 5 minutes,
before : 2800MB, after 1000-1750 MB.
Could this cause the CPU utilization ?

Will it help if I add more Heap (4000MB) ? or will it cause CPU work
harder if more heap ?

Thank you,
xtanto

More heap may increase the amount of time between GCs, but may make GCs
more expensive (therefor less optimal)

You *must* use a profiler to determine what the problem is before you
start making guesses. You wouldn't want a surgeon saying "Okay, lets
try removing your liver and see if that helps." Don't tweak until you
know where the problem is.

 

[Arne Vajhøj]

The code I paste is not actual code that run in the apps server, that
is the simplified form.
(it is 150 - 200 user at peak load)

Btw, I notice in the console, there are 3 times of GC in 5 minutes,
before : 2800MB, after 1000-1750 MB.
Could this cause the CPU utilization ?

Will it help if I add more Heap (4000MB) ? or will it cause CPU work
harder if more heap ?

It is impossible to analyze what causes your high CPU utilization
based on the information we have.

You need to investigate it systematically and test various
solutions systematically.

More heap will usually just make the GC run at longer intervals
but take more time when it runs.

But note that there are plenty of options to control how GC runs.

Arne

 

[Arne Vajhøj]

The String constants will be interned into the constant pool, and likely
never GCed.

I don't think they are included in the 4.

However, the concatenation could be Hotspot-optimized into something
very fast and compact, maybe, just possibly.

Absolutely. Performance is in many cases implementation specific.

Arne

 

[Lew]

Where the heck did these quote marks come from?

“ and †are not ". Surely these lines raised a compiler error, or is there
some syntactic Java magic of which I'm not aware? The JLS (Section 3.10.5)
specifies:

StringLiteral:
" StringCharacters opt "

No mention of left-double-quote or right-double-quote at all.

I don't think they are included in the 4.

I never said they were. I also didn't originally comment on the bizarre quote
marks.

There isn't justification for saying the statement sequence would generate
four objects. On first glance, it seems as though there might be eight String
objects in that statement sequence, though our comments /infra/ show how that
might also be inaccurate. There might be five String objects and one
StringBuilder, where the interned String objects might be implemented as
pointers into a long 'char' array with associated lengths, and the resultant
'String' might be a pointer into that selfsame 'char' array with its
associated length. My main point was:

 

[Wojtek]

Lew wrote :

Where the heck did these quote marks come from?

Some Microsoft product being friendly and so changing things IT
believes are correct.

 

[Arne Vajhøj]

Where the heck did these quote marks come from?

“ and †are not ".

They were in the original post.

Surely these lines raised a compiler error, or is
there some syntactic Java magic of which I'm not aware? The JLS
(Section 3.10.5) specifies:

StringLiteral:
" StringCharacters opt "

No mention of left-double-quote or right-double-quote at all.

I think most people figured out what it meant.

Including you in your first post.

I never said they were.

Fair enough.

There isn't justification for saying the statement sequence would
generate four objects. On first glance, it seems as though there might
be eight String objects in that statement sequence, though our comments
/infra/ show how that might also be inaccurate. There might be five
String objects and one StringBuilder, where the interned String objects
might be implemented as pointers into a long 'char' array with
associated lengths, and the resultant 'String' might be a pointer into
that selfsame 'char' array with its associated length.

I would expect 4 objects to be created from that code.

And javap -c | grep init says that the code makes 4 constructor
calls.

Arne

 

[Lew]

They were in the original post.

Actually, I double-checked the original post, from which I copy-and-paste again:

String sample1 = new String(“Builder.comâ€);
sample1 += “ is “;
sample1 += “the place “;
sample1 += “to be.â€;

Still not regular quotes.

OP:

Arne:
I would expect 4 objects to be created from that code.

And javap -c | grep init says that the code makes 4 constructor
calls.

The String literals count as objects, too.

They just aren't constructed via constructor calls, being constants.

OK, I'm splitting hairs on the difference between "created" and "constructed",
I admit.