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

On Wed, Nov 25, 2015 at 2:52 PM, wrote: > Have you looked anything at the performance of the generated code? No. I looked at the emitted code, saw 'MOVQDU' instruction being used (it was 'MOVQDA' before that resulted in alignment error), and concluded that the compiler knows what it's doing :-)

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

Hi all, Would you please help to review the test development of JDK-8144215 : Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service. webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/ Thank y

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

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 to add a new static method to the Runtime class: class Runtime { /.

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

Another comment below... On 11/27/2015 6:36 AM, Magnus Ihse Bursie wrote: On 2015-11-25 02:54, Iris Clark wrote: Hi. Please review the new classes jdk.Version and jdk.OracleVersion. These are simple Java APIs to parse, validate, and compare version numbers. Bug 8072379: Implement

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

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 structured a bit differently to > return the number of errors. > > I think it would be acceptable to push the test

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

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: http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 The proposed method is designed to make the conversi

Re: Deprecation of LogRecord.getMillis in JDK9

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. While it seems that getMillis() is merely a convenience method for calling

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

> 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 in use. > jtreg comes bundled with testng so what is there to reduce? It’s being used more and more core library te

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

Because jtreg is the test framework that we use, we've been working hard to reduce the number of test frameworks in use. Thanks, Christian - Original Message - From: paul.san...@oracle.com Cc: hotspot-compiler-...@openjdk.java.net, core-libs-dev@openjdk.java.net Sent: Monday, November 30

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

> On 30 Nov 2015, at 22:17, Christian Tornqvist > wrote: > > Hi Paul, > > >>> Tests don't think we use testng with any hotspot tests so not sure >>> about that part. >> >> There are already quite a few, primarily in the serviceability area, search >> for “testng”. > > We don't use te

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

Converting LocalDate <-> java.util.Date is the question with the largest number of votes on SO: http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 The proposed method is designed to make the conversion easier. It also plugs an obvious gap in the API.

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

Hi Paul, >> Tests don't think we use testng with any hotspot tests so not sure >> about that part. > >There are already quite a few, primarily in the serviceability area, search >for “testng”. We don't use testng for our runtime tests, please change these into normal jtreg tests. Thanks

Re: RFR: JDK-8142936:Additional java.time.Duration methods

This is all about fixing a messy API that was created in 8. The methods propose are all about consistency. The toSeconds() method completes the set. For each unit there is a toXxx() and a toXxxPart(). Missing one out makes everything worse. Stephen On 30 November 2015 at 19:02, Roger Riggs wrot

Re: RFR (JAXP): 8142463: Xml schema validation failing after Xerces update; maxOccurs ignored

Looks OK Joe Best Lance On Nov 30, 2015, at 2:33 PM, huizhe wang wrote: > Hi, > > This is a quick one-line fix. > > For the UPA [1] processing, the DFA was compacted. A flag > (fIsCompactedForUPA) was added to indicate whether the DFA was compacted. In > the previous update however, the line

RFR (JAXP): 8142463: Xml schema validation failing after Xerces update; maxOccurs ignored

Hi, This is a quick one-line fix. For the UPA [1] processing, the DFA was compacted. A flag (fIsCompactedForUPA) was added to indicate whether the DFA was compacted. In the previous update however, the line that set the flag was missed. This fix recovers the previous update. All tests pass

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

On 11/30/2015 10:37 AM, Stephen Colebourne wrote: This is based on user difficulties picked up via Stack Overflow. These methods aim to provide a simpler and faster approach, particularly for cases converting to/from java.util.Date. Can you be a little more specific on this one? We now have Inst

Re: RFR: JDK-8142936:Additional java.time.Duration methods

Hi Stephen, Nadeesh, The toXXXPart methods look fine. I'm not entirely convinced that the toSeconds() method is worth it and may be deemed as confusing with the new toSecondsPart method. How many people have problems with getSeconds()? The toXXXPart tests could have used a single DataProvider

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

This is based on user difficulties picked up via Stack Overflow. These methods aim to provide a simpler and faster approach, particularly for cases converting to/from java.util.Date. For the time cases, the convention of 1970-01-01 is natural and commonly used in many codebases. Stephen On 30

Re: Deprecation of LogRecord.getMillis in JDK9

On 30/11/15 18:43, Roger Riggs wrote: Hi Daniel, I think it makes sense to keep getMillis (and document it) as a convenience method. Thanks Roger, Jason, I logged https://bugs.openjdk.java.net/browse/JDK-8144262 best regards, -- daniel Roger On 11/30/2015 12:25 PM, Daniel Fuchs wrote:

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, On 30/11/15 18:57, Jason Mehrens wrote: Sure. I'm just trying to pick a path forward so that in X years when someone does code review (like my future self) can avoid, "What was this guy thinking calling such a SUPERSEDED, DANGEROUS, and CONDEMNED method?" when confronted with using

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

Hi, While it is kinda understandable to have LocalDate.toEpochSecond(...) to get the epoch seconds since 1970.1.1, with the assumption of the time is at the midnight of that day. It is strange to have the Local/OffsetTime to have two public methods with the assumption of the "date" is at epoch ye

Re: Deprecation of LogRecord.getMillis in JDK9

Sure. I'm just trying to pick a path forward so that in X years when someone does code review (like my future self) can avoid, "What was this guy thinking calling such a SUPERSEDED, DANGEROUS, and CONDEMNED method?" when confronted with using getMillis. I would assume JEP 277 would mark getMil

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Daniel, I think it makes sense to keep getMillis (and document it) as a convenience method. Roger On 11/30/2015 12:25 PM, Daniel Fuchs wrote: On 30/11/15 18:04, Jason Mehrens wrote: Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps w

Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, To complete my earlier reply: On 30/11/15 18:25, Daniel Fuchs wrote: If it can't be undeprecated what is the proper way to target support as low as JDK7 but might end up executing on JDK9? Well - a lib using LogRecord.getMillis() could use @SuppressWarnings("deprecation') when calli

Re: Deprecation of LogRecord.getMillis in JDK9

On 30/11/15 18:04, Jason Mehrens wrote: Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use getInstant

RE: RFR 8124977 cmdline encoding challenges on Windows

Hi Kumar, Please find updated webreview here: http://cr.openjdk.java.net/~kshoop/8124977/webrev.04/ Thanks, Vladimir. -Original Message- From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com] Sent: Sunday, November 22, 2015 8:14 AM To: Martin Sawicki Cc: Kirk Shoop ; Vladimir Sh

Deprecation of LogRecord.getMillis in JDK9

Hi Daniel, When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps was commited the LogRecord.getMillis() method was marked as deprecated with the reason "To get the full nanosecond resolution event time, use getInstant". I can see marking LogRecord.setMillis

PoC for JDK-4347142: Need method to set Password protection to Zip entries

Hi all, Our customers have to handle password-protected zip files. However, Java SE does not provide the APIs to handle it yet, so we must use third party library so far. Recently, we found JDK-4347142: "Need method to set Password protection to Zip entries", and we tried to implement it. The cu

Re: Reference.reachabilityFence

On 30/11/15 12:41, Paul Sandoz wrote: On 30 Nov 2015, at 12:48, Chris Hegarty wrote: I looked at the jdk webrev, looks fine. Out of curiosity, what is the point of running the test with -Xint? Does it verify anything useful? It tests our assumptions are correct about the interpreter tha

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 2015-11-30 16:37, Alan Bateman wrote: On 30/11/2015 11:54, Chris Hegarty wrote: On 30/11/15 11:31, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8143926/webrev.03 This looks ok to me Claes. This version looks okay to me too although the /*package-private*/ comments are a b

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 30/11/2015 11:54, Chris Hegarty wrote: On 30/11/15 11:31, Claes Redestad wrote: On 2015-11-30 11:38, Chris Hegarty wrote: I'm OK with moving these utility methods to a more neutral place, but since the BytecodeDescriptor utilities are public for now, maybe this should be a follow-up once/if

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

> On 25 Nov 2015, at 10:53, 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 updated to add @HotSpotIntrinsicCandidate when JDK-8143355 is > pushed

Re: RFC: AbstractStringBuilder sharing its buffer with String

On 11/30/2015 03:19 PM, Vitaly Davidovich wrote: Hi Peter, I see your point about someone deliberately doing this to break String invariants. But by this logic, everything should be "threadsafe" in case someone attempts to break it via concurrency. Anything related to security, yes. R

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

The method Javadoc (specs) for each of the three new methods needs to be enhanced. For the date ones it needs to say "The resulting date will have a time component of midnight at the start of the day." For the time ones it needs to say "The resulting time will be on 1970-01-01." Some of the line

Re: RFR: JDK-8142936:Additional java.time.Duration methods

I think thats ready to be merged, thanks Stephen On 30 November 2015 at 11:26, nadeesh tv wrote: > Hi all, > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8142936/webrev.02/ > Regards, > Nadeesh TV > > On 11/27/2015 11:20 PM, Stephen Colebourne wrote: >> >> "Overall, looks prett

Re: RFC: AbstractStringBuilder sharing its buffer with String

Hi Peter, I see your point about someone deliberately doing this to break String invariants. But by this logic, everything should be "threadsafe" in case someone attempts to break it via concurrency. sent from my phone On Nov 28, 2015 7:19 PM, "Peter Levart" wrote: > > > On 11/28/2015 08:19 PM

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Aleksey, > Yes, thanks for more polishing, I have uploaded the updates to: > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.06/ Maybe one more: 1342 Class[] cls = new Class[cnt]; 1343 for (int i = 0; i < cnt; i++) { 1344

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Yes, thanks for more polishing, I have uploaded the updates to: http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.06/ http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.04/ More reviews, please! Thanks, -Aleksey On 11/30/2015 12:34 PM, Andrej Golovnin wrote: > Hi Aleksey, > >> ht

Re: Reference.reachabilityFence

> On 30 Nov 2015, at 12:48, Chris Hegarty wrote: > > I looked at the jdk webrev, looks fine. > > Out of curiosity, what is the point of running the test with > -Xint? Does it verify anything useful? > It tests our assumptions are correct about the interpreter that finalisation should not occ

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 30/11/15 11:35, Peter Levart wrote: ... Wouldn't it be nice to offer this often needed functionality as a public API? It would fit naturally on the java.lang.Class as an instance method. I don't have a strong opinion either way on this. I'm ok with Claes proceeding with this bug as is. Any

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 30/11/15 11:31, Claes Redestad wrote: On 2015-11-30 11:38, Chris Hegarty wrote: I'm OK with moving these utility methods to a more neutral place, but since the BytecodeDescriptor utilities are public for now, maybe this should be a follow-up once/if these classes become properly encapsulated

RFR:8143413:add toEpochSecond methods for efficient access

Hi all, Please review a fix for Bug Id -https://bugs.openjdk.java.net/browse/JDK-8143413 Issue - add toEpochSecond methods for efficient access webrev - http://cr.openjdk.java.net/~ntv/8143413/webrev.01/

Re: Reference.reachabilityFence

I looked at the jdk webrev, looks fine. Out of curiosity, what is the point of running the test with -Xint? Does it verify anything useful? -Chris. On 26/11/15 16:22, Paul Sandoz wrote: Hi, I have updated the patches: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8133348-reachability-fenc

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 11/30/2015 11:38 AM, Chris Hegarty wrote: On 29/11/15 16:42, Claes Redestad wrote: On 2015-11-29 17:18, Alan Bateman wrote: On 29/11/2015 14:30, Claes Redestad wrote: On 2015-11-25 16:23, Aleksey Shipilev wrote: On 11/25/2015 06:14 PM, Claes Redestad wrote: Inlining the isPrimitive chec

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 2015-11-30 11:38, Chris Hegarty wrote: I'm OK with moving these utility methods to a more neutral place, but since the BytecodeDescriptor utilities are public for now, maybe this should be a follow-up once/if these classes become properly encapsulated? I see that BytecodeDescriptor has meth

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

Hi all, Would you please help to review for http://cr.openjdk.java.net/~mli/8144214/webrev.00/, which fixes bug https://bugs.openjdk.java.net/browse/JDK-8144214. Thank you -Hamlin

Re: RFR: JDK-8142936:Additional java.time.Duration methods

Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8142936/webrev.02/ Regards, Nadeesh TV On 11/27/2015 11:20 PM, Stephen Colebourne wrote: "Overall, looks pretty good. There a a number of double spaces that should be single spaces in the Javadoc. Change "This is based on t

Re: RFR(S): 8131129: Attempt to define a duplicate BMH$Species class

Hello, FYI, I've requested backport approval for this fix to 8u. http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-November/004540.html Best, Michael > Am 09.11.2015 um 16:28 schrieb Michael Haupt : > > ... thanks a lot, Peter and Vladimir! > > Best, > > Michael > >> Am 09.11.2015 um 13

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

On 29/11/15 16:42, Claes Redestad wrote: On 2015-11-29 17:18, Alan Bateman wrote: On 29/11/2015 14:30, Claes Redestad wrote: On 2015-11-25 16:23, Aleksey Shipilev wrote: On 11/25/2015 06:14 PM, Claes Redestad wrote: Inlining the isPrimitive check should be enough to avoid extra comparisons:

Re: Code (Pre-)Review for JEP 280: Indify String Concat

Hi Aleksey, > http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.05/ src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java 669 final boolean sized; 670 final boolean exact; The fields can be declared private. test/java/lang/String/concat/ImplicitStringConcat

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

> On 29 Nov 2015, at 17:08, Alan Bateman wrote: > > On 27/11/2015 09:06, Paul Sandoz wrote: >> : >> >>> Also wondering how these tests will access jdk.internal once we're using >>> the modular image? >>> >> I believe it is sufficient to include: >> >> 28 * @modules java.base/jdk.internal.