Re: Reg - Sub Process creation from java takes more time

2016-09-15 Thread ecki
Hello, Does the (virtual) size increase over time when it gets slower? How does the GC log looks like, any increasing activity or longer pauses? If you let this VM run for longer time (when it slows down), will it eventually fail because of some resource exhaustion? How often does the execute

Reg - Sub Process creation from java takes more time

2016-09-15 Thread Manjunath SV
Hi, I monitored memory usage, below are the details. Heap usage :- 857mb Virtual memory:- 12.6gb -Xmx set to 4gb. I have taken virtual and heap memory usage when Java spawns sub processes. Sub processes have short life, will be done in milli seconds. Thanks & Regards, Manjunath Message: 5

Re: core-libs-dev Digest, Vol 113, Issue 53

2016-09-15 Thread David Holmes
Hi Manjunath, When replying to something you see in a digest it would be a lot easier to follow if you could use the original subject line, or even go to the archives and respond to the original mail. Thanks, David On 16/09/2016 12:39 AM, Manjunath SV wrote: Hi, I monitored memory usage, b

Re: RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds

2016-09-15 Thread Thomas Stüfe
Hi Roger, Thank you for taking care of this! Fix looks fine. Kind Regards, Thomas On Thursday, 15 September 2016, Roger Riggs wrote: > Please review a fix for build breakage on Solaris. > The NAME_MAX value does not seem to add much value in this case and is not > defined on all supported plat

Re: RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds

2016-09-15 Thread Naoto Sato
+1 Naoto On 9/15/16 12:16 PM, Roger Riggs wrote: Please review a fix for build breakage on Solaris. The NAME_MAX value does not seem to add much value in this case and is not defined on all supported platforms. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/ Issue: https:/

Re: RFR(s): 4285505: deprecate java.lang.Compiler

2016-09-15 Thread Krystal Mok
Hi Stuart, Again, replying on behalf of Azul Systems: Removal is the real concern. We can probably live with deprecation (if this amounts to annotation) as long as removal does not occur until a vetted alternative is in place. But we suggest a re-consideration of the deprecation issue if it's dri

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Jonathan Bluett-Duncan
Hi all, Stuart, thank you very much for your thorough response. Regarding serializability concerns, I've just checked my changes and all non-test code in the JDK which calls it, and it doesn't seem to me that they affect any fields in `Serializable` classes or the return values of methods which e

RFR 9: 8166148 Fix for JDK-8165936 broke Solaris builds

2016-09-15 Thread Roger Riggs
Please review a fix for build breakage on Solaris. The NAME_MAX value does not seem to add much value in this case and is not defined on all supported platforms. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-max-8166148/ Issue: https://bugs.openjdk.java.net/browse/JDK-8166148 Thanks,

Re: RFR(xs): 8165936: Potential Heap buffer overflow when seaching timezone info files

2016-09-15 Thread Roger Riggs
Hi Thomas, It looks like NAME_MAX is not defined on Solaris and breaks the build on Solaris. [1] An alternative would be to conditionally use PATH_MAX. But I think it would be reasonable to just remove the use of NAME_MAX, since the following code increases the value to at least 1024, whic

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Stuart Marks
Hi all, Unfortunately I don't have time to work on any of this at the moment, because of JavaOne preparation, and JavaOne next week. Jonathan, thanks for pushing forward with this. I'm glad that others have picked it up. Patrick, thanks for posting the changeset on Jonathan's behalf. This i

Re: [8u] RFR(XXS): 8165231: java.nio.Bits.unaligned() doesn't return true on ppc

2016-09-15 Thread Hiroshi H Horii
Hi Volker, and Sean, Thank you for your comments and suggestion. I and Gustavo created a webrev that includes Bits and ByteArrayAccess. http://cr.openjdk.java.net/~gromero/8165231/02/ I believe there is no other similar methods in jdk. Regards, Hiroshi --- Hiroshi Horii, Ph

Re: RFC: System.console().encoding()

2016-09-15 Thread Ulf Zibis
Am 15.09.2016 um 17:56 schrieb Aleksey Shipilev: ...which opens a way to poll this without a Reflection hack. Extended the JMH hack with it, but it still fragile: http://hg.openjdk.java.net/code-tools/jmh/rev/8c20adb08b2d Maybe keep it simple - no need for (prop != null) - and in design line

Re: RFC: System.console().encoding()

2016-09-15 Thread Xueming Shen
On 9/15/16 8:56 AM, Aleksey Shipilev wrote: On 09/15/2016 09:06 AM, Xueming Shen wrote: Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. Simply for some implementation convenience is really not a good reason to add such a public me

Re: RFC: System.console().encoding()

2016-09-15 Thread Aleksey Shipilev
On 09/15/2016 09:06 AM, Xueming Shen wrote: > Console is supposed to be a "char/String" based class, "encoding" > really should have no business here in its api. Simply for some > implementation convenience is really not a good reason to add such a > public method. Let's look at it this way: there

Re: RFC: System.console().encoding()

2016-09-15 Thread David M. Lloyd
On 09/15/2016 02:06 AM, Xueming Shen wrote: -1 :-) Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. Simply for some implementation convenience is really not a good reason to add such a public method. Let's look at the two likely

Re: core-libs-dev Digest, Vol 113, Issue 53

2016-09-15 Thread Manjunath SV
Hi, I monitored memory usage, below are the details. Heap usage :- 857mb Virtual memory:- 12.6gb -Xmx set to 4gb. I have taken virtual and heap memory usage when Java spawns sub processes. Thanks & Regards, Manjunath On 15 Sep 2016 4:17 p.m., wrote: Send core-libs-dev mailing list submis

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Jonathan Bluett-Duncan
Patrick, would you kindly line-wrap the TOCTOU comment in http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01/src/java.base/share/classes/java/nio/file/FileTreeIterator.java.cdiff.html for me, so that each line has 80 characters or less (and maybe insert a `.` at the end)? Kind regards,

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Jonathan Bluett-Duncan
Pavel, > 6. I couldn't find any evidence that `resolverFields` might contain `null`. > Am I missing a javadoc or a line of code? Maybe we should talk to java.time > folks to see if it's the case? > When I ran the tests for java.time, one of them failed because `null` was being passed to `resolve

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Jonathan Bluett-Duncan
Wow, lots of discussion went on since I was busy doing other stuff! Thanks Patrick for doing the work of creating a new webrev for me. Really appreciated! Pavel already mentioned it, but I think List.of instead of Collections.emptyList in ZoneOffsetTransition is the right thing to do for visual a

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Patrick Reinhart
Hello together, I tried to process all suggested change input into the following new webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01 Give me feedback if something is missing/wrong -Patrick On 2016-09-15 13:48, Pavel Rappo wrote: Daniel, Claes, List.of() and Collecti

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Pavel Rappo
Daniel, Claes, List.of() and Collections.emptyList() are not the same. The behaviours are different. Moreover, immutable static factory methods return instances which are value-based. I believe it also means we are not tied with unconditional instantiation, and in case of empty collections/maps co

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Claes Redestad
+1 I don't mind List.of() aesthetically, but there are places where startup/footprint is important where Collections.emptyList() is simply superior, e.g., constituting permanent data structures such as the module graph during early bootstrap. I know there are some drawbacks to the singleton appr

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Pavel Rappo
Daniel, if you're referring to 388 List getValidOffsets() { 389 if (isGap()) { > 390 return List.of(); 391 } 392 return List.of(getOffsetBefore(), getOffsetAfter()); 393 } I think in this particular case, List.of is more consistent. > On 15 S

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Stephen Colebourne
The date/time changes seem reasonable. Stephen On 14 September 2016 at 21:55, Patrick Reinhart wrote: > Hi Jonathan, > > Here are your changes in a webrev: > > http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00 > > > -P

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Daniel Fuchs
Hi, I'm not sure I like the replacement of Collections.emptyList() by List.of(); I find emptyList() more expressive (+ it always returns the same instance). best regards, -- daniel On 15/09/16 11:46, Pavel Rappo wrote: Hi, I have had a look at the change. It looks good. Retrofitting Collect

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Pavel Rappo
Hi, I have had a look at the change. It looks good. Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience Factory Methods requires extra carefulness as the factory methods are stricter than any of those. Not only do they provide unconditional non-modifiability [0], they also do

Re: RFC: System.console().encoding()

2016-09-15 Thread Dawid Weiss
> out of curiosity... what will you do if you find the encoding lacking what > you need? Oh, display a warning. Helps to figure out where those "???" characters are coming from... Naive, I know. But it's the best one can do and it works (most of the time). D.

Re: RFC: System.console().encoding()

2016-09-15 Thread Jochen Theodorou
On 15.09.2016 09:21, Dawid Weiss wrote: Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. While I agree with your concerns about the functional side of the API, I disagree about this method having no practical use. I can give you

Re: Reg - Sub Process creation from java takes more time

2016-09-15 Thread ecki
Hello, Do you monitor heap usage and virtual memory size of your Java process? I would look out for increase (which causes slower for tines). Also it is generally a good idea to turn on GC logging and look into it if a java process degregades over time Gruss Bernd Just BTW: I think Java would

Re: RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

2016-09-15 Thread Jonathan Bluett-Duncan
Thanks Patrick! Stuart, would you be happy to sponsor this change? If anyone else has any thoughts regarding this change, then I'm all ears. Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373 Rationale for changes: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/04348

Re: RFC: System.console().encoding()

2016-09-15 Thread Claes Redestad
+1 Won't be enough, though, since in JMH it appears you're also getting the encoding from System.out (java.io.PrintStream) via reflective hacks. /Claes On 2016-09-15 08:42, Aleksey Shipilev wrote: Hi, Claes pointed out that our own reflective hacks to figure out console encoding do not work a

Re: RFC: System.console().encoding()

2016-09-15 Thread Dawid Weiss
> Console is supposed to be a "char/String" based class, "encoding" really > should have no business here in its api. While I agree with your concerns about the functional side of the API, I disagree about this method having no practical use. I can give you a concrete example. The use case that we

Re: RFC: System.console().encoding()

2016-09-15 Thread Xueming Shen
-1 :-) Console is supposed to be a "char/String" based class, "encoding" really should have no business here in its api. Simply for some implementation convenience is really not a good reason to add such a public method. That said, I would be fine to have such informative info in the system