> On Apr 9, 2020, at 11:31 AM, Paul Sandoz wrote:
>
> Reference.java
> —
>
> 335 *
> 336 * @return The object to which this reference refers, or
> 337 * {@code null} if this reference object has been cleared
>
> Add @see refersTo
>
> 338 */
> 339 @HotSpotInt
Please review this fix for a missing comma in the copyright
header for
src/jdk.incubator.jpackage/share/classes/jdk/incubator/jpackage/internal/DottedVersion.java.
CR:
https://bugs.openjdk.java.net/browse/JDK-8243587
Webrev:
https://cr.openjdk.java.net/~kbarrett/8243587/webrev/
Testing:
Tested
> On Apr 26, 2020, at 10:18 PM, Igor Ignatev wrote:
>
> LGTM
>
> — Igor
>
>> On Apr 26, 2020, at 7:14 PM, Kim Barrett wrote:
>>
>> Please review this fix for a missing comma in the copyright
>> header for
>> src/jdk.incubator.jpacka
> On May 6, 2020, at 9:01 PM, Yumin Qi wrote:
>
> Hi,
> Please review the fix for
> bug: https://bugs.openjdk.java.net/browse/JDK-8244495
> webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/
>
> Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed
> after 823
[Changes are only to the build system, but since the changes have jdk-wide
effect I’ve cc’d what I think are the relevant dev lists.]
This change is part of JEP 347; the intent is to target JDK 16.
Please review this change to the building of C++ code in the JDK to
enable the use of C++14 languag
> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie
> wrote:
>
> On 2020-06-05 13:59, Jim Laskey wrote:
>> I know there was a discussion about this elsewhere but I would like to take
>> the opportunity to correct this now
>>
>> make//autoconf/flags-cflags.m4:241
>>
>> […]
>> MacOSX has been payi
> On Jun 5, 2020, at 7:57 PM, Magnus Ihse Bursie
> wrote:
>
> On 2020-06-05 09:52, Kim Barrett wrote:
>> [Changes are only to the build system, but since the changes have jdk-wide
>> effect I’ve cc’d what I think are the relevant dev lists.]
>>
>> This chan
> On Jun 8, 2020, at 4:07 PM, Philip Race wrote:
>
> Hi Kim,
>
> Can we amend the JEP itself to be not solely about hotspot.
> Since it affects other areas I think that
> 1) They may need to be compiled with C++14 enabled whether they use new
> features or not
> 2) They may want - or need - to
> On Jun 10, 2020, at 2:26 AM, Kim Barrett wrote:
>
>> On Jun 8, 2020, at 4:07 PM, Philip Race wrote:
>
>> BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says
>>> For Solaris: Add the -std=c++14 compiler option. .
>>
>> So I
to require at
least a major ABI change, and at the time the JEP was created there
was no path to C++14 for the AIX/PPC port; both of those needed
visibility and discussion that seemed best provided via the JEP
process.
> -phil.
>
> On 6/13/20, 8:48 PM, Kim Barrett wrote:
>>> On Jun
> On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote:
>
>> On Jun 14, 2020, at 12:45 AM, Philip Race wrote:
>>
>> Kim,
>>
>>
>> Until it says in "the JDK" and not "in HotSpot" you have not addressed my
>> main point.
>&g
> On Jun 24, 2020, at 7:01 AM, Magnus Ihse Bursie
> wrote:
>
> On 2020-06-18 08:34, Kim Barrett wrote:
>>> On Jun 15, 2020, at 7:41 AM, Kim Barrett wrote:
>>>
>>>> On Jun 14, 2020, at 12:45 AM, Philip Race wrote:
>>>>
>>>> Ki
I just noticed that doc/building.{md,html} describes minimum toolchain versions,
so also needs to be updated. Here’s the update, matching what’s now in the JEP:
full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/
I also de
> On Jul 7, 2020, at 9:59 AM, Erik Joelsson wrote:
>
> Doc changes look good.
>
> /Erik
>
> On 2020-07-06 18:10, Kim Barrett wrote:
>> I just noticed that doc/building.{md,html} describes minimum toolchain
>> versions,
>> so also needs to be updated. He
urrently waiting on some other folks to have time to chime in.
Replies to your comments inline below.
> On 8/04/2020 10: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 functi
Finally getting back to this after some internal discussion that
dragged along because folks have been busy.
> On Apr 8, 2020, at 12:05 PM, Gil Tene wrote:
>
> Lifting out of response from the JIRA issue:
>
> I always worry when proposing a change to an existing invariant, and
> PhantomReferenc
> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote:
>
> Hi all,
>
> Please review this simple change to fix some compile warnings.
>
> The newer gcc (gcc-8 or higher) would warn for calls to bounded string
> manipulation functions such as 'strncpy' that may either truncate the
> copied string or leav
> On Sep 1, 2020, at 5:46 AM, Kim Barrett wrote:
>
>> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote:
>>
>> Hi all,
>>
>> Please review this simple change to fix some compile warnings.
>>
>> The newer gcc (gcc-8 or higher) would warn for calls to
> On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie
> wrote:
>
> On 2020-09-01 11:46, Kim Barrett wrote:
>> I really hate -Wstringop-truncation. It's been a constant source of churn
>> for us ever since it appeared. The changes being made to getIndex and
>>
> On Sep 2, 2020, at 3:19 AM, Florian Weimer wrote:
>
> * Magnus Ihse Bursie:
>
>> Maybe we should have a common library for all native code where we
>> supply our own string operation functions? It will then be much easier
>> to make sure the implementation passes different compiler versions,
> On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote:
>
> * Daniel Fuchs:
>
>> Hi,
>>
>> On 02/09/2020 08:19, Florian Weimer wrote:
>>> At least one of the bugs was in theory user-visible: the network
>>> interface code would return data for an interface that does not actually
>>> exist on the sy
> On Sep 1, 2020, at 9:59 AM, Eric Liu wrote:
> I just tested this patch by GCC (10.1.0) and it would really re-trigger those
> warnings :(
> I have not noticed the history before, but it's really hard to imagine that
> GCC would
> have different behaviors.
Can you be (very) specific about thi
> On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote:
> src/hotspot/share/compiler/compileBroker.hpp
> 64 PRAGMA_DIAG_PUSH
> 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED
> 66 // This code can incorrectly cause a "stringop-truncation" warning
> with gcc
> 67
> On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote:
> src/java.base/unix/native/libnet/NetworkInterface.c
> 1298 memset((char *)&if2, 0, sizeof(if2));
> 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1);
> 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0
> On Sep 6, 2020, at 1:03 PM, Florian Weimer wrote:
> There is no reason to use strncpy. At least on Linux, the struct field
> needs to be null-terminated, and you need to compute the length for the
> length check. So you might as well use memcpy with the length plus one
> (to copy the null term
> On Sep 6, 2020, at 9:51 PM, Kim Barrett wrote:
> Oh, good grief! This file contains 3 identical copies of getMTU and
> getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a
> mess. If changing any of these for linux, probably similar changes
> ought to be appli
> On Sep 7, 2020, at 10:56 AM, Eric Liu wrote:
> I have tested 4 cases for those warnings:
> a) Without my patch, without asan, gcc-8 and gcc-10 are OK.
> b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK.
> c) With my patch, without asan, gcc-8 and gcc-10 are OK.
That’s *very* stran
> On Sep 7, 2020, at 5:55 AM, Florian Weimer wrote:
>
> * Kim Barrett:
>
>> And strlen is not even necessarily the best solution, as it likely
>> introduces an additional otherwise unnecessary string traversal. For
>> example, getFlags could be changed t
> On Sep 23, 2020, at 2:10 AM, Eric Liu wrote:
>
> Hi Kim,
>
> Sorry for the delay.
>
> This patch removes a redundant string copy in NetworkInterface.c to avoid
> string-truncation
> warning. Other warnings we talked before, which are unable to completely fix
> in different version
> of g
> On Oct 12, 2020, at 3:25 PM, Per Liden wrote:
>
> On Mon, 12 Oct 2020 15:56:59 GMT, Kim Barrett wrote:
>
>>> test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 186:
>>>
>>>> 184:
>>>> 185: expectNotValue(testWeak2, testOb
plitting avoids that complexity.
>
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage
> collectors.
Kim Barrett has updated the pull request incrementally with three additional
commits since the last revision:
- simplify test
-
On Wed, 14 Oct 2020 11:18:18 GMT, Albert Mingkun Yang wrote:
>> Kim Barrett has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - simplify test
>> - cleanup nits from Mandy
>> - use Object instead o
On Wed, 14 Oct 2020 14:39:40 GMT, Albert Mingkun Yang wrote:
>> (1) The "0" suffix is idiomatic for this sort of thing. See, for example,
>> src/java.base/share/native/libjava/ConstantPool.c. (2) I'm not sure what
>> else besides an override one might wonder
>> about? "Default implementation o
plitting avoids that complexity.
>
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage
> collectors.
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
Mor
plitting avoids that complexity.
>
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage
> collectors.
Kim Barrett has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev
excludes the unrelat
On Fri, 16 Oct 2020 05:41:17 GMT, David Holmes wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull
>> request contai
> On Oct 18, 2020, at 5:36 PM, David Holmes wrote:
>
> On 17/10/2020 1:23 am, Kim Barrett wrote:
>>> src/java.base/share/classes/java/lang/ref/Reference.java line 348:
>>>
>>>> 346: * Tests if this reference object refers to {@code obj}. If
>
> On Oct 19, 2020, at 7:20 PM, Mandy Chung wrote:
>
> On Mon, 19 Oct 2020 23:10:23 GMT, Mandy Chung wrote:
>
>>> Looks good.
>>
>>> That's the crux of it: what exactly is meant by "the referent"? Does it
>>> mean the original object that was used as the referent, or does it mean
>>> the curren
On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung wrote:
> @kimbarrett your reworded text is okay. I think "if it initially had some
> other referent value" can be dropped.
>
> For a `Reference` constructed with a `null` referent, we can clarify in the
> spec that such reference object will never
> On Oct 20, 2020, at 2:09 AM, David Holmes wrote:
>
> On 20/10/2020 3:26 pm, Kim Barrett wrote:
>> On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung wrote:
>>> @kimbarrett your reworded text is okay. I think "if it initially had some
>>> other referent
> On Oct 20, 2020, at 3:21 AM, David Holmes wrote:
>
> On 20/10/2020 5:01 pm, Kim Barrett wrote:
>>> On Oct 20, 2020, at 2:09 AM, David Holmes wrote:
>>>
>>> I think that can be addressed by considering a Reference created with a
>>> null referent
On Tue, 20 Oct 2020 16:35:02 GMT, Mandy Chung wrote:
>>> @kimbarrett your reworded text is okay. I think "if it initially had some
>>> other referent value" can be dropped.
>>>
>>> For a `Reference` constructed with a `null` referent, we can clarify in the
>>> spec that such reference object w
plitting avoids that complexity.
>
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage
> collectors.
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
improv
On Fri, 16 Oct 2020 19:22:16 GMT, Mandy Chung wrote:
>> I just want to note that if you have a `Reference ref` at hand,
>> you can not just do:
>> Referemce r = (Reference) ref;
>> ...since those generic types are not related. You have to do something like:
>>
>> @SuppressWarnings({"unchecked",
plitting avoids that complexity.
>
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage
> collectors.
Kim Barrett has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes t
On Sun, 4 Oct 2020 03:59:59 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-
On Wed, 4 Nov 2020 09:31:13 GMT, Tagir F. Valeev wrote:
>> The API looks good, thanks for getting this in.
>
> Hello!
>
> As an IDE developer, I'm thinking about IDE inspection that may suggest the
> new method. My idea is to suggest replacing every `ref.get() == obj` with
> `ref.refersTo(obj)
On Wed, 4 Nov 2020 09:31:13 GMT, Tagir F. Valeev wrote:
> Hello!
>
> As an IDE developer, I'm thinking about IDE inspection that may suggest the
> new method. My idea is to suggest replacing every `ref.get() == obj` with
> `ref.refersTo(obj)`. Is this a good idea or there are cases when `ref.g
>> + if (aborted) {
>> + logProgress("Waiting for completion FAILED after: " +
>> dur);
>> + } else {
>> + logProgress("Waiting for completion finished after: " +
>> dur);
>> +
> On May 30, 2019, at 3:58 PM, Roger Riggs wrote:
>
> Hi Kim,
>
> To ensure you see some messages in the case of timeouts, it would be
> useful to call System.out.flush() after printing the message in logProcess().
Good idea; added.
full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
i
ms reasonable to me.
>>>
>>> Thanks,
>>> David
>>>
>>> On 31/05/2019 7:04 am, Kim Barrett wrote:
>>>>> On May 30, 2019, at 3:58 PM, Roger Riggs wrote:
>>>>>
>>>>> Hi Kim,
>>>>>
>>&
> On May 31, 2019, at 8:02 AM, Roger Riggs wrote:
>
> +1
Thanks.
>
> On 5/31/19 2:19 AM, David Holmes wrote:
>> Hi Kim,
>>
>> This seems reasonable to me.
>>
>> Thanks,
>> David
>>
>> On 31/05/2019 7:04 am, Kim Barr
> On May 31, 2019, at 2:19 AM, David Holmes wrote:
>
> Hi Kim,
>
> This seems reasonable to me.
>
> Thanks,
> David
Thanks.
>
> On 31/05/2019 7:04 am, Kim Barrett wrote:
>>> On May 30, 2019, at 3:58 PM, Roger Riggs wrote:
>>>
>>>
> On Mar 2, 2020, at 7:00 AM, Andrew Haley wrote:
>
> On 11/19/18 8:39 PM, Kim Barrett wrote:
>> I don't see any benefit to making the first C++ code change that uses
>> a new feature also incorporate the needed build system changes.
>> Indeed, how does one devel
> On Mar 3, 2020, at 4:49 PM, Alexey Semenyuk
> wrote:
>
> How about C++11? I have a pending patch for jpackage that depends on C++11
> features that I hesitate to pull in jdk15.
The reasons for HotSpot (at least) not already being on C++14 (cost of
switching over the Solaris Studio based plat
[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.
This function is needed to test the referent of a Reference object
without artificially extending the lifetime of the referent object, as
> On Apr 8, 2020, at 4:11 AM, Thomas Schatzl wrote:
>
> Hi,
>
> On 08.04.20 02:25, 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.
> On Apr 8, 2020, at 12:19 PM, Mandy Chung wrote:
>
> I agree with Gil on this point. `PhantomReference::get` always returns
> null. The intent behavior of `ref.refersTo(obj)` is the same as `ref.get()
> == obj`.Gil's proposed option to have `refersTo(obj)` to return true only
> if obj
> On Apr 8, 2020, at 3:32 AM, Per Liden wrote:
> On 4/8/20 2:25 AM, Kim Barrett wrote:
>> The new function uses a native method whose implementation is in the
>> VM so it can use the Access API. It is the intent that this function
>> will be intrinsified by optimizing co
> On Apr 8, 2020, at 5:44 AM, Aleksey Shipilev wrote:
>
> On 4/8/20 2:25 AM, Kim Barrett wrote:
>> Webrev:
>> https://cr.openjdk.java.net/~kbarrett/8188055/open.04/
>
> src/hotspot/share/prims/jvm.cpp:
>
> *) Do we really need a typedef (L3250) for someth
On Mon, 16 Nov 2020 18:30:38 GMT, Mandy Chung wrote:
>> A follow-up to JDK-8256106, this is adding two asserts to check that the API
>> is used as it should be, i.e. only on inactive FinalReferences. Also, in
>> Finalizer, where getInactive() is used, there is a null-check. The GC must
>> neve
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 with concurrent reference processing, clearing the
referent field
-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these
> changes.
Kim Barrett has updated the pull request incrementally with two additional
commits since the
On Mon, 23 Nov 2020 12:50:31 GMT, Per Liden wrote:
> Looks good. Just want to request that you also remove the following comment
> in zReferenceProcessor.cpp, as it's no longer true.
>
> ```
> --- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
> +++ b/src/hotspot/share/gc/z/zReferenceProcesso
On Tue, 24 Nov 2020 02:59:50 GMT, Kim Barrett wrote:
>> Looks good. Just want to request that you also remove the following comment
>> in zReferenceProcessor.cpp, as it's no longer true.
>>
>> --- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
&g
On Mon, 23 Nov 2020 20:36:57 GMT, Roman Kennke wrote:
>> Kim Barrett has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - new tests need ref in oldgen too
>> - remove obsolete comment about races with cl
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.
>
>
-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these
> changes.
Kim Barrett has updated the pull request with a new target base due to a merge
or a rebase. The inc
On Thu, 3 Dec 2020 22:54:54 GMT, Mandy Chung wrote:
> This patch replaces some uses of `Reference::get` to `Reference::refersTo` to
> avoid keeping a referent strongly reachable that could cause unnecessary
> delay in collecting such object. I only made change in some but not all
> classes i
On Fri, 4 Dec 2020 22:38:24 GMT, Mandy Chung wrote:
>> This patch replaces some uses of `Reference::get` to `Reference::refersTo`
>> to avoid keeping a referent strongly reachable that could cause unnecessary
>> delay in collecting such object. I only made change in some but not all
>> class
On Tue, 8 Dec 2020 02:36:01 GMT, Mandy Chung wrote:
> `Reference::isEnqueued` method was never implemented as it was initially
> specified since 1.2. The specification says that it tests if this reference
> object has been enqueued, but the long-standing behavior is to test if this
> reference
Please review this change that eliminates the use of Reference.isEnqueued by
tests. There were three tests using it:
vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.java
jdk/java/lang/ref/ReferenceEnqueue.java
In each of them, some combi
On Tue, 8 Dec 2020 20:42:52 GMT, Mandy Chung wrote:
>> `Reference::isEnqueued` method was never implemented as it was initially
>> specified since 1.2. The specification says that it tests if this reference
>> object has been enqueued, but the long-standing behavior is to test if this
>> refer
On Wed, 9 Dec 2020 13:28:44 GMT, Thomas Schatzl wrote:
>> Please review this change that eliminates the use of Reference.isEnqueued by
>> tests. There were three tests using it:
>>
>> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
>> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.j
On Wed, 9 Dec 2020 13:26:04 GMT, Thomas Schatzl wrote:
>> Please review this change that eliminates the use of Reference.isEnqueued by
>> tests. There were three tests using it:
>>
>> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
>> vmTestbase/gc/gctests/WeakReferenceGC/WeakReferenceGC.j
On Wed, 9 Dec 2020 13:59:09 GMT, Thomas Schatzl wrote:
>> test/jdk/java/lang/ref/ReferenceEnqueue.java line 58:
>>
>>> 56: for (int i = 0; i < iterations; i++) {
>>> 57: System.gc();
>>> 58: enqueued = (queue.remove(100) == ref);
>>
>> The code does n
d the failure checks were made stronger.
>
> Testing:
> mach5 tier1
> Locally (linux-x64) ran all three tests with each GC (including Shenandoah).
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
move REMOVE and RETAIN dec
d the failure checks were made stronger.
>
> Testing:
> mach5 tier1
> Locally (linux-x64) ran all three tests with each GC (including Shenandoah).
Kim Barrett has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelate
On Tue, 8 Dec 2020 09:52:51 GMT, Kim Barrett wrote:
> Please review this change that eliminates the use of Reference.isEnqueued by
> tests. There were three tests using it:
>
> vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
> vmTestbase/gc/gctests/WeakReferenceGC/WeakR
On Tue, 8 Dec 2020 17:30:11 GMT, Mandy Chung wrote:
>> Kim Barrett has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains five addi
Please review this change which fixes the type of the private
Reference.discovered field. It was Reference, but that's wrong because
it can be any Reference object.
I've changed it to Reference and let that flow through, updating some
other variables that were previously somewhat incorrectly type
ding the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference. The pending list handling has nothing to do with the generic
> parameter T.
>
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
> On Jan 18, 2021, at 12:28 PM, Peter Levart wrote:
> If you introduce a private method in Reference:
>
>private void enqueueFromPending() {
>var q = queue;
>if (q != ReferenceQueue.NULL) q.enqueue(this);
>}
>
> ...and use it Reference.processPendingReferences while loop
ding the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference. The pending list handling has nothing to do with the generic
> parameter T.
>
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are r
On Tue, 19 Jan 2021 11:15:17 GMT, Peter Levart wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> plevart improvement
>
> This looks good.
Thanks @plevart , @rkennke , @RogerRi
ding the discovered field,
> could be moved into a non-public, non-generic, sealed(?) base class of
> Reference. The pending list handling has nothing to do with the generic
> parameter T.
>
> Testing:
> mach5 tier1 and tier4 (tier4 is where vmTestbase_vm_gc_ref tests are run)
On Sat, 26 Dec 2020 03:25:51 GMT, Kim Barrett wrote:
> Please review this change which fixes the type of the private
> Reference.discovered field. It was Reference, but that's wrong because
> it can be any Reference object.
>
> I've changed it to Reference and let th
Please review this change to java.util.Timer, replacing the use of deprecated
finalization-based cleanup with use of java.lang.ref.Cleaner.
In addition, Timer.cancel now cancels any later execution of the the no longer
relevant cleanup.
Testing:
mach5 tier1
New AutoStop test verifies the specif
On Sun, 21 Mar 2021 22:49:37 GMT, David Holmes wrote:
>> Please review this change to java.util.Timer, replacing the use of
>> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>>
>> In addition, Timer.cancel now cancels any later execution of the the no
>> longer releva
On Sun, 21 Mar 2021 22:57:10 GMT, David Holmes wrote:
>> Please review this change to java.util.Timer, replacing the use of
>> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>>
>> In addition, Timer.cancel now cancels any later execution of the the no
>> longer releva
ier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
dholmes review
-
Changes:
- all: https://git.
On Mon, 22 Mar 2021 07:15:24 GMT, Kim Barrett wrote:
>> Please review this change to java.util.Timer, replacing the use of
>> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>>
>> In addition, Timer.cancel now cancels any later execution
ier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)
Kim Barrett has updated the pull request incrementally with one additional
commit since the last revision:
make ThreadReaper constructor non-public
On Tue, 23 Mar 2021 18:36:24 GMT, Brent Christian wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make ThreadReaper constructor non-public
>
> Marked as reviewed by bchristi (Revi
ier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)
Kim Barrett has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by the merge/reb
On Sun, 21 Mar 2021 03:53:24 GMT, Kim Barrett wrote:
> Please review this change to java.util.Timer, replacing the use of deprecated
> finalization-based cleanup with use of java.lang.ref.Cleaner.
>
> In addition, Timer.cancel now cancels any later execution of the the no
>
On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson wrote:
> Add more logging to the LargeCopyWithMark.java test, to gather more
> information when this test fails with OOME.
>
> The intention is to gather more info for JDK-8239089.
>
> I consider this patch trivial, and expect to push it after
Please review this change to the String Deduplication facility. It is being
changed to use OopStorage to hold weak references to relevant objects,
rather than bespoke data structures requiring dedicated processing phases by
supporting GCs.
(The Shenandoah update was contributed by Zhengyu Gu.)
T
On Sun, 25 Apr 2021 17:32:51 GMT, Zhengyu Gu wrote:
>> Please review this change to the String Deduplication facility. It is being
>> changed to use OopStorage to hold weak references to relevant objects,
>> rather than bespoke data structures requiring dedicated processing phases by
>> supporti
On Wed, 28 Apr 2021 00:29:23 GMT, Ioi Lam wrote:
>> src/hotspot/share/classfile/stringTable.cpp line 784:
>>
>>> 782: SharedStringIterator iter(f);
>>> 783: _shared_table.iterate(&iter);
>>> 784: }
>>
>> So with this change (somewhere below) do you no longer deduplicate strings
>> from the
1 - 100 of 277 matches
Mail list logo
