That would be the case, if it can assume access is single-threaded.
Alex
> On 26 Oct 2015, at 11:56, Justin Sampson wrote:
>
> Alex Otenko wrote:
>
>> Wouldn't it be possible to add a test that will always be false?
>>
>> eg
>> [...]
>> if (get() != referent) {
>> [...]
>>
>> The point being
Wouldn’t it be possible to add a test that will always be false?
eg
Reference(T referent, ReferenceQueue queue) {
this.referent = referent;
// - safepoint with GC happens, 'referent' is found weakly-reachable,
'this' Reference is hooked on the pending chain
// - Refere
Alex Otenko wrote:
> Wouldn't it be possible to add a test that will always be false?
>
> eg
> [...]
> if (get() != referent) {
> [...]
>
> The point being that referent would need to stay alive due to
> Java semantics to align with get() and queue assignment.
Couldn't the compiler just inline ge
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/5d13c9b094c4/src/share/vm/opto/library_call.cpp#l5629
C2 does inline it but intentionally forbids commoning out reads of
Reference.get. However, this needs a real fix not a hack.
sent from my phone
On Oct 26, 2015 3:22 PM, "Justin Sampson" wr
It's unlikely there would be a safepoint between those two statements in
compiled code. Polls are typically placed at method exit (modulo polls
inserted for some types of loops, but that's irrelevant to this instance).
With inlining, the poll distance is likely to increase as well. However,
there
Hi,
Thanks for the insight.
I'd like to note that I'm not concerned about the reachability of the
Reference object itself (program code takes care of that - for example
in Cleaner API it hooks Reference objects into a doubly-linked list
exactly for them to stay reachable until discovered by G
>
> Yes, if runtime stripes that instance before it is exposed anywhere
> (e.g. scalarizes the weakref)
If you look at escape analysis code (
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/a60bd3d34158/src/share/vm/opto/escape.cpp#l803),
Reference and subclasses get special treatment and ma
>
> queue is marked volatile, so a simple reordering of the lines should be
> just as effective:
> Reference(T referent, ReferenceQueue queue) {
> this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
> this.referent = referent;
> }
Won't mean much since the plai
>> Might the following be needed or not:
>>
>> Reference(T referent, ReferenceQueue queue) {
>> this.referent = referent;
>> this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
>> reachabilityFence(referent);
>> }
>
queue is marked volatile, so a simple reor
On 10/21/2015 06:53 PM, Andrew Haley wrote:
> On 10/21/2015 04:44 PM, Aleksey Shipilev wrote:
>> Of course, this does not tell another (scary) part of the story, what if
>> the Reference itself is not discovered as strong ref by GC, e.g. when it
>> isn't published on heap, or scalarized by compiler
On 10/21/2015 04:44 PM, Aleksey Shipilev wrote:
> Of course, this does not tell another (scary) part of the story, what if
> the Reference itself is not discovered as strong ref by GC, e.g. when it
> isn't published on heap, or scalarized by compiler, etc.
> reachabilityFence, as currently implemen
Hi,
On 10/21/2015 03:34 PM, Peter Levart wrote:
> Say it is being used like that:
>
> ReferenceQueue queue = ...;
>
> WeakReference wr = new WeakReference(new Object(), queue);
>
> Is it possible that the newly constructed Object is found
> weakly-reachable before the 'queue' is assigned to the
On 10/21/2015 01:34 PM, Peter Levart wrote:
> Is it possible that the newly constructed Object is found
> weakly-reachable before the 'queue' is assigned to the Reference.queue
> field or is there something in the JVM that prevents this happening
> (like all the constructor parameters are reacha
13 matches
Mail list logo
