<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks Thomas,<br>
<br>
do you want me to attach the complete gc logfile to the bug?<br>
<br>
Thanks and Regards<br>
<br>
Thomas <br>
<br>
<br>
<div class="moz-cite-prefix">On 02/11/15 13:43, Thomas Schatzl
wrote:<br>
</div>
<blockquote cite="mid:1423658587.3514.13.camel@oracle.com"
type="cite">
<pre wrap="">Hi,
On Mon, 2015-02-09 at 12:41 +0100, Thomas Viessmann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">many thanks for your detailed explanation. Here are some more details
about the background. It seems that a humongous allocation triggers a
(long) evacuation pause although the eden is still (almost) empty.
Such long pauses could only be observed during a humongous allocation.
</pre>
</blockquote>
<pre wrap="">
In the case shown by the gc log snippet, the explanation is that G1
tries to start the concurrent cycle as soon as the occupancy in the old
gen reaches the threshold. It checks the threshold every time a
humongous allocation is done.
I.e. this works as implemented.
The cause for the long pauses seems to be a huge amount of reference
changes before allocating the humongous object (the large amount of
_pending_cards and the long update rs pause).
I do not know why particularly before humongous object allocation this
amount of pending cards is so high. There are two possibilities:
- it seems to be the application doing a large amount of reference
changes just before allocating that new large object; in the normal case
(ie. when reaching a young gc when it is full) this number may have
always been reduced by concurrent background activity to some manageable
amount.
- if that initial mark young gc happens right after a (final) mixed gc,
this would explain the high amount of pending cards too.
The single GC log entry does not give enough information to rule out
either of these options.
I created JDK-8072920 to record this problem.
</pre>
<blockquote type="cite">
<pre wrap="">Here is an example from the gc.log
173913.719: [G1Ergonomics (Concurrent Cycles) request concurrent
cycle initiation, reason: occupancy higher than threshold, occupancy:
11710496768 bytes, allocation request: 33554448 bytes, threshold:
</pre>
</blockquote>
<pre wrap="">
Side note: This large object is exactly 32M + 16 bytes (i.e. object
header) large. This means that this object actually requires 64M on the
heap. Maybe the application could be improved for that.
As for fixes/workaround for this problem assuming that I am correct
about the situation:
I do not think increasing the region size to 64M helps because the same
situation can occur for 64M humongous objects too. I am of course not
sure if the application ever tries to allocate 64M objects. Also, even
with a 64M region size, your 32M+16 byte object is still considered
humongous (i.e. the application would require 128M regions).
In case these pending cards originate from a preceding mixed young gc,
then a solution would be to increase the IHOP. I.e. give the background
processing more time between the last mixed gc and that forced initial
mark to process them to a useful level. I do not know if increasing IHOP
is acceptable in this situation.
If the application causes so many pending cards just before humongous
object allocation, I do not see a good way to prevent this occurrence
right now. Maybe somebody else has some idea.
>From the log snippet I also saw that the application is running with a
JDK7 build. 8u40's early reclaim may allow the application to have more
free space in general, doing less marking cycles (but the problem may
still occur in the current configuration).
Thanks,
Thomas
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<a href="http://www.oracle.com" target="_blank"><img
style="border: 0px solid ; width: 114px; height: 26px;"
src="cid:part1.09010504.04090206@oracle.com" alt="Oracle"></a><br>
<font face="Verdana, Arial, Helvetica, sans-serif" color="#666666"
size="2">THOMAS VIESSMANN | Senior Principal Technical Support
Engineer - Java<br>
Phone: <a href="tel:+49814302496">+498914302496</a> | Mobile: <a
href="tel:+491743005467">+491743005467</a> <br>
<font color="#ff0000">Oracle</font> Customer Technical Support -
Java<br>
<br>
ORACLE Deutschland B.V. & Co. KG | Riesstr.25 | D-80992
Muenchen </font><br>
<br>
<font face="Verdana, Arial, Helvetica, sans-serif" color="#666666"
size="1">ORACLE Deutschland B.V. & Co. KG<br>
Hauptverwaltung: Riesstr. 25, D-80992 Muenchen<br>
Registergericht: Amtsgericht Muenchen, HRA 95603<br>
Geschäftsführere: Juergen Kunz<br>
<br>
Komplementärin: ORACLE Deutschland Verwaltung B.V.<br>
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande<br>
Handelsregister der Handelskammer Midden-Niederlande, Nr.
30143697<br>
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher<br>
</font>
<br>
<hr>
<hr>
<a href="http://www.oracle.com/commitment" target="_blank"><img
style="border: 0px solid ; width: 44px; height: 28px;"
src="cid:part5.09000902.05090606@oracle.com" alt="Green
Oracle" align="middle"></a>
<font face="Verdana, Arial, Helvetica, sans-serif" color="#4b7d42"
size="1">Oracle is committed to developing practices and
products that help protect the environment</font>
<!-- This signature was generated by the MyDesktop Oracle Business Signature utility version 3.8.6 -->
</div>
</body>
</html>