<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 06/06/2017 11:17 PM, Kirk Pepperdine
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:C4891B4A-BA72-4844-93FB-2DDCC84306E8@kodewerk.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite"
cite="mid:7C8B47AA-21B2-4253-90F5-96EAE8CA4574@kodewerk.com"
class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite"
cite="mid:05FF4DD7-5C2A-4061-AD55-E7AB30FAE1C1@kodewerk.com"
class="">
<div class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF"
class=""> <br class="">
<a class="issue-link"
data-issue-key="JDK-8043575"
href="https://bugs.openjdk.java.net/browse/JDK-8043575"
id="key-val" rel="4726783"
moz-do-not-send="true">JDK-8043575</a>
is proposing to dynamically switch
between MT and single thread. And
there are other CRs to enhance
references processing.<br class="">
I have a prototype but need more
refining. Please keep on eye on this
if you are interested. (Thanks,
Aleksey for the link at the other
email thread)<br class="">
<br class="">
[1]: e.g. Most of Specjvm2008
sub-tests don't use references. Derby
is exceptional case that shows over
12k FinalReferences. So single thread
is faster except Derby case.<br
class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
SpecJVM doesn’t represent the real world. </div>
</blockquote>
Absolutely!<br class="">
I was trying to answer the reason why
ParallelRefProcEnabled is set to false as a
default.<br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
I got that.. I was trying to suggest that basing this
decision on that benchmark isn’t a great idea.</div>
</blockquote>
Probably my explanation was incomplete.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
I think we’re talking past each other, my apologies for being a
bit too terse. </div>
</blockquote>
It was same here.. :)<br>
<br>
<blockquote type="cite"
cite="mid:C4891B4A-BA72-4844-93FB-2DDCC84306E8@kodewerk.com">
<div>The referenced bug report seems to cover all of my concerns.</div>
</blockquote>
Good to hear the CR would cover your concerns.<br>
<br>
<blockquote type="cite"
cite="mid:C4891B4A-BA72-4844-93FB-2DDCC84306E8@kodewerk.com">
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
ParallelRefProcEnabled command-line option was introduced
long time ago with false as a default. And my previous
answer with Specjvm2008 was my guess from recent data when
I investigated JDK-8043575. I was saying if we don't have
enough references to process, single thread is better
choice. So this could be the reason of current default
value. Or my guess would be simply wrong. :)<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
Right, hence my comment that SpecJVM isn’t a great benchmark as
it doesn’t represent enterprise applications and hence has
nothing useful to say about reference processing which is
commonly seen in enterprise applications.</div>
</blockquote>
Yes, SpecJVM doesn't represent enterprise applications.<br>
<br>
I was trying to say that MTness of reference processing is mostly
affected by the total of references. But saying the benchmark name
made a noise.<br>
JDK-8043575 is mostly about dynamically choosing MTness for
reference processing. Focusing on the switch(turn on/off the
option), any applications that showing several aspects(many
references, limited references etc..) seem okay to me. In my case,
as SpecJVM2008-Derby has many final references(over 12k), my
prototype should show almost same result as "baseline,
+ParallelRefProcEnabled". And for other sub-tests of SpecJVM2008, my
prototype should show almost same as "baseline,
-ParallelRefProcEnabled" because with limited references, single
thread shows better results.<br>
<br>
Initially I worked with micro-benchmark but I also wanted to test
with known benchmark as well. <br>
Hope this explains why I used SpecJVM2008.<br>
<br>
<blockquote type="cite"
cite="mid:C4891B4A-BA72-4844-93FB-2DDCC84306E8@kodewerk.com">
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> <br
class="">
Probably you are saying that we have to use other
benchmarks to decide the default value.<br class="">
May I ask what is your recommendation for the benchmarks?<br
class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
I don’t have a specific benchmark for this. I’m relying on
observations made from customer’s applications. I don’t know if
the SPEC application server benchmark addresses this question.
I’ve not run it in quite some time so I don’t recall. At any
rate, it is very clear that real world applications use many
frameworks that rely heavily on the use of reference types. For
example, Hibernate with secondary caching turned on. CMS is
sensitive but the G1’s remark phase appears to be exceptionally
sensitive to the amount of references it processes. I’ve
attached a pause time and G1 breakout of the other phases that
is very typical of what I’m seeing.</div>
</blockquote>
Thank you for the attachments.<br>
I will analyze a bit more.<br>
<br>
Thanks,<br>
Sangheon<br>
<br>
<br>
<blockquote type="cite"
cite="mid:C4891B4A-BA72-4844-93FB-2DDCC84306E8@kodewerk.com">
<div><br class="">
</div>
<div>Kind regards,</div>
<div>Kirk</div>
<div><br class="">
</div>
<div><img apple-inline="yes"
id="039AD1BC-C4E4-4B1A-9049-73AD37B310CC"
src="cid:2DAE543A-624F-4806-A2C8-45CA1F9C5013" class=""
moz-do-not-send="true"></div>
<div><br class="">
</div>
<div><img apple-inline="yes"
id="6A180909-BEC0-436A-9D28-78B872764754"
src="cid:FBD9E14D-F619-4CD8-9B72-86BCAA342143" class=""
moz-do-not-send="true"></div>
<div><br class="">
</div>
</blockquote>
<br>
</body>
</html>