Re: Proposed API for JEP 259: Stack-Walking API

> On Nov 2, 2015, at 6:42 AM, Jason Mehrens wrote: > > Mandy, > > Thread.dumpStack should generate the stacktrace elements then capture > System.err into a local var and lock it while writing the output. That would > be compatible with what was done before. > Good catch. Will fix that. T

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

Hi, I have updated the webrev to include all the feedback from the past few days: Delta from the previous webrev http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02.delta/ Full changes http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v02/ Change Log: + Various formatt

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

On 10/30/15 1:31 PM, Coleen Phillimore wrote: On 10/30/15 4:18 PM, Karen Kinnear wrote: Coleen, Question for you below please ... On Oct 30, 2015, at 3:44 PM, Coleen Phillimore wrote: Hi Ioi, This is a manageable code change. http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

On 10/30/15 12:44 PM, Coleen Phillimore wrote: Hi Ioi, This is a manageable code change. http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html You forward declare Klass* but don't use it in this header file. Also can you add a com

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

> On Oct 20, 2015, at 11:28 AM, Roger Riggs wrote: > > Updated Javadoc: > http://cr.openjdk.java.net/~rriggs/cleaner-doc/ I’m happy with this API to provide an easy way to migrate away from finalizers. Some thoughts: 1. For an existing finalizer (say cleanup function), it will be replaced wi

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

On 11/2/15 1:57 PM, Ioi Lam wrote: On 10/30/15 1:31 PM, Coleen Phillimore wrote: On 10/30/15 4:18 PM, Karen Kinnear wrote: Coleen, Question for you below please ... On Oct 30, 2015, at 3:44 PM, Coleen Phillimore wrote: Hi Ioi, This is a manageable code change. http://cr.openjdk.jav

Re: RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

On 10/30/15 1:23 PM, Jiangli Zhou wrote: Hi Ioi, The change looks pretty clean. The new src/share/vm/classfile/systemDictionary_ext.hpp and src/share/vm/classfile/vmSymbols_ext.hpp do not have copyright header. Please add the copyright headers. Please also fix the copyright year for the modif

Re: jmx-dev RFR 6425769: jmx remote bind address

Hi, Thanks Jaroslav and Daniel for the reviews! Comments inline. On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote: > Hi, > > On 2.11.2015 16:19, Daniel Fuchs wrote: > > Hi Severin, > > > > Adding serviceability-...@openjdk.java.net into the loop - that's > > a better alias than hotspo

Re: Proposed API for JEP 259: Stack-Walking API

> On Oct 31, 2015, at 11:05 PM, Jeroen Frijters wrote: > > Hi Mandy, > > I like the API shape and this capability is very much needed. Thanks! > > It does bring something related to mind and that is that the current Java > ecosystem is already very dependent on accurate stack frames (i.e. not

Re: Proposed API for JEP 259: Stack-Walking API

Thanks for the feedback, Paul and Maurizio, that’s very helpful. I slightly opt for consistency with other areas and go with #2. Mandy > On Nov 2, 2015, at 4:44 AM, Paul Sandoz wrote: > > I agree with Maurizio, the first signature is good enough. > > One could argue that it might be better to

RFR 8136496 Connection.begin/endRequest

Hi, Need a reviewer for 8136496. The CCC has been approved. The webrev can be found at http://cr.openjdk.java.net/~lancea/8136496/webrev.00/ Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.an

Re: [9] RFR: 8140649: imageFile should use delete[] with new[]

+1 > On Nov 2, 2015, at 9:30 AM, Artem Smotrakov > wrote: > > Hello, > > Please review this small fix for jdk9/dev repo. > > It updates imageFile.cpp to use delete[] operator together with new[]. It > also adds a check to ImageLocation::set_data(u1*) method to prevent a > possible null-dere

Re: Proposed API for JEP 259: Stack-Walking API

Mandy, Thread.dumpStack should generate the stacktrace elements then capture System.err into a local var and lock it while writing the output. That would be compatible with what was done before. Jason From: core-libs-dev on behalf of Mandy Chung Sen

Re: jmx-dev RFR 6425769: jmx remote bind address

Hi, On 2.11.2015 16:19, Daniel Fuchs wrote: Hi Severin, Adding serviceability-...@openjdk.java.net into the loop - that's a better alias than hotspot-dev for this kind of changes - maybe someone from serviceability-dev will offer to sponsor :-) I will let serviceability team members comment on

Re: Proposed API for JEP 259: Stack-Walking API

I also agree - when an object type "passes through" a method, it's usually best to use an invariant type variable. On 11/02/2015 06:44 AM, Paul Sandoz wrote: I agree with Maurizio, the first signature is good enough. One could argue that it might be better to apply PECS since it would encourag

Re: RFR 6425769: jmx remote bind address

Adding core libs. On 2.11.2015 11:38, Severin Gehwolf wrote: Hi, Here is a patch addressing JDK-6425769. The issue is that the JMX agent binds to the wildcard address by default, preventing users to use system properties for JMX agents on multi-homed hosts. Given a host with local network inter

[9] RFR: 8140649: imageFile should use delete[] with new[]

Hello, Please review this small fix for jdk9/dev repo. It updates imageFile.cpp to use delete[] operator together with new[]. It also adds a check to ImageLocation::set_data(u1*) method to prevent a possible null-dereference. Bug: https://bugs.openjdk.java.net/browse/JDK-8140649 Webrev: htt

Re: Proposed API for JEP 259: Stack-Walking API

On 10/30/2015 11:24 PM, Mandy Chung wrote: On Oct 30, 2015, at 3:38 PM, David M. Lloyd wrote: (that's what I was looking for before), or maybe even ToIntFunction where X is something that might inform the next batch size based on the work that has already been done - maybe even a Stream that

Re: Proposed API for JEP 259: Stack-Walking API

I agree with Maurizio, the first signature is good enough. One could argue that it might be better to apply PECS since it would encourage more consistent usage when it is actually required as all too often it’s easy to forget, and then too late to change. However, i don’t want to encourage the

Re: Proposed API for JEP 259: Stack-Walking API

So, we have three potential signatures here: T walk(Function, T> function) //1 T walk(Function, ? extends T> function) //2 T walk(Function, R> function) //3 Under normal conditions (i.e. lambda parameter being passed to 'walk') I think all these signatures are fundamentally equivalent

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 11/02/2015 02:56 AM, Chris Hegarty wrote: > In line with the intended location for other VM annotations, > see 8138732 [1], @sun.misc.Contended should be moved > to the jdk.internal.vm.annotation package. > > http://cr.openjdk.java.net/~chegar/8140687/00/ Changes look good to me. But what's t

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

On 01/11/2015 23:56, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. http://cr.openjdk.java.net/~chegar/8140687/00/ -Chris. [1] https://bugs.openjdk.java.net/brow

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

> On 2 Nov 2015, at 00:56, Chris Hegarty wrote: > > In line with the intended location for other VM annotations, > see 8138732 [1], @sun.misc.Contended should be moved > to the jdk.internal.vm.annotation package. > > http://cr.openjdk.java.net/~chegar/8140687/00/ > +1 Paul.

Re: RFR [9] 8140606: Update library code to use internal Unsafe

> On 28 Oct 2015, at 20:55, Chris Hegarty wrote: > > Following on from 8139891 "Prepare Unsafe for true encapsulation” [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > +1 Paul. > This will be pu

[8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev

(Apologies for multiple posts with wrong subject lines.) > Dear all, > > cross-posted to jdk8u-dev and core-libs-dev. > > Please review this change. > Issue: https://bugs.openjdk.java.net/browse/JDK-8139863 > > Webrev: http://cr.openjdk.java.ne