Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

On 10/31/17 4:07 PM, Peter Levart wrote: Hi Mandy, Sherman, Roger, On 10/31/17 00:25, mandy chung wrote: I played a little with an idea of how such additional Cleaner API might look like. Here's what I came up with, together with how this would apply to ZipFile/Inflater/Deflater: http://

Re: ThreadPoolExecutor and finalization

Hi Stuart, Jumping to the end ... On 1/11/2017 6:37 AM, Stuart Marks wrote: On 10/30/17 10:21 AM, Martin Buchholz wrote: The initiative is to identify and remediate existing uses of finalization in the JDK. I've been skeptical about this initiative as stated.  I would not have deprecated fi

Re: ThreadPoolExecutor and finalization

Hi Roger, On 31/10/2017 11:58 PM, Roger Riggs wrote: Hi Peter, Only native resources that do not map to the heap allocation/gc cycle need any kind of cleanup.  I would work toward a model that encapsulates the reference to a native resource with a corresponding allocation/release mechanism as

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Having a List.of(List) copy constructor would save an additional array copy in the collector Which uses (List)List.of(list.toArray()) Gruss Bernd -- http://bernd.eckenfels.net From: core-libs-dev on behalf of Stuart Marks Sent: Wednesday, November 1, 2017 12:4

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Updated webrev, based on comments from Brian and Roger: http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/ s'marks On 10/30/17 3:50 PM, Stuart Marks wrote: (also includes 8184690: add Collectors for collecting into unmodifiable List, Set, and Map) Hi all, Here's an updated we

Re: RFR Re: [PATCH] 8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics

Hi Paul, On 10/30/2017 9:33 PM, Paul Sandoz wrote: Hi, On 30 Oct 2017, at 17:19, Joseph D. Darcy wrote: Hello, Is it intentional that "DoubleSummaryStatistics" is used in a sentence like 91 * @apiNote 92 * The enforcement of argument correctness means that the retrieved s

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Peter, After tried couple implementations it seems the most reasonable approach is to use the coding pattern you suggested to move all pieces into ZSStream Ref. Given we are already using the internal API CleanerFactory it is attractive to go a little further to subclass PhantomCleanable di

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 10/31/17 11:24 AM, Roger Riggs wrote: Hi Stuart, Collection.java: The mix of "should" and "must" in Collection.java can be confusing. Typically "should" is interpreted as "must" from a conformance point of view. "Must" is a requirement, and "should" is a recommendation to implementors, a

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Mandy, Sherman, Roger, On 10/31/17 00:25, mandy chung wrote: On 10/30/17 1:49 PM, Peter Levart wrote: ...above example lends itself as a use case for the following equivalent alternative using internal low-level API where ZStreamRef becomes the Cleanable itself: class ZStreamRef exten

Re: [10] RFR 8186046 Minimal ConstantDynamic support

> On 31 Oct 2017, at 14:43, mandy chung wrote: > > > > On 10/26/17 10:03 AM, Paul Sandoz wrote: >> Hi, >> >> Please review the following patch for minimal dynamic constant support: >> >> >> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ >> >>

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Thanks for the review. Editorial comments accepted. Discussion and responses to some items below. On 10/31/17 7:25 AM, Brian Goetz wrote: Returns an unmodifiable Map containing the entries 1664 * of the given Map. the given Map must not be null, and it must not contain any 1665 * null keys o

Re: [10] RFR 8186046 Minimal ConstantDynamic support

On 10/26/17 10:03 AM, Paul Sandoz wrote: Hi, Please review the following patch for minimal dynamic constant support: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/

Re: RFR: JDK-8190439 - Removal of newrmic

On 31/10/2017 19:28, Lance Andersen wrote: Hi all, Please review the webrev which removes newrmic as newrmic is not used. The webrev can be found at http://cr.openjdk.java.net/~lancea/8190439/webrev.00/ Looks fine. As you found, it was disabled in JDK 9 and probably should have been remo

Re: ThreadPoolExecutor and finalization

On 10/30/17 10:21 AM, Martin Buchholz wrote: The initiative is to identify and remediate existing uses of finalization in the JDK. I've been skeptical about this initiative as stated. I would not have deprecated finalize(). We will never remove finalize() from the JDK, and I don't see how sw

Re: RFR: JDK-8190439 - Removal of newrmic

Ditto:  +1 On 10/31/2017 4:06 PM, mandy chung wrote: On 10/31/17 12:28 PM, Lance Andersen wrote: Hi all, Please review the  webrev which removes newrmic as newrmic is not used. The webrev can be found at http://cr.openjdk.java.net/~lancea/8190439/webrev.00/ +1 Mandy

Re: RFR 8190441: ProblemList some intermittent CORBA tests

+1 -Joe On 10/31/2017 1:07 PM, Lance Andersen wrote: Looks good roger On Oct 31, 2017, at 4:05 PM, Roger Riggs wrote: Please review some additions to the ProblemList.txt for intermittent CORBA tests. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemLi

Re: RFR 8190441: ProblemList some intermittent CORBA tests

Looks good roger > On Oct 31, 2017, at 4:05 PM, Roger Riggs wrote: > > Please review some additions to the ProblemList.txt for intermittent CORBA > tests. > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@

Re: RFR: JDK-8190439 - Removal of newrmic

On 10/31/17 12:28 PM, Lance Andersen wrote: Hi all, Please review the webrev which removes newrmic as newrmic is not used. The webrev can be found at http://cr.openjdk.java.net/~lancea/8190439/webrev.00/ +1 Mandy

RFR 8190441: ProblemList some intermittent CORBA tests

Please review some additions to the ProblemList.txt for intermittent CORBA tests. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -315,8 +315,12 @@ sun/tools/jhsdb/heapconfig/JMapHeapConfi  com/sun/jndi/ldap/DeadS

Re: [10] RFR 8186046 Minimal ConstantDynamic support

Lois identified and fixed a bug found when running the JCK VM tests. I merged the changes below into the current webrev. Paul. --- old/src/hotspot/share/interpreter/linkResolver.cpp 2017-10-31 11:56:30.541287505 -0400 +++ new/src/hotspot/share/interpreter/linkResolver.cpp 2017-10-31 11:56:29

RFR: JDK-8190439 - Removal of newrmic

Hi all, Please review the webrev which removes newrmic as newrmic is not used. The webrev can be found at http://cr.openjdk.java.net/~lancea/8190439/webrev.00/ Best Lance

Re: RFR Re: [PATCH] 8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics

While I agree that the overflow-detecting constraint on min/max in the early version was too aggressive, you could reasonably choose to enforce the constraint that if count == 0, then so should sum, min, and max. On 10/30/2017 6:49 PM, Paul Sandoz wrote: Hi Chris, After some hiatus here is an

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Hi Stuart, Collection.java: The mix of "should" and "must" in Collection.java can be confusing. Typically "should" is interpreted as "must" from a conformance point of view. For example, 147 * An unmodifiable collection is a collection, all of whose 148 * mutator methods (as defined above) ar

Re: [10] RFR 8186046 Minimal ConstantDynamic support

> On 31 Oct 2017, at 05:58, Dmitry Samersoff > wrote: > > Paul and Frederic, > > Thank you. > > One more question. Do we need to call verify_oop below? > > 509 { // Check for the null sentinel. > ... > 517 xorptr(result, result); // NULL object reference > ... > > 521 if (VerifyOo

Re: RFR JDK-8185582, Update Zip implementation to use Cleaner, not finalizers

Hi Sherman, On 10/31/17 00:32, Xueming Shen wrote: On 10/30/2017 01:34 PM, Peter Levart wrote: The Inflater and Deflater now look fine (except you don't have to check for cleanable != null any more in Inflater.end()). But what shall we do with ZipFile? Peter, The fundamental issue here

Re: RFR: 8190287: Update JDK's internal ASM to ASMv6

Hi Remi, Are you ok with the ASMv6 changes ? Thanks Kumar On 10/27/2017 10:12 AM, Kumar Srinivasan wrote: Hello Remi, Sundar and others, Please review the webrev [1] to update JDK's internal ASM to v6. To help with review areas, you can use the browser to search for mq patches commented wit

Re: [10] RFR 8186046 Minimal ConstantDynamic support

Paul, templateTable_x86.cpp: 564 const Register flags = rcx; 565 const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1); Should we use another register for rarg under NOT_LP64 ? -Dmitry On 10/26/2017 08:03 PM, Paul Sandoz wrote: > Hi, > > Please review the following patch for minimal d

Re: [10] RFR 8186046 Minimal ConstantDynamic support

Paul and Frederic, Thank you. One more question. Do we need to call verify_oop below? 509 { // Check for the null sentinel. ... 517 xorptr(result, result); // NULL object reference ... 521 if (VerifyOops) { 522 verify_oop(result); 523 } -Dmitry On 31.10.2017 00:56, Frederic

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

In "View Collections" Most collections contain elements themselves. By contrast, view collections 112 * themselves do not contain elements, but instead rely on a backing collection to 113 * store the actual elements. This should be: "most collections manage the storage for the elements they

Re: ThreadPoolExecutor and finalization

Hi Peter, Most of the discussion is in: https://bugs.openjdk.java.net/browse/JDK-6399443. The linked issue in that report then links to the CI mail thread. Jason >I'm trying to understand the purpose of finalize() in TPE, but can't. >I'm surely missing something. If the pool is no longer refe

Re: ThreadPoolExecutor and finalization

Hi Peter, Only native resources that do not map to the heap allocation/gc cycle need any kind of cleanup.  I would work toward a model that encapsulates the reference to a native resource with a corresponding allocation/release mechanism as you've described here and in the thread on zip. For

Re: ThreadPoolExecutor and finalization

Hi David, On 10/31/2017 12:37 AM, David Holmes wrote: Hi Roger, On 31/10/2017 12:43 AM, Roger Riggs wrote: Hi David, On 10/30/2017 3:31 AM, David Holmes wrote: Hi Andrej, On 30/10/2017 5:02 PM, Andrej Golovnin wrote: Hi David, On 30. Oct 2017, at 01:40, David Holmes wrote: Hi Roger,

Re: ThreadPoolExecutor and finalization

On 10/31/2017 04:55 AM, David Holmes wrote: > > In 2006 we added the docs about it being unreferenced and no remaining > threads - which I guess is a necessary condition for finalization to now > occur. But as you noted at that point shutdown() is pretty much a no-op. > > Maybe Doug (cc'd) can r

Re: ThreadPoolExecutor and finalization

Hi, Here are some of my thoughts... On 10/31/17 05:37, David Holmes wrote: Hi Roger, On 31/10/2017 12:43 AM, Roger Riggs wrote: Hi David, On 10/30/2017 3:31 AM, David Holmes wrote: Hi Andrej, On 30/10/2017 5:02 PM, Andrej Golovnin wrote: Hi David, On 30. Oct 2017, at 01:40, David Holmes

Re: ThreadPoolExecutor and finalization

Hi Peter, cc'ing Doug Lea On 31/10/2017 6:25 PM, Peter Levart wrote: Hi David, On 10/31/17 08:45, David Holmes wrote: The docs for TPE cover this in detail: [1] Finalization     A pool that is no longer referenced in a program AND has no remaining threads will be shutdown automatically. If

Re: ThreadPoolExecutor and finalization

Hi David, On 10/31/17 08:45, David Holmes wrote: The docs for TPE cover this in detail: [1] Finalization     A pool that is no longer referenced in a program AND has no remaining threads will be shutdown automatically. If you would like to ensure that unreferenced pools are reclaimed even if

Re: ThreadPoolExecutor and finalization

On 31/10/2017 5:36 PM, Peter Levart wrote: On 10/31/17 05:12, David Holmes wrote: On 31/10/2017 1:02 AM, David Lloyd wrote: On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs wrote: ThreadPoolExecutor has a responsibility to cleanup any native resources it has allocated (threads) and it should be f

Re: ThreadPoolExecutor and finalization

Hi, On 10/31/17 05:12, David Holmes wrote: On 31/10/2017 1:02 AM, David Lloyd wrote: On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs wrote: ThreadPoolExecutor has a responsibility to cleanup any native resources it has allocated (threads) and it should be free to use whatever mechanism is appro