3

PhantomReference java doc for java 8 and less looks like this:

Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used for scheduling pre-mortem cleanup actions in a more flexible way than is possible with the Java finalization mechanism. If the garbage collector determines at a certain point in time that the referent of a phantom reference is phantom reachable, then at that time or at some later time it will enqueue the reference.

In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The get method of a phantom reference always returns null.

Unlike soft and weak references, phantom references are not automatically cleared by the garbage collector as they are enqueued. An object that is reachable via phantom references will remain so until all such references are cleared or themselves become unreachable

PhantomReference java doc for java 9 and higher looks like this:

Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used to schedule post-mortem cleanup actions. Suppose the garbage collector determines at a certain point in time that an object is phantom reachable. At that time it will atomically clear all phantom references to that object and all phantom references to any other phantom-reachable objects from which that object is reachable. At the same time or at some later time it will enqueue those newly-cleared phantom references that are registered with reference queues.

In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The get method of a phantom reference always returns null.

Was something changing in PhantomReference behaviour in java 9? or just java founders rethought dedication of that class ?

gstackoverflow
  • 36,709
  • 117
  • 359
  • 710
  • 1
    Given, how many garbage collection related questions you already asked, I’m a bit surprised that you don’t know the answer already. E.g. [this answer](https://stackoverflow.com/a/41987600/2711488) does already explain which technical change has been made. And I’m wondering whether [this question](https://stackoverflow.com/q/41378933/2711488) still needs clarification (as you didn’t accept an answer)… – Holger Jun 20 '19 at 11:37
  • @Holger It is old topics and I just was messed with contradicting opinions that time so I decided not to accept it. Thanks for reminder - I will review it. But anyway current topic absolutely different. – gstackoverflow Jun 20 '19 at 11:47
  • I don’t see how “current topic absolutely different”, as both linked questions have an answer mentioning the relevant change made in Java 9. The first link leads directly to the answer, as that answer *is* the answer to your new question. – Holger Jun 20 '19 at 11:53
  • @Holger, I will reread, thanks. What about https://stackoverflow.com/questions/56683916/phantomreference-java-doc-definition ? It marked as duplicate but it is ridiculous – gstackoverflow Jun 20 '19 at 12:01
  • It’s indeed not a duplicate. On the other hand, the answer is quiet trivial, the word “otherwise” only makes sense for the pre-Java 9 behavior and most likely has been overlooked when the documentation was adapted. Ironically, the old documentation had a better sentence right beneath that: “*If the garbage collector determines at a certain point in time that the referent of a phantom reference is phantom reachable, then at that time or at some later time it will enqueue the reference.*”. – Holger Jun 20 '19 at 12:21
  • @Holger is it correct that if I found phantom reference in the queue I can't be sure if the referent was cleared(the memory which referent was kept was cleared) or not ? – gstackoverflow Jun 20 '19 at 12:27
  • @Holger if it is not a duplicate, please vote for reopen and provide a bit more detailed answer there. Thanks in advance – gstackoverflow Jun 20 '19 at 12:28
  • I don’t know, what details to add to that single sentence without repeating stuff, compared to the already linked answer or a hypothetical answer to this question. Normally, you shouldn’t ask too much in one question on SO, but here, these details can be answered with a single concise answer. – Holger Jun 20 '19 at 12:31
  • “cleared” is a term used to describe the behavior of the `Reference` objects. The memory of the referent may get reused by the JVM whenever the application behavior wouldn’t change and with a `PhantomReference`, the referent can’t be retrieved, so it makes no difference whether the memory has been reused already. – Holger Jun 20 '19 at 12:33
  • @Holger theoretically I can save link to the referent in the PhantomReference subclass(I know it is very bad practice because of ressurection but by the way) – gstackoverflow Jun 20 '19 at 12:41
  • @Holger anyway I don't understand meaning of **otherwise** even for java<=8. Could you please elaborate ? – gstackoverflow Jun 20 '19 at 12:43
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/195277/discussion-between-holger-and-gstackoverflow). – Holger Jun 20 '19 at 12:45

1 Answers1

10

Since Java 9, PhantomReference (PR) are automatically cleared. What you see is the Javadoc change that comes as the result of that change.

Before Java 9, the object referenced by PR was kept alive, even though its get() would return null. Therefore, until PR itself is dead, the referent would be technically alive, although you could not acquire the reference to it. The benefits of this behavior are not very clear. Anyhow, PR handling would be the "pre-mortem cleanup".

After Java 9, PR is cleared right before enqueueing (just like other types of weak/soft refs), the referent itself becomes fully dead before PR is processed by application code, which would be the "post-mortem cleanup".

Aleksey Shipilev
  • 18,599
  • 2
  • 67
  • 86
  • Alexey, thanks for your answer. I just want to specify one thing in addition. Is it correct that weak/soft/phantom reference clearing happens before enqueing into ReferenceQueue? – gstackoverflow Jun 22 '19 at 22:37
  • And please, translate to Russian the first sentence of PR javadoc. I really not able to understand meaning of "otherwise" in that sentence. – gstackoverflow Jun 22 '19 at 22:40
  • @gstackoverflow that’s implementation specific, but yes, the clearing happens immediately in the garbage collection thread, whereas the enqueuing happens asynchronously in a dedicated “reference handler” thread after that. The specification for each reference type contains the phrases “At that time it will atomically clear all … references” and “At the same time or at some later time it will enqueue those newly-cleared … references”, allowing that behavior. – Holger Jun 24 '19 at 11:24
  • If you shy to type here in Russian, please send me response to gredwhite@gmail.com – gstackoverflow Jul 05 '19 at 10:07