Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Peter, Thank you for the explanation! -Dmitry On 2015-05-14 23:35, Peter Levart wrote: > > > On 05/14/2015 10:11 PM, Peter Levart wrote: >> Hi Dmitry, >> >> ReferenceQueue is not really a queue, but a LIFO stack. Scanner is >> walking the stack from top (the 'head') to bottom (the last element

JEP 254: Compact Strings

New JEP Candidate: http://openjdk.java.net/jeps/254 - Mark

Re: Updating existing JDK code to use InputStream.transferTo() (jdk)

Hello, Not providing a code review, but I wanted to state I think this is a very good sort of cleanup and worthwhile to get into the platform once the details have been worked through. Thanks, -Joe On 5/12/2015 3:10 PM, Patrick Reinhart wrote: Hi Pavel, Is there anything I can do in the m

Re: RFR(s): 8078463: optimize java/util/Map/Collisions.java

On 5/14/15 1:22 AM, Daniel Fuchs wrote: I'm curious: have you tried with using a lambda instead? changing: 394 static void check(String desc, boolean cond) { 395 if (cond) { 396 pass(); 397 } else { 398 fail(desc); 399 } 400 }

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

On 05/14/2015 10:11 PM, Peter Levart wrote: Hi Dmitry, ReferenceQueue is not really a queue, but a LIFO stack. Scanner is walking the stack from top (the 'head') to bottom (the last element pointing to itself). When poller(s) overtake the scanner, it actually means that the top of the stack

Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

On 05/13/2015 01:45 AM, Paul Sandoz wrote: On May 12, 2015, at 10:49 PM, Mandy Chung wrote: How likely does existing code do this? A proper way is to call System.setProperty. One pattern I found on System.setProperties is like this to add a system property of key/value pair: Properties p

Re: RFR(s): 8078463: optimize java/util/Map/Collisions.java

On 5/14/15 12:58 AM, Chris Hegarty wrote: Or could use jdk.testlibrary.Asserts.assertEquals, if you want to avoid spinning up the testng machinery, and generating yet another xml test report. If you are only interested in assertEquals. Unfortunately there are several assertions that aren't si

Re: RFR(s): 8078463: optimize java/util/Map/Collisions.java

Hi Martin, thanks for taking a look. It probably would be a good idea to convert this test (and a whole bunch of others) to Test-NG. However, that's more change than I want to bite off at this point, so I'd prefer to stick with my change as it stands right now. s'marks On 5/13/15 7:24 PM, Ma

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Hi Dmitry, ReferenceQueue is not really a queue, but a LIFO stack. Scanner is walking the stack from top (the 'head') to bottom (the last element pointing to itself). When poller(s) overtake the scanner, it actually means that the top of the stack has been eaten under scanner's feet while try

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Peter, Could we just bail out on r == r.next? It gives us less accurate result, but I suspect that If we restart from head we need to flush all counters. As far I understand queue poller removes items one by one from a queue end so if we overtaken by queue poller we can safely assume that we are

Re: RFR: 8080344: Incorrect GPL header

Thanks Lance! Joe On 5/14/2015 9:24 AM, Lance Andersen wrote: Looks fine Joe On May 14, 2015, at 12:21 PM, huizhe wang > wrote: Hi, The license header in these files contain an incorrect YEAR format, e.g. "Copyright (c) 2013 Oracle and/or its affiliates. Al

Re: [9] RFR: 8080342: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle

+1 On May 14, 2015, at 12:31 PM, Naoto Sato wrote: > Hello, > > Another GPL header fix. Please review. > > http://cr.openjdk.java.net/~naoto/8080342/webrev.00/ > > Naoto Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlingto

[9] RFR: 8080342: Incorrect GPL header causes RE script to miss swap to commercial header for licensee source bundle

Hello, Another GPL header fix. Please review. http://cr.openjdk.java.net/~naoto/8080342/webrev.00/ Naoto

Re: RFR: 8080344: Incorrect GPL header

Looks fine Joe On May 14, 2015, at 12:21 PM, huizhe wang wrote: > Hi, > > The license header in these files contain an incorrect YEAR format, e.g. > "Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved." where > the YEAR should have been "2013,". > > Please review: > http:/

RFR: 8080344: Incorrect GPL header

Hi, The license header in these files contain an incorrect YEAR format, e.g. "Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved." where the YEAR should have been "2013,". Please review: http://cr.openjdk.java.net/~joehw/jdk9/8080344/webrev/ Thanks, Joe

Re: AbstractList etc. functionality as interfaces with default methods?

> On May 14, 2015, at 7:24 AM, Remi Forax wrote: > > On 05/14/2015 03:05 PM, Brian Goetz wrote: Not only is there a problem with modCount, but also with equals/hashCode/toString. You can’t define these Object methods in an interface. >>> They could be defined as static methods t

Re: AbstractList etc. functionality as interfaces with default methods?

That's fine, not complaining, but as you say, it was a conscious design decision; alternative syntax could have been used to not make this ambiguous. Given that APIs try to be lean and only support minimal required functionality, "extensions" are bolted on via static helper methods, so having a wa

Re: AbstractList etc. functionality as interfaces with default methods?

No, it’s fundamental, and it was a conscious trade-off. The uniformity of using the same syntax for all flavors of method references outweighed the small number of collisions like this one. On May 14, 2015, at 10:06 AM, Vitaly Davidovich wrote: > That's an implementation detail not a fundam

Re: AbstractList etc. functionality as interfaces with default methods?

javac should emit a lint warning in these cases to help API designers. I have created 8080413 [1] to track that. Rémi [1] https://bugs.openjdk.java.net/browse/JDK-8080413 On 05/14/2015 04:04 PM, Brian Goetz wrote: The static-instance asymmetry cancels that one out. If you have class Foo {

Re: AbstractList etc. functionality as interfaces with default methods?

That's an implementation detail not a fundamental issue right? sent from my phone On May 14, 2015 10:04 AM, "Brian Goetz" wrote: > The static-instance asymmetry cancels that one out. If you have > > class Foo { > void m(int x) > static void m(Foo f, int x) > } > > Then Foo::x could eith

Re: AbstractList etc. functionality as interfaces with default methods?

The static-instance asymmetry cancels that one out. If you have class Foo { void m(int x) static void m(Foo f, int x) } Then Foo::x could either be an unbound mref to the instance method or a static mref. Even with a perfect target type (Foo, int) -> void, compiler will still report

Re: RFR 9: 8077350 Process API Updates Implementation Review

Hi Alan, For something to log from an inoperative destroy call, are you thinking it should throw an exception? In that case the return value could be void and the exception message could expose the OS specific reason. None of the currently available exceptions seem appropriate; A bare Runtim

Re: AbstractList etc. functionality as interfaces with default methods?

Ambiguous in isolation, but within context they're quite different: one takes an arg and the other is void. sent from my phone On May 14, 2015 9:25 AM, "Remi Forax" wrote: > > > On 05/14/2015 03:05 PM, Brian Goetz wrote: > >> Not only is there a problem with modCount, but also with equals/h

Re: AbstractList etc. functionality as interfaces with default methods?

On 05/14/2015 03:24 PM, Remi Forax wrote: On 05/14/2015 03:05 PM, Brian Goetz wrote: Not only is there a problem with modCount, but also with equals/hashCode/toString. You can’t define these Object methods in an interface. They could be defined as static methods to delegate to. From API c

Re: RFR 9: 8077350 Process API Updates Implementation Review

Hi Peter, On 5/14/15 8:19 AM, Peter Levart wrote: Hi Roger, The new API using Optional(s) looks fine. In particular for the ProcessHandle returning methods. They now either return Stream or Optional. At some point in the development of this API, the implementation introduced the AsyncExecu

Re: RFR: 8079459: JCK test api/java_nio/ByteBuffer/index.html#GetPutXXX start failing after JDK-8026049

On 05/13/2015 07:35 PM, Alan Bateman wrote: > > > A few passing comments on the test > - Is errors incremented anywhere? Oops. I realized after sending the email that I needed to strengthen the test. If one of the four {get,put} operations fails then all four should fail. I added a check for

Re: AbstractList etc. functionality as interfaces with default methods?

On 05/14/2015 03:05 PM, Brian Goetz wrote: Not only is there a problem with modCount, but also with equals/hashCode/toString. You can’t define these Object methods in an interface. They could be defined as static methods to delegate to. From API consistency perspective, we have for example

Re: AbstractList etc. functionality as interfaces with default methods?

>> Not only is there a problem with modCount, but also with >> equals/hashCode/toString. You can’t define these Object methods in an >> interface. > > They could be defined as static methods to delegate to. From API consistency > perspective, we have for example the following static methods on

Re: 8080330: (cs) Charset.availableCharsets failing with NPE on several platforms

The changes looks fine Alan. -Chris. On 14 May 2015, at 12:49, Alan Bateman wrote: > > This method is currently broken in jdk9/dev and is causing several test > failures. It looks like the changes JDK-8035302 missed a file. > > I need a Reviewer for the patch below. Additionally the > test/

Re: RFR 9: 8077350 Process API Updates Implementation Review

On 13/05/2015 16:10, Roger Riggs wrote: Hi Alan, Yes, the destroy use looks a bit odd. In Process, destroyForcibly returns this so that the application can fluently wait for the termination to complete. Returning Optional enables the case to fluently perform an action on the process when it

Re: RFR 9: 8077350 Process API Updates Implementation Review

Hi Roger, The new API using Optional(s) looks fine. In particular for the ProcessHandle returning methods. They now either return Stream or Optional. At some point in the development of this API, the implementation introduced the AsyncExecutor to execute synchronous continuations of the onE

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Small update in JDK code (webrev updated in place): http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02 Changes: - hid Context.dependencies field from Reflection - new test case: CallSiteDepContextTest.testHiddenDepField() Best regards, Vladimir Ivanov On 5/13/15 5:56 PM, Paul Sandoz w

8080330: (cs) Charset.availableCharsets failing with NPE on several platforms

This method is currently broken in jdk9/dev and is causing several test failures. It looks like the changes JDK-8035302 missed a file. I need a Reviewer for the patch below. Additionally the test/sun/nio/cs/TestCompoundTest.java can be removed. I'm sure Sherman will have suggestions for othe

Re: [9] RFR (M): 8079205: CallSite dependency tracking is broken after sun.misc.Cleaner became automatically cleared

Thanks, Roland. Best regards, Vladimir Ivanov On 5/13/15 4:47 PM, Roland Westrelin wrote: http://cr.openjdk.java.net/~vlivanov/8079205/webrev.02/ The hotspot code looks good to me. Roland.

Re: AbstractList etc. functionality as interfaces with default methods?

On 05/14/2015 03:16 AM, Brian Goetz wrote: Not only is there a problem with modCount, but also with equals/hashCode/toString. You can’t define these Object methods in an interface. They could be defined as static methods to delegate to. From API consistency perspective, we have for exampl

Re: Updating existing JDK code to use InputStream.transferTo()

Hi Pavel, On 14.05.2015 01:28, Pavel Rappo wrote: Let me start then. 1. I've seen several cases where current behaviour while ((n = in.read(buffer)) > 0) ~~~ has been changed to while ((read = this.read(buffer, 0, TRANSFER_BUFFER_SIZE)) >= 0)

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

I also have some comments on Dmitry's code... On 05/13/2015 11:52 PM, Derek White wrote: Hi Dmitry, Some review comments below... On 5/12/15 1:10 PM, Dmitry Samersoff wrote: Everybody, Updated version: http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.03/ Now it iterates over queue

Re: RFR [9] Add blocking bulk read to java.io.InputStream

I think we’ve agreed that we are not going to attempt to re-introduce the problematic interruptible I/O mechanism. These new methods are targeted at specific use-cases and common patterns found in code. I’d like to do a final review of the spec before finalising it. http://cr.openjdk.java.net

Re: RFR(s): 8078463: optimize java/util/Map/Collisions.java

Hi Stuart, On 5/14/15 3:44 AM, Stuart Marks wrote: Hi all, Please review this change to optimize a test. Basically the test did string formatting for every assertion, but the string was thrown away if the assertion passed -- the most common case. The change is to do the string formatting onl

Re: RFR(s): 8078463: optimize java/util/Map/Collisions.java

On 14 May 2015, at 03:24, Martin Buchholz wrote: > Your changes look good, Yes, this is a nice improvement. > but: > > 204 check(map.size() == i, "insertion: map expected size > m%d != i%d", map.size(), i); > > many of those detail messages look like leftovers from a long debuggi

Re: RFR(M,v3): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo

Hi Derek, On 05/13/2015 10:34 PM, Derek White wrote: Hi Peter, I don't have smoking gun evidence that your change introduces a bug, but I have some concerns... I did have a concern too, ... On 5/12/15 6:05 PM, Peter Levart wrote: Hi Dmitry, You iterate the queue then, not the unfinalize

Re: PriorityQueue

> You may have trouble finding someone with the same enthusiasm for this > constructor as yourself. This probably applies to many data structures that have specific (and rare) applications. A priority queue that takes a custom comparator seems like a pretty frequent (algorithmic) use case to me,