<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Peter,<div><br></div><div>Interesting email. I think it is a thoughtful contribution and these are great responses to concerns and questions. I hope it receives the due consideration it deserves.</div><div><br></div><div>Kind regards,</div><div>Kirk</div><div><br><div><div>On May 31, 2015, at 9:32 PM, Peter Levart <<a href="mailto:peter.levart@gmail.com">peter.levart@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div style="background-color: rgb(255, 255, 255);" bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
Thanks for views and opinions. I'll try to confront them in-line...<br>
<br>
<div class="moz-cite-prefix">On 05/29/2015 04:18 AM, David Holmes
wrote:<br>
</div>
<blockquote cite="mid:5567CC5E.7000102@oracle.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->Hi
Peter, <br>
<br>
I guess I'm very concerned about the premise that finalization
should scale to millions of objects and be performed highly
concurrently. To me that's sending the wrong message about
finalization. It also isn't the most effective use of cpu
resources - most people would want to do useful work on most cpu's
most of the time. <br>
<br>
Cheers, <br>
David <br>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
@David<br>
<br>
Ok, fair enough. It shouldn't be necessary to scale finalization to
millions of objects and be performed concurrently. Normal programs
don't need this. But there is a diagnostic command being developed
at this moment that displays the finalization queue. The utility of
such command, as I understand, is precisely to display when the
finalization thread can not cope and Finalizer(s) accumulate. So
there must be that some hypothetical programs (ab)use finalization
or are buggy (deadlock) so that the queue builds up. To diagnose
this, a diagnostic command is helpful. To fix it, one has to fix the
code. But what if the problem is not that much about the
allocation/death rate of finalizable instances then it is about the
heavy code of finalize() methods of those instances. I agree that
such programs have a smell and should be rewritten to not use
finalization but other means of cleanup such as multiple threads
removing WeakReferences from the queue for example or something
completely different and not based on Reference(s). But wouldn't it
be nice if one could simply set a system property for the max.
number of threads processing Finalizer(s)?<br>
<br>
I have prepared an improved variant of the prototype that employs a
single ReferenceHandler thread and adds a ForkJoinPool that by
default has a single worker thread which replaces the single
finalization thread. So by default, no more threads are used than
currently. If one wants (s)he can increase the concurrency of
finalization with a system property.<br>
<br>
I have also improved the benchmarks that now focus on CPU overhead
when processing references at more typical rates, rather than
maximum throughput. They show that all changes taken together
practically half the CPU time overhead of the finalization
processing. So freed CPU time can be used for more useful work. I
have also benchmarked the typical asynchronous WeakReference
processing scenario where one thread removes enqueued WeakReferences
from the queue. Results show about 25% decrease of CPU time
overhead.<br>
<br>
Why does the prototype reduce more overhead for finalization than
WeakReference processing? The main improvement in the change is the
use of multiple doubly-linked lists for registration of Finalizer(s)
and the use of lock-less algorithm for the lists. The WeakReference
processing benchmark also uses such lists internally to handle
registration/deregistration of WeakReferences so that the impact of
this part is minimal and the difference of processing overheads
between original and changed JDK code more obvious. (De)registration
of Finalizer(s) OTOH is part of JDK infrastructure, so the
improvement to registration list(s) also shows in the results. The
results of WeakReferece processing benchmark also indicate that
reverting to the use of a single finalization thread that just
removes Finalizer(s) from the ReferenceQueue could lower the
overhead even a bit further, but then it would not be possible to
leverage FJ pool to simply configure the parallelism of
finalization. If parallel processing of Finalizer(s) is an
undesirable feature, I could restore the single finalization thread
and the CPU overhead of finalization would be reduced to about 40%
of current overhead with just the changes to data structures.<br>
<br>
So, for the curious, here's the improved prototype:<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.02/">http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/webrev.02/</a><br>
<br>
And here are the improved benchmarks (with some results inline):<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/refproc/">http://cr.openjdk.java.net/~plevart/misc/JEP132/ReferenceHandling/refproc/</a><br>
<br>
<br>
The benchmark results in the ThroughputBench.java show the output of
the test(s) when run with the Linux "time" command which shows the
elapsed real time and the consumed user and system CPU times. I
think this is relevant for measuring CPU overhead.<br>
<br>
So my question is: Is it or is it not desirable to have a
configurable means to parallelize the finalization processing? The
reduction of CPU overhead of infrastructure code should always be
desirable, right?<br>
<br>
<div class="moz-cite-prefix">On 05/29/2015 05:57 AM, Kirk Pepperdine
wrote:<br>
</div>
<blockquote cite="mid:8DBC7345-09D8-458F-9017-298D1E620F86@gmail.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<pre wrap="">Hi Peter,
It is a very interesting proposal but to further David’s comments, the life-cycle costs of reference objects is horrendous of which the actual process of finalizing an object is only a fraction of that total cost. Unfortunately your micro-benchmark only focuses on one aspect of that cost. In other words, it isn’t very representative of a real concern. In the real world the finalizer *must compete with mutator threads and since F-J is an “all threads on deck” implementation, it doesn’t play well with others. It creates a “tragedy of the commons”. That is situations where everyone behaves rationally with a common resource but to the detriment of the whole group”. In short, parallelizing (F-Jing) *everything* in an application is simply not a good idea. We do not live in an infinite compute environment which means to have to consider the impact of our actions to the entire group.</pre>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
@Kirk<br>
<br>
I changed the prototype to only use a single FJ thread by default
(configurable with a system property). Lowering the CPU overhead of
finalizer processing for 50% is also an improvement. I'm still
keeping finalization FJ-pool for now because it is more scaleable
and has less overhead than a solution with multiple threads removing
references from the same ReferenceQueue. This happens when the
FJ-pool is configured with > 1 parallelism or when user code
calls Runtime.runFinalization() that translates to
ForkJoinPool.awaitQuiescence() which lends the calling thread to
help the poll execute the tasks.<br>
<br>
<blockquote cite="mid:8DBC7345-09D8-458F-9017-298D1E620F86@gmail.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<pre wrap="">This was one of the points of my recent article in Java Magazine which I wrote to try to counter some of the rhetoric I was hearing in conference about the universal benefits of being able easily parallelize streams in Java 8. Yes, I agree it’s a great feature but it must be used with discretion. Case in point. After I finished writing the article, I started running into a couple of early adopters that had swallowed the parallel message whole indiscriminately parallelizing all of their streams. As you can imagine, they were quite surprised by the results and quickly worked to de-parallelize *all* of the streams in the application.
To add some ability to parallelize the handling of reference objects seems like a good idea if you are collecting large numbers of reference objects (>10,000 per GC cycle). However if you are collecting large numbers of reference objects you’re most likely doing something else wrong. IME, finalization is extremely useful but really only for a limited number of use cases and none of them (to date) have resulted in the app burning through 1000s of final objects / sec.
It would be interesting to know why why you picked on this particular issue.</pre>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
Well, JEP-132 was filed by Oracle, so I thought I'll try to tackle
some of it's goals. I think I at least showed that the VM part of
reference handling is mostly not the performance problem (if there
is a problem at all), but the Java side could be modernized a bit.<br>
<br>
<blockquote cite="mid:8DBC7345-09D8-458F-9017-298D1E620F86@gmail.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<pre wrap="">Kind regards,
Kirk
</pre>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
<div class="moz-cite-prefix">On 05/29/2015 07:20 PM, Rezaei,
Mohammad A. wrote:<br>
</div>
<blockquote cite="mid:6882C9A35DFB9B4FA2779F7BF5B9757D20761169A2@GSCMAMP06EX.firmwide.corp.gs.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<pre wrap="">For what it's worth, I fully agree with David and Kirk around finalization not necessarily needing this treatment.
However, I was hoping this would have the effect of improving (non-finalizable) reference handling. We've seen serious issues in WeakReference handling and have had to write some twisted code to deal with this.</pre>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
@Moh<br>
<br>
Can you elaborate some more on what twists were necessary or what
problems you had?<br>
<br>
<blockquote cite="mid:6882C9A35DFB9B4FA2779F7BF5B9757D20761169A2@GSCMAMP06EX.firmwide.corp.gs.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<pre wrap="">So I guess the question I have to Kirk and David is: do you feel a GC load of 10K WeakReferences per cycle is also "doing something else wrong"?</pre>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
If there is an elegant way to achieve your goal without using
WeakReferences then it might be better to not use them. But it is
also true that WeakReferences frequently lend an elegant way to
solve a problem. The same goes with finalization which is sometimes
even more elegant.<br>
<br>
<blockquote cite="mid:6882C9A35DFB9B4FA2779F7BF5B9757D20761169A2@GSCMAMP06EX.firmwide.corp.gs.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<pre wrap="">Sorry if this is going off-topic.</pre>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
You're spot on topic and thanks for your comment.<br>
<br>
<blockquote cite="mid:6882C9A35DFB9B4FA2779F7BF5B9757D20761169A2@GSCMAMP06EX.firmwide.corp.gs.com" type="cite"><!--[if !IE]><DIV style="border-left: 2px solid #009900; border-right: 2px solid #009900; padding: 0px 15px; margin: 2px 0px;"><![endif]-->
<pre wrap="">Thanks
Moh
</pre>
<!--[if !IE]></DIV><![endif]--></blockquote>
<br>
<br>
Regards, Peter<br>
<br>
</div>
</blockquote></div><br></div></body></html>