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

[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:

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

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

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

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

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

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

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

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

[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:

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

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

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/ >

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/ >

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]

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.

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

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

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

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

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 -