Summary of Lightweight finalization for the JDK without any drawbacks
Peter Levart
peter.levart at gmail.com
Fri Aug 15 10:06:32 UTC 2014
Hi Jaroslav,
FWIW, I have experimented with adapting sun.misc.Cleaner for external
use. For example, it could be used as a NetBeans provided API. The
thread management is based on tracking of Cleaner (PhantomReference)
objects. When 1st Cleaner object is added to a doubly-linked list, the
thread is started, when the last Cleaner object is removed from the
list, it is stopped, so this is a kind of reference tracking (not
counting). Here's the attempt:
http://cr.openjdk.java.net/~plevart/misc/nb.Cleaner/Cleaner.java
Would this be an appropriate replacement for ActiveQueue API in NetBeans?
Regards, Peter
On 08/15/2014 11:34 AM, Jaroslav Tulach wrote:
> Hi.
> I'd like to thank everyone in participating in our discussion about lightweight
> finalization and shaping and sharping my understanding of the problem. I believe the
> discussion has now slowed down and it is time for another summary. I have added one
> into the issue (while also changing its subject):
>
> https://bugs.openjdk.java.net/browse/JDK-8051843?focusedCommentId=13539596&p
> age=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#comment-13539596[1]
>
> I believe our understanding of the problem has been deepen enough to focus on
> creation of the actual public API for lightweight finalization. It will be my task for up-
> coming week to start necessary steps to propose such API.
>
> -jt
>
> PS: I'd like to especially thank to Andrew for pointing out the "this" reference problem
> and Doug for commenting it. I've reported
> https://bugs.openjdk.java.net/browse/JDK-8055183[2] to resolve it somehow. I'll be
> watching from distance eager to know the result.
>
>
> Dne St 13. srpna 2014 13:12:43, Jaroslav Tulach napsal(a):
>> Dne So 9. srpna 2014 07:18:54, Doug Lea napsal(a):
>>>> Dne Pá 8. srpna 2014 15:02:41, Stanimir Simeonoff napsal(a):
>>>>
>>>>
>>>> According to articles provided by Andrew[1], toString() can be on stack,
>>>> even if obj
>>>> (e.g. this for toString()) is garbage collected. This is a bit
>>>> surprising
>>>> (an OOP fan
>>>> would expect that this is GC root while its instance method is running),
>>>> but such
>>>> behavior is said to be in accordance to the 1.8 spec.
>>>>
>>>> Question for Doug (as a member of jmm-dev list) then is: would not it be
>>>> wise to
>>>> change the spec to require this to be GC root while its instance method
>>>> is
>>>> being
>>>> executed?
>>> Possible changes are being discussed. It is not clear yet
>>> exactly what rules would better match people's expectations
>>> while remaining implementable by JVMs, and/or whether they
>>> would force performance degradations even
>>> for the vast majority of code not using finalizers. It is
>>> very possible the end result will just be to clarify rules and
>>> provide mechanisms allowing better programmer control.
>>>
>>> Any changes would go into effect for JDK9 at the earliest,
>>> so if you can find a way to avoid use of finalizers
>>> here, it would be a better option.
>> I'll do my best to come up with a lightweight alternative to finalization.
>> However:
>>
>> As far as I understand Andrew's inquiry, the problem is not (that much)
>> related to finalizers, rather to question whether following method can ever
>> finish or not:
>>
>> private void gcThis() {
>> Reference<?> ref = new WeakReference<>(this);
>> while (ref.get() != null) {
>> System.gc();
>> }
>> System.err.println("ref is gone: " + ref);
>> }
>>
>> On Oracle's JDK8 the method has never finished for me. However when I tried
>> IBM's JDK (identification can be found below) the method finished every
>> time! A bit of consistency would be beneficial in this area, imho.
>>
>> -jt
>>
>> PS: While I understand why the two JDKs behave the way they behave, I don't
>> think this is explainable to regular Java developers. But maybe they don't
>> care that much and one day it will be easy to google out solution on
>> stackoverflow to prevent "this" being garbage collected by changing the last
>> method line to
>>
>> System.err.println("ref is gone: " + ref + " for " + this);
>>
>> The version of IBM's Java was:
>>
>> ~/bin/ibmjava7$ ./bin/java -version
>> java version "1.7.0"
>> Java(TM) SE Runtime Environment (build pxa6470_27sr1fp1-20140708_01(SR1
>> FP1)) IBM J9 VM (build 2.7, JRE 1.7.0 Linux amd64-64 Compressed References
>> 20140707_205525 (JIT enabled, AOT enabled)
>> J9VM - R27_Java727_SR1_20140707_1408_B205525
>> JIT - tr.r13.java_20140410_61421.07
>> GC - R27_Java727_SR1_20140707_1408_B205525_CMPRSS
>> J9CL - 20140707_205525)
>> JCL - 20140707_01 based on Oracle 7u65-b16
> --------
> [1]
> https://bugs.openjdk.java.net/browse/JDK-8051843?focusedCommentId=13539596&p
> age=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#comment-13539596
> [2] https://bugs.openjdk.java.net/browse/JDK-8055183
More information about the core-libs-dev
mailing list