Improve timezone mapping for AIX platform

Hi ppc-aix-port-dev, core-libs-dev, Here's a patch for JDK-8034220, http://cr.openjdk.java.net/~luchsh/JDK-8034220/ It is trying to add the a more complete timezone mapping mechanism for AIX platform. the changes are primarily based on IBM's commercial JDK code, which includes: - A new timezone

Re: Implicit 'this' return for void methods

On 26/03/2014 6:19 AM, Victor Polischuk wrote: Good day, everyone, I have a question regarding a proposal I found some time ago: http://tech.puredanger.com/java7#chained. More direct original link: http://www.mernst.org/blog/rss.xml#AModestLanguageProposal In a word, it is all about replac

Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

Mike, On 26/03/2014 6:37 AM, Mike Duigou wrote: Hello all; Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit fr

Re: Process API Updates (JEP 102)

Hi Florian, On 3/25/14 5:18 AM, Florian Weimer wrote: On 03/24/2014 10:11 PM, roger riggs wrote: From the scope of the JEP, a fairly simple API seems sufficient. - Enumerate the direct children - The rest of the functions are similar to Process - to terminate a process, forcibly and n

Re: Process API Updates (JEP 102)

Hi Peter, On 3/25/14 2:50 AM, Peter Levart wrote: On 03/24/2014 10:11 PM, roger riggs wrote: Hi, I'm starting to work on JEP 102, Process API Updates for JDK 9. The use cases identified include test execution and build systems such as Jtreg and Hudson/Jenkins. And there is a use-case for using

Re: ProcessReaper: single thread reaper

No, in the prototype only. The current shipping implementation dedicates a thread to each Process and waits only for a specific pid to exit. Roger On 3/25/14 3:50 PM, Martin Buchholz wrote: Roger, are you saying there's a race in the currently shipping implementation? --- I believe It's

Re: 8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

On 03/25/2014 09:37 PM, Mike Duigou wrote: Hello all; Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clu

Re: ProcessReaper: single thread reaper

Hi Peter, The stream draining code was added in 2011 to address resource exhaustion due to poor hygiene. * JDK-6944584 Improvements to subprocess handling on Unix Moves the resource 'leak' from the OS kernel/process space to the heap and al

Re: ProcessReaper: single thread reaper

Hi Martin, Two cases, one current and one future. In the current case, Process can spawn a process and the process can exit before Process can register the callback to get the exitValue. Peter pointed out this race in his comments. The exitValue needs to be saved (for some time yet to be determi

Re: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action

On 25/03/2014 20:41, Mandy Chung wrote: : The ExtendedCharsets.init method has a check to ensure that the VM has been booted. Sherman can confirm that. 1170 protected void init() { 1171 if (initialized) 1172 return; 1173 if (!sun.misc.VM.isBooted()) 1174

Re: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action

On 3/24/2014 8:15 AM, Alan Bateman wrote: On 21/03/2014 21:28, Mandy Chung wrote: This is the second patch to eliminate the dependencies to sun.security.action: https://bugs.openjdk.java.net/browse/JDK-8038177 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/ I

8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

Hello all; Recently HotSpot gained additional support for transactional memory, . This patch is a libraries followon to that change. RTM and other transactional memory implementations benefit from clustering writes towards the end of the transac

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

+ enum BasicType { + L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types + I_TYPE('I', int.class,Wrapper.INT), + J_TYPE('J', long.class, Wrapper.LONG), + F_TYPE('F', float.class, Wrapper.FLOAT), + D_TYPE('D', double.class, Wrapper.DO

Implicit 'this' return for void methods

Good day, everyone, I have a question regarding a proposal I found some time ago: http://tech.puredanger.com/java7#chained. In a word, it is all about replacing 'void' behavior to always return 'this' and I think for static methods it would be nice to return Class instance. I have not found an

Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError

On 03/25/2014 07:31 AM, Yekaterina Kantserova wrote: On 03/25/2014 02:53 PM, Alan Bateman wrote: On 25/03/2014 12:14, Staffan Larsen wrote: I’ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to

Re: Process API Updates (JEP 102)

Hi Roger, I have a few questions for your consideration, hopefully they make sense! Is this API to be available to the plug-in/applet? Even with appropriate permissions? What permissions are required to invoke operations on the API? Do you need to differentiate between "spawning" a Java p

Re: Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration

On Mar 25, 2014, at 2:37 PM, Staffan Larsen wrote: > (Adding hotspot-runtime-dev since some changes are in hotspot code). > > > On 25 mar 2014, at 14:20, Paul Sandoz wrote: > >> >> On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: >> >>> >>> On Mar 24, 2014, at 7:49 PM, Staffan Larsen >>

Re: ProcessReaper: single thread reaper

On 03/25/2014 05:25 PM, Roger Riggs wrote: Hi Peter, Thanks for the comments, I'll fix the races conditions, I intended to go back to the dedicated thread but wanted to check for scalability in the case of a large number of threads and non-trivial termination overheads where the streams had to

Re: ProcessReaper: single thread reaper

Hi Peter, Thanks for the comments, I'll fix the races conditions, I intended to go back to the dedicated thread but wanted to check for scalability in the case of a large number of threads and non-trivial termination overheads where the streams had to be drained. Thanks, Roger On 3/25/14 7:

Re: ProcessReaper: single thread reaper

On 03/25/2014 03:05 PM, Peter Levart wrote: That's enough races for today. Or just one more... The debug log("Unexpected process exit for pid:...") could also be reached when new process is spawned by UNIXProcess constructor and before the constructor manages to register new consumer for it'

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On Mar 25, 2014, at 1:58 AM, Paul Sandoz wrote: > This is another example of a stable variable. > > I would like to re-iterate my scepticism that such changes are necessary in > this case (i am not sure if it is possible to create a benchmark that could > better exacerbate the concurrent over

Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError

On 03/25/2014 02:53 PM, Alan Bateman wrote: On 25/03/2014 12:14, Staffan Larsen wrote: I’ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. I’m sure you know this, but for

Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError

On 03/25/2014 01:14 PM, Staffan Larsen wrote: I’ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. I’m sure you know this, but for the record: please don’t push this until jt

ProcessReaper: single thread reaper

On 03/24/2014 10:05 PM, roger riggs wrote: Hi Rob, Martin, et.al. I've prototyped (for 9) a thread reaper[1] that uses a single thread to wait for exiting processes and calling back to the process with the exit status. the interesting part is getting the exit status back to the Process that n

Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError

On 25/03/2014 12:14, Staffan Larsen wrote: I’ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. I’m sure you know this, but for the record: please don’t push this until jtreg

Re: Process API Updates (JEP 102)

On 25/03/2014 12:17, David M. Lloyd wrote: There are two features we would definitely like to see added: 1) NIO Channel interface for process streams 2) The ability to pass additional channels to child processes #1 seems relatively straightforward, Assuming #1 means non-blocking and multiplexi

Re: Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration

(Adding hotspot-runtime-dev since some changes are in hotspot code). On 25 mar 2014, at 14:20, Paul Sandoz wrote: > > On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: > >> >> On Mar 24, 2014, at 7:49 PM, Staffan Larsen >> wrote: >> >>> We have abandoned the HSX model. From JDK 8 one versi

Experimental patches for unsafe cleanup Re: The s.m.Unsafe representation in hotspot and method registration

On Mar 25, 2014, at 9:34 AM, Paul Sandoz wrote: > > On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: > >> We have abandoned the HSX model. From JDK 8 one version of Hotspot will be >> tied to one version of the JDK. This looks like old code that has not been >> cleaned up. >> > > Thanks

Re: Process API Updates (JEP 102)

On 25/03/2014 09:50, Peter Levart wrote: : It would just require the API specification to strengthen it's guarantees on some methods: for example destroyForcibly() would guarantee forcible termination. It might require an additional method like destroyNicely() or terminateNicely() which would

Re: Process API Updates (JEP 102)

Hi Martin, Good idea, I'll put something together in the next couple of weeks. Roger On 3/25/14 1:54 AM, Martijn Verburg wrote: Hi Roger, Is there a short survey we could send out to the wider dev community on this one? I think just about every day to day Java developer has had to use Pr

Re: Process API Updates (JEP 102)

On 03/24/2014 10:11 PM, roger riggs wrote: From the scope of the JEP, a fairly simple API seems sufficient. - Enumerate the direct children - The rest of the functions are similar to Process - to terminate a process, forcibly and normally - to destroy a process and all of its childr

Re: Process API Updates (JEP 102)

On 03/24/2014 04:11 PM, roger riggs wrote: Hi, I'm starting to work on JEP 102, Process API Updates for JDK 9. The use cases identified include test execution and build systems such as Jtreg and Hudson/Jenkins. And there is a use-case for using Java to monitor the health of a more complex system

Re: RFR(S): 8034960: Serviceability tests using @library failing with java.lang.NoClassDefFoundError

I’ve looked at a random sample of these changes and they look ok. Since some of the changes are in non-serviceability code I have also added core-libs to the review thread. I’m sure you know this, but for the record: please don’t push this until jtreg with the fix has been promoted. Thanks, /

Re: RFR: 8036786: Update jdk7 testlibrary to match jdk8

I’ve looked at the changes in StreamPumper and ProcessTools: they look good. Since the rest of the code is a straight backport, I didn’t look at it. Reviewed. Thanks, /Staffan On 6 mar 2014, at 16:34, Vladimir Kempik wrote: > Please review this change to update jdk part of testlibrary in jdk7

Re: Process API Updates (JEP 102)

On 03/24/2014 10:11 PM, roger riggs wrote: Hi, I'm starting to work on JEP 102, Process API Updates for JDK 9. The use cases identified include test execution and build systems such as Jtreg and Hudson/Jenkins. And there is a use-case for using Java to monitor the health of a more complex system

RE: RFR: 8036786: Update jdk7 testlibrary to match jdk8

This is becoming URGENT as we have other high priority cases pending the backport of these test libraries. We could backport these fixes without the tests and then file a separate bug to backport the tests, but it would be great if we could just get a review of this, as it is a pretty straight

Re: Process API Updates (JEP 102)

On 25 Mar 2014, at 08:45, Kasper Nielsen wrote: > On Mon, Mar 24, 2014 at 10:11 PM, roger riggs wrote: > >> Hi, >> >> I'm starting to work on JEP 102, Process API Updates for JDK 9. >> >> Are there use cases for which this is insufficient? Please comment. >> >> > What about a non-blocking w

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On Mar 24, 2014, at 8:30 PM, Mike Duigou wrote: > The other issue here, and why this thread has gone on so long, is that we've > been trying to establish what the best idiom is (for 2014-) for this lazy > initialization situation so that we can reuse it with less thought and > review. In th

Re: Process API Updates (JEP 102)

Would be nice to have some kind of "async" process I/O streaming. And an event mechanism to receive notifications when the process terminates or input is available from stdout/stderr. > Am 25.03.2014 um 09:45 schrieb Kasper Nielsen : > > On Mon, Mar 24, 2014 at 10:11 PM, roger riggs wrote: > >>

Re: Process API Updates (JEP 102)

Hi Roger, Is there a short survey we could send out to the wider dev community on this one? I think just about every day to day Java developer has had to use Process at some stage in their career. Cheers, Martijn On 24 March 2014 21:11, roger riggs wrote: > Hi, > > I'm starting to work on JE

Re: Process API Updates (JEP 102)

On Mon, Mar 24, 2014 at 10:11 PM, roger riggs wrote: > Hi, > > I'm starting to work on JEP 102, Process API Updates for JDK 9. > > Are there use cases for which this is insufficient? Please comment. > > What about a non-blocking waitFor mechanism such as void onTerminate(IntConsumer consumer) or

Re: The s.m.Unsafe representation in hotspot and method registration

On Mar 24, 2014, at 7:49 PM, Staffan Larsen wrote: > We have abandoned the HSX model. From JDK 8 one version of Hotspot will be > tied to one version of the JDK. This looks like old code that has not been > cleaned up. > Thanks, yes, looks like we can clean this up and also remove the deprec

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On 03/24/2014 06:48 PM, Brian Burkhalter wrote: Hi Peter, On Mar 24, 2014, at 2:21 AM, Peter Levart > wrote: Thanks to Aleksey for re-establishing the access, I bring you results of the microbenchmark from his quad-core Cortex-A9: Thanks to you and Aleksey for