On Tue, 10 Aug 2021 08:59:59 GMT, Per Liden wrote:
>> While fixing JDK-8270626 it was discovered that the C2 intrinsic for
>> `Reference.refersTo()` is not used as often as one would think. Instead C2
>> often prefers using the native implementation, which is much slower whi
On Mon, 9 Aug 2021 13:13:33 GMT, Per Liden wrote:
> While fixing JDK-8270626 it was discovered that the C2 intrinsic for
> `Reference.refersTo()` is not used as often as one would think. Instead C2
> often prefers using the native implementation, which is much slower which
>
On Mon, 9 Aug 2021 19:59:21 GMT, Vladimir Ivanov wrote:
>> Per Liden has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Private implies final
>
> src/java.base/share/classes/java/lang/ref/Reference.jav
tDescription.java`)
> that initially uncovered the problem. See JDK-8270626 for additional
> information.
Per Liden has updated the pull request incrementally with one additional commit
since the last revision:
Private implies final
-
Changes:
- all: https://git.openjdk.
While fixing JDK-8270626 it was discovered that the C2 intrinsic for
`Reference.refersTo()` is not used as often as one would think. Instead C2
often prefers using the native implementation, which is much slower which
defeats the purpose of having an intrinsic in the first place.
The problem ar
JDK-8240679 introduced a change where the information exposed via the
GarbageCollectorMXBean went from being related to the GC pauses to instead be
related to the GC cycles. This helped provide more accurate heap usage
information. However, some users have noticed that that you no longer get
ti
On Mon, 25 Jan 2021 13:23:27 GMT, Magnus Ihse Bursie wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral back
>
> Changes requested by ihse (
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
> Tested
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
> Tested
On Tue, 24 Nov 2020 03:05:19 GMT, Kim Barrett wrote:
>> Please review this change to Reference.clear() to address several issues.
>>
>> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
>> field to null may extend the lifetime of the referent value.
>>
>> (JDK-8240696) F
On Mon, 23 Nov 2020 15:00:08 GMT, Roman Kennke wrote:
>> Please review this change to Reference.clear() to address several issues.
>>
>> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
>> field to null may extend the lifetime of the referent value.
>>
>> (JDK-8240696)
On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett wrote:
> Please review this change to Reference.clear() to address several issues.
>
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
>
> (JDK-8240696) For GCs
On Wed, 14 Oct 2020 04:27:34 GMT, Kim Barrett wrote:
>> Finally returning to this review that was started in April 2020. I've
>> recast it as a github PR. I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A
On Thu, 8 Oct 2020 14:00:11 GMT, Roger Riggs wrote:
>> Can you add a unit test in `test/jdk/java/lang/ref` that serves as a basic
>> API test for this new `refersTo` API without
>> depending the WhiteBox API? test/hotspot/jtreg/gc` test serves as a more
>> white-boxed type and comprehensive
Hi Kim,
On 4/8/20 2:25 AM, Kim Barrett wrote:
[Note review on both core-libs and hotspot-gc-dev lists; try not to lose
either when replying.]
Please review a new function: java.lang.ref.Reference.refersTo.
Nice!
This function is needed to test the referent of a Reference object
without art
Error, contradicting the 'guarantee' in the javadoc.
Workaround: if you additionally configure
`-XX:SoftRefLRUPolicyMSPerMB=0`, it finalizes them and doesn't run out
of memory.
Tested with:
openjdk version "1.8.0_212"
java version "1.8.0_144" (oracle)
openjdk version &q
Hi Michael,
On 4/16/19 4:19 AM, David Holmes wrote:
Hi Michael,
Re-directing to core-libs-dev and hotspot-gc-dev.
Thanks,
David
On 16/04/2019 12:14 pm, Michael Pollmeier wrote:
Quoting
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/SoftReference.html
All sof
On 03/13/2019 09:29 PM, Kim Barrett wrote:
On Mar 13, 2019, at 4:07 PM, Kim Barrett wrote:
Please review this change to the JNI specification. The specified
behavior of Weak Global References, and in particular their
relationship to Java PhantomReference, is being updated to account
for a ch
On 2018-07-09 20:49, mandy chung wrote:
On 7/9/18 11:31 AM, Zheka Kozlov wrote:
It is possible to create a WeakReference/SoftReference/PhantomReference
with a null value in which case the Reference will never be enqueued.
This
is quite obvious (since null cannot be weakly/softly/phantom re
On 05/17/2018 10:03 PM, mark.reinh...@oracle.com wrote:
2018/5/16 18:31:15 -0700, marti...@google.com:
I've been confused by NULL vs null for years.
That’s because `NULL` in ReferenceQueue.java refers to the singleton
object `ReferenceQueue.NULL`, not the null value. See the long comment
at t
in practice on current platforms.
If all you're trying to do is to ensure atomicity and that the
reads/writes don't get optimized away by the jit, then consider using
"opaque" VarHandles instead.
I was surprised there was no bug subcomponent for java.lang.ref
On Fri,
The clock and timestamp fields in SoftReference should be declared
volatile. These fields are read or updated by the VM, (possibly)
concurrently with the execution of Java threads.
To be more specific, the timestamp field is read by the GC during
reference discovery, e.g. during G1/CMS concurr
Still looks good.
cheers,
Per
On 2016-08-23 23:09, Kim Barrett wrote:
Mandy asked for some additional comments to make life easier for
future readers. I've also stopped pretending the description for
waitForReferenceProcessing is javadoc, since this function is private
and only accessible via
Hi Kim,
On 2016-08-09 03:25, Kim Barrett wrote:
On Aug 8, 2016, at 8:16 AM, Per Liden wrote:
Hi Kim,
On 2016-08-01 20:47, Kim Barrett wrote:
This updated webrev addresses concerns about the performance of the VM
API used by the reference processor thread in the original webrev.
New webrevs
Hi Kim,
On 2016-08-01 20:47, Kim Barrett wrote:
This updated webrev addresses concerns about the performance of the VM
API used by the reference processor thread in the original webrev.
New webrevs:
full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/
http://cr.openjdk.java.net/~kba
Hi Kim,
On 2016-06-24 22:09, Kim Barrett wrote:
Please review this change which moves the Reference pending list and
locking from the java.lang.ref.Reference class into the VM. This
includes elimination of the ReferencePendingListLocker mechanism in
the VM. This fixes various fragility issues a
Hi Dan,
On 2016-06-28 03:34, Daniel D. Daugherty wrote:
[...]
src/share/vm/gc/shared/vmGCOperations.cpp
L103: Heap_lock->unlock();
You did not add a conditional "Heap_lock->notify_all()" before
the Heap_lock->unlock() like you've done in other places.
Since y
Hi David,
On 2016-06-28 06:04, David Holmes wrote:
Hi Kim,
I like all the removal of the pending-list-locker related code, but
can't really comment on the details of how it was replaced and interacts
with all the GC code. The interface to the Reference class is fine, it
is the GC code that push
Hi Peter,
On 2016-03-28 19:18, Peter Levart wrote:
[...]
And now a few words about ReferenceHandler thread and synchronization
with it (for Kim and Per mostly). I think it should not be a problem to
move the following two java.lang.ref.Reference methods to native code if
desired:
static Re
Hi Peter,
On 2016-03-23 15:02, Peter Levart wrote:
Hi Per, Kim,
On 03/22/2016 10:24 AM, Per Liden wrote:
So, I imagine the ReferenceHandler could do something like this:
while (true) {
// getPendingReferences() is a downcall to the VM which
// blocks until the pending list becomes
Hi,
On 2016-03-23 08:13, Peter Levart wrote:
On 03/22/2016 10:28 PM, Kim Barrett wrote:
On Mar 22, 2016, at 5:24 AM, Per Liden wrote:
One thing I like about this approach is that it's only the
ReferenceHandler thread that pops of elements from the pending list
and enqueues them.
addition, find a
way to handle the OOME thrown from Cleaner.clean().
What do you think?
Regards, Peter
On 03/21/2016 02:41 PM, Per Liden wrote:
Hi David,
On 2016-03-21 13:49, David Holmes wrote:
Hi Per,
On 21/03/2016 10:20 PM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old th
On 2016-03-21 18:32, Kim Barrett wrote:
On Mar 21, 2016, at 8:20 AM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the discussio
round
Cleaner.clean() catching not just OOME, but all Throwables, right?
cheers,
Per
Regards, Peter
On 03/21/2016 02:41 PM, Per Liden wrote:
Hi David,
On 2016-03-21 13:49, David Holmes wrote:
Hi Per,
On 21/03/2016 10:20 PM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old th
Hi David,
On 2016-03-21 13:49, David Holmes wrote:
Hi Per,
On 21/03/2016 10:20 PM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the discussion, I propose the following patch for
ReferenceHandler:
http://cr.openjdk.java.net/~plevart/jdk9-de
On 2015-12-04 19:16, Kim Barrett wrote:
On Dec 4, 2015, at 2:16 AM, Per Liden wrote:
On 2015-12-02 19:37, Kim Barrett wrote:
Please review this change to PhantomReference processing, changing the
GC-based notification to automatically clear the referent.
[…]
CR:
https
Hi Peter,
On 2015-12-04 13:35, Peter Levart wrote:
On 12/04/2015 08:16 AM, Per Liden wrote:
test/java/lang/ref/PhantomReferentClearing.java:
85 // Delete root -> O1, collect, verify P1 notified, P2 not
notified.
86 O1 = null;
87 System.gc();
88
Hi Kim,
On 2015-12-02 19:37, Kim Barrett wrote:
Please review this change to PhantomReference processing, changing the
GC-based notification to automatically clear the referent.
This change provides performance benefits by eliminating the work
involved in keeping the otherwise inaccessible refe
39 matches
Mail list logo
