Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

On Nov 24, 2015, at 6:17 AM, Aleksey Shipilev wrote: > > Oh no, I don't. Pre-integration JPRT runs exposed an opaque dependency > on Integer.sizeTable field from C2 OptimizeStringConcat. I added the > field declaration back: >

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Daniel, I like proposed #3 solution too. Usually is best to not allow "poisoning the well". This will really help me out with supporting older platforms and keeping the code smell to a minimum. Thanks for taking this on, Jason From: Daniel Fuchs

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

This is as far as I got before I got interrupted: http://cr.openjdk.java.net/~mikael/NioBenchmark.java I haven't had time yet to verify that the benchmark code even measures the right thing, much less figure out why I get the performance impact with my fix. I can see many reasons why that

Re: Deprecation of LogRecord.getMillis in JDK9

I think #3 or a variation is best. Clearly, #1 is inconsistent and simply documenting it (#2) isn't much better. I'd recommend making setInstant() be more explicit about the range of Instant values that are allowed, namely those created from Instant.ofEpochMilli(long), which allows +/- 292

Re: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

Hi Roger, On 12/1/2015 6:05 PM, Roger Riggs wrote: Hi Joe, I do not know of any specific skew issues at the resolutions used. For example, Linux records the start time in ticks (1/60th to 100th of a second), not the full resolution of the time of day clock. Typically, the child start time

RFR(m): updated: JEP 269 initial API and skeleton implementation (JDK-8139232)

and Set): http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html Webrev: http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/ Thanks, s'marks

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

On Nov 25, 2015, at 3:21 AM, Peter Levart wrote: > > The mentioning of "reference component types" in javadoc for > vectorizedMismatch: > > 52 /** > 53 * Find the relative index of the first mismatching pair of elements > in two > 54 * arrays of the

Re: RFR: 8144214 Some log messages will be discarded when VM is bootstrapping.

On 2015/12/1 18:32, Daniel Fuchs wrote: Hi Hamlin, I see that you're going to push a test for this with JDK-8144215; I will also ask for your help to push the test code after the test pass the open review. Looks good to me. Do you need a sponsor for this fix? Hi Daniel, Yes, I need a

RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

Please review this change in ProcessHandle to validate parent pids provided by the OS. Children of a process have start times that are the same or later than the parent. The implementation of descendants(), and children(), and getParent() are updated to validate the parent pid. The problem is

Re: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

Hi Joe, I do not know of any specific skew issues at the resolutions used. For example, Linux records the start time in ticks (1/60th to 100th of a second), not the full resolution of the time of day clock. Typically, the child start time is at least a bit later than the parent. If the

Re: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

Hi Roger, Looks fine. Do you know if there are clock skew issues to be concerned with if the parent and child are spawned on different CPUs? Thanks, -Joe On 12/1/2015 5:49 PM, Roger Riggs wrote: Please review this change in ProcessHandle to validate parent pids provided by the OS.

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

I reviewed 8143355 today and my main question is where are range checks? Thanks, Vladimir On 11/25/15 1:53 AM, Paul Sandoz wrote: Hi, And this is the review for the Java part: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/ Which will be

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Value-based is a property of types, not of instances. For disclaimers regarding the result of factory methods, it seems clearer to go to the traditional "make no assumptions about the type, mutability, serializability, or identity..." sort of language. On 11/25/2015 7:37 PM, Stuart Marks

RE: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

That makes sense (and it's consistent with my layman's interpretation that List as a value-based is weird). In this particular case, I believe Stuart does want to make explicit claims for immutability and serializability. In the case of the empty methods, I don't see why a strong claim about

Re: RFR:JDK-8144349: @since tag missed

Those are not the right methods on LocalDate and LocalTime Stephen On 1 December 2015 at 16:50, nadeesh tv wrote: > Hi all, > Please review a fix for >BugID - https://bugs.openjdk.java.net/browse/JDK-814434 >Issue - while fixing JDK-8071919, JDK-8133079 I

RFR:JDK-8144349: @since tag missed

Hi all, Please review a fix for BugID - https://bugs.openjdk.java.net/browse/JDK-814434 Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add @since 9 tag. webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/ -- Thanks and Regards, Nadeesh TV

Re: RFR:8143413:add toEpochSecond methods for efficient access

On 12/1/15 6:36 AM, Stephen Colebourne wrote: As Roger says, these new methods are about performance as well as conversion. While I fully acknowledge the time methods make an assumption, it is not a crazy one, after all 1970-01-01 is just zero. Key I think is it allows: long epochSecs =

Re: RFR(xxs): 8143858: typo in Timer.purge() doc

Look good, -Joe On 12/1/2015 10:25 PM, Stuart Marks wrote: Hi all, Please review this tiny fix for a typo in the the documentation of the Timer.purge() method. Diff appended below. Thanks! s'marks # HG changeset patch # User smarks # Date 1449025313 28800 # Tue Dec 01 19:01:53 2015

RFR(xxs): 8143858: typo in Timer.purge() doc

Hi all, Please review this tiny fix for a typo in the the documentation of the Timer.purge() method. Diff appended below. Thanks! s'marks # HG changeset patch # User smarks # Date 1449025313 28800 # Tue Dec 01 19:01:53 2015 -0800 # Node ID 01aa186248334bf669f075dd7913391b07387747 #

Re: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

Hi Daniel, Thanks for the review, I follow you suggestion to create a new RFE https://bugs.openjdk.java.net/browse/JDK-8144460 to track the pushing for this new test. webrev : http://cr.openjdk.java.net/~mli/8144460/webrev.01/ old one is moved to

Re: RFE Pre-review: Support for cloning exceptions

I very much want object copying to be simple and easy, but Cloneable has been under a cloud for a very long time and Effective Java Item 11 advises to stay away from it. Josh writes: """Given all of the problems associated with Cloneable, it’s safe to say that other interfaces should not extend

Re: [9] RFR of 8032027: Add BigInteger square root methods

Hi Brian, On 11/30/2015 3:24 PM, Brian Burkhalter wrote: Hi Joe, On Nov 29, 2015, at 10:01 AM, joe darcy > wrote: The "if (...) " logic that is repeated a few times in this method could be pulled out into its own method, possibly one

Re: RFR:JDK-8144349: @since tag missed

Hi , Sorry. I made a mistake. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8144349/webrev.01 Regards, Nadeesh On 12/1/2015 10:24 PM, Stephen Colebourne wrote: Those are not the right methods on LocalDate and LocalTime Stephen On 1 December 2015 at 16:50, nadeesh tv

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, Stuart, Here is a potential fix for the issue: http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html

Re: RFR:JDK-8144349: @since tag missed

Hi Nadeesh, Thanks for the correction, looks fine. Reviewed, Roger p.s. I can sponsor that and get it integrated On 12/1/2015 1:38 PM, nadeesh tv wrote: Hi , Sorry. I made a mistake. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8144349/webrev.01 Regards, Nadeesh On

Re: RFR: 8143131: Remove unused code from java.lang.invoke

CDE = Code Deletion Engineering. Yes! Reviewed. — John On Dec 1, 2015, at 8:06 AM, Claes Redestad wrote: > > Hi, > > please review this patch to cleanup various things in and around > java.lang.invoke: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 >

RE: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

Hi Paul, Tests in hotspot/test/runtime needs to be jtreg tests. Looking at your tests, I can't see a reason why they can't easily be modified to be jtreg tests instead? (adding the hotspot-dev mail alias) Thanks, Christian -Original Message- From: hotspot-compiler-dev

Re: RFR: 8143131: Remove unused code from java.lang.invoke

John, Michael, thanks for reviewing! /Claes On 2015-12-01 19:53, John Rose wrote: CDE = Code Deletion Engineering. Yes! Reviewed. — John On Dec 1, 2015, at 8:06 AM, Claes Redestad wrote: Hi, please review this patch to cleanup various things in and around

Re: RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting

Looks good and sorry for the delay. Thanks, /Staffan > On 24 nov. 2015, at 20:13, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/ >> 3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg > > Hi, > > Could you please review the

Unexpected BindException in Endpoint.publish

Hi Miroslav and all, Could you please review the below issue and patch? I got the advice by Alan at net-dev. So I want to ask you. http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK community. This's

Re: [PING] RFR 6425769: jmx remote bind address

On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev with jtreg test in Java: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

> On 30 Nov 2015, at 23:33, Paul Sandoz wrote: > > >> On 30 Nov 2015, at 23:05, Christian Tornqvist >> wrote: >> >> Because jtreg is the test framework that we use, we've been working hard to >> reduce the number of test frameworks

Re: RFR: 8144214 Some log messages will be discarded when VM is bootstrapping.

Hi Hamlin, I see that you're going to push a test for this with JDK-8144215; Looks good to me. Do you need a sponsor for this fix? best regards, -- daniel On 30/11/15 12:28, Hamlin Li wrote: Hi all, Would you please help to review for http://cr.openjdk.java.net/~mli/8144214/webrev.00/,

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

> On 1 Dec 2015, at 03:58, Gil Tene wrote: > > Update: After some significant back-and-forth between Doug and I on naming > and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what > we think is a good spec and name selection for this thing. We're proposing

Re: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

Hi Hamlin, You should probably create a new open RFE for pushing this new test. I'm not sure we can use internal task ids in commit/push comments. From looking at the test, it would be preferable to create the loggers after setting up the stub that pretend that the VM is not yet booted. In

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

On 26 Nov 2015, at 12:00, Aleksey Shipilev wrote: > On 11/26/2015 12:55 PM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/ > > Both JDK and

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Stuart, Thanks for the feedback! On 30/11/15 23:53, Stuart Marks wrote: Hi all, Thanks for considering JEP 277 in this discussion. It's far from being finalized at this point, but SUPERSEDED seems like the most likely of the deprecation reasons from the proposal that would be applied here.

RFR: 8143131: Remove unused code from java.lang.invoke

Hi, please review this patch to cleanup various things in and around java.lang.invoke: Bug: https://bugs.openjdk.java.net/browse/JDK-8143131 Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/ /Claes

RFE Pre-review: Support for cloning exceptions

Hi, There are at least two places in java.util.concurrent where it would be beneficial if java.lang.Throwable was Cloneable: - ForkJoinTask::getException() returns original exception thrown by the computation of the task when the task is completed exceptionally. The same exception is

Re: [PING] RFR 6425769: jmx remote bind address

On 1.12.2015 11:17, Severin Gehwolf wrote: On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: Hi, Updated webrev with jtreg test in Java: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/ bug:

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Minor quibble, but why the "on" prefix in the name? Maybe just me, but onXYX is typically used for event notification style APIs. Also, the "wait" part seems inappropriate as the method itself isn't doing any waiting. What was wrong with the original spinLoopHint name? Or cpuRelax()? sent from

ClassFileTransformer does not apply to anonymous classes

Hello everybody, classes that are loaded via Unsafe::defineAnonymousClass are not transformed by a registered ClassFileTransformer. At the same time, it is possible to retransform / redefine such an anonymous classes using the instrumentation API. Here is a rather confusing bug that I

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 12/01/2015 05:36 AM, Paul Sandoz wrote: On 1 Dec 2015, at 03:58, Gil Tene wrote: class Runtime { /... /** * Method signifying that the caller is momentarily unable to * progress until the occurrence of one or more actions of one or * more other

Re: RFR:8143413:add toEpochSecond methods for efficient access

As Roger says, these new methods are about performance as well as conversion. While I fully acknowledge the time methods make an assumption, it is not a crazy one, after all 1970-01-01 is just zero. Key I think is it allows: long epochSecs = date.toEpochSeconds(offset) +

Re: [PING] RFR 6425769: jmx remote bind address

Hi Jaroslav, On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote: > On 1.12.2015 11:17, Severin Gehwolf wrote: > > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote: > > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Updated webrev with

Re: RFR:8143413:add toEpochSecond methods for efficient access

Hi Sherman, On 11/30/2015 6:09 PM, Xueming Shen wrote: On 11/30/2015 01:26 PM, Stephen Colebourne wrote: Converting LocalDate<-> java.util.Date is the question with the largest number of votes on SO:

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Hi Dan, Thank you for your detailed review. My answers are in-lined below. New webrev: http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/ On 24/11/2015 17:26, Daniel D. Daugherty wrote: src/cpu/sparc/vm/frame_sparc.cpp (old) L635: if (fp() - sp() > 1024 +

Re: RFR: 8143131: Remove unused code from java.lang.invoke

Hi Claes, note that this is a lower-case review: thumbs up. Good catches! Thanks! :-) Best, Michael > Am 01.12.2015 um 17:06 schrieb Claes Redestad : > > Hi, > > please review this patch to cleanup various things in and around > java.lang.invoke: > > Bug: