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

Hi peter, Given this is a stack walker, considering the stack as a state seems natural to me. Rémi - Mail original - > De: "Peter Levart" > À: "Remi Forax" , "David Holmes" > Cc: "Mandy Chung"

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

Hi, Re-posting this for review since I've done another version which duplicates some of the code in SslRMIServerSocketFactory.java but does not change API other than adding the new property. I personally don't like it, but maybe this version is preferred? Bug: 

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

> On Nov 18, 2015, at 1:11 AM, Peter Levart wrote: > > Hi Mandy, > > Just one nit... > > On 11/17/2015 11:59 PM, Mandy Chung wrote: >>> Apart from the orphaned paragraph fragment at the end looks good to me, but >>> that’s just my opinion. >> I caught that that after

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

This is the update javadoc of getCallerClass. Thanks for all the feedback and suggestion. I have to finalize this API today to make the FC date :) /** * Gets the {@code Class} object of the caller invoking the method * that calls this {@code getCallerClass} method. * * Reflection

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

I also think IllegalStateException is better than UOE for this case as getCallerClass is inappropriate to be called where there is no caller frame. Mandy > On Nov 18, 2015, at 5:12 AM, fo...@univ-mlv.fr wrote: > > Hi peter, > Given this is a stack walker, considering the stack as a state seems

Re: Code Review for JEP 259: Stack-Walking API

Hi, Mandy I looked through the jdk code. I think it's looking quite good. I just noticed some small details to consider fixing up before pushing. Docs: StackWalker.StackFrame.getClassName(): the "binary name" link seems to be broken (StackWalker.java line 100) StackWalker.getInstance(Set

Re: RFR: jsr166 jdk9 integration wave 2

On Tue, Nov 17, 2015 at 2:26 AM, Paul Sandoz wrote: > > For the jtregTest updates, if you have any excess energy remaining, you > might want to consider adding the jtreg randomness tag (i cannot recall its > exact name) to the test metadata. > Most of the jtreg tests

Re: RFR: JDK-8140364: JEP 264 Platform Logger API and Service Implementation

> On Nov 3, 2015, at 12:12 PM, Daniel Fuchs wrote: > > Hi Mandy, > > I have pushed an update that adds the diagnosability tweaks > you asked me for in LoggerFinderLoader. > I also added a couple of new tests. > No changes in the API specification. > : > >

Re: RFR: 8143253: java/lang/invoke/CompileThresholdBootstrapTest.java failing on mach5

Thanks! /Claes On 2015-11-18 20:56, Lance Andersen wrote: lOOks ok On Nov 18, 2015, at 2:22 PM, Claes Redestad > wrote: Hi, seems I pushed out the wrong version of CompileThresholdBootstrapTest with JDK-8143232 and didn't look

Re: RFR(L): 8139885: implement JEP 274: enhanced method handles

Hi Vladimir, > Am 17.11.2015 um 13:08 schrieb Vladimir Ivanov : > Awesome! Looks really good, Michael! thank you very much. > src/java.base/share/classes/java/lang/invoke/MethodHandles.java: > if (!hasPrivateAccess() > || (specialCaller

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

> On Nov 17, 2015, at 2:09 PM, Peter Levart wrote: > > I think that calling getCallerClass() from implementation of Runnable::run > should expect it to return a system class. It may be Thread.class or > ThreadPoolExecutor$Worker.class or anything actually. > I’m now

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

Hi, I’m happy to hear that, I was just about to post more convoluted examples against special-casing (i.e. new Thread(r).start(); vs. new Thread(r) {}.start(); vs. new Thread(new Thread(r)) {}.start(); vs. new Thread(new Thread(r)

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Kind of related but not really, I’ve filed a bug against ConstantPool to add JSR 292 “support”: JDK-8077229: sun.reflect.ConstantPool should support class and method constant pools https://bugs.openjdk.java.net/browse/JDK-8077229 > On Nov 17,

Re: RFR: jsr166 jdk9 integration wave 2

On 11/17/2015 07:43 AM, Paul Sandoz wrote: Separately but related, i have a solution that allows VarHandles to be used in the A*FU implementations. However, i am not sure it would be possible to preserve the exact exception throwing behaviour and their content e.g. the type of a CAS expect

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

Hi Mandy, Just one nit... On 11/17/2015 11:59 PM, Mandy Chung wrote: Apart from the orphaned paragraph fragment at the end looks good to me, but that’s just my opinion. I caught that that after I clicked sent :( This is a better version. /** * Gets the {@code Class} object of the caller

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

On 11/18/2015 12:22 PM, Remi Forax wrote: - Mail original - De: "David Holmes" À: "Mandy Chung" , "Peter Levart" Cc: "OpenJDK Dev list" Envoyé: Mercredi 18 Novembre 2015

Re: RFR: jsr166 jdk9 integration wave 2

> On 18 Nov 2015, at 03:46, Martin Buchholz wrote: > > > > On Tue, Nov 17, 2015 at 2:26 AM, Paul Sandoz > wrote: > > For the jtregTest updates, if you have any excess energy remaining, you might > want to

Re: RFR: 8140344: add support for 3 digit update release numbers

On 18/11/2015 1:30 AM, Rob McKenna wrote: I'd expect this to be superseded by 223 completely but I've cc'd verona-dev in case there are objections. At this point the fix is more for the benefit of 7 & 8. I'd be happy to mark this 9-na if that makes more sense? I'd vote for a 7 (and 8?)

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

On 18/11/2015 8:42 AM, Mandy Chung wrote: On Nov 17, 2015, at 2:09 PM, Peter Levart wrote: I think that calling getCallerClass() from implementation of Runnable::run should expect it to return a system class. It may be Thread.class or ThreadPoolExecutor$Worker.class

Re: RFR: 8143232: Fix java.lang.invoke bootstrap when specifying COMPILE_THRESHOLD

Reviewed. Best regards, Vladimir Ivanov On 11/18/15 5:41 PM, Claes Redestad wrote: Hi, a recent change of mine to make LF bootstrap lazier[1] breaks when explicitly interpreting LambdaForms due to a circular dependency. By explicitly compiling identity and zero forms bootstrap to bytecode we

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

- Mail original - > De: "David Holmes" > À: "Mandy Chung" , "Peter Levart" > > Cc: "OpenJDK Dev list" > Envoyé: Mercredi 18 Novembre 2015 08:58:56 > Objet: Re: Proposed API for JEP

RFR: 8143232: Fix java.lang.invoke bootstrap when specifying COMPILE_THRESHOLD

Hi, a recent change of mine to make LF bootstrap lazier[1] breaks when explicitly interpreting LambdaForms due to a circular dependency. By explicitly compiling identity and zero forms bootstrap to bytecode we avoid this corner case, while maintaining the benefits of lazy initialization.

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Remi, Thanks for reviewing. Your suggestion sounds sensibly. May be it also has sense to make a method "getMethodRefNameAndTypeIndex(int index)" to acquire name-and-type entry index for methods also. -Konstantin On 11/18/2015 12:04 AM, Remi Forax wrote: Hi Konstantin, Technically,

Re: Code Review for JEP 259: Stack-Walking API

On 11/18/15 5:06 PM, Mandy Chung wrote: On Nov 18, 2015, at 1:01 PM, Coleen Phillimore wrote: One of the things that I'm struggling with is that StackFrameInfo contains both the collected information from walking the stack frames, method id, bci, mirror,

Re: Code Review for JEP 259: Stack-Walking API

> On Nov 18, 2015, at 1:01 PM, Coleen Phillimore > wrote: > > > One of the things that I'm struggling with is that StackFrameInfo contains > both the collected information from walking the stack frames, method id, bci, > mirror, version and cpref, and the

Re: Code Review for JEP 259: Stack-Walking API

On 11/18/15 2:24 PM, Mandy Chung wrote: == >jdk/src/java.base/share/classes/java/lang/StackFrameInfo.java > >66 >Perhaps this.memberName does not need to be allocated in the case of -XX:-MemberNameInStackFrame ? > For more accurate footprint comparison, yes it should not allocate MemberName.

Re: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle Byte, Short, Character

On 11/18/2015 01:08 AM, Claes Redestad wrote: > On 2015-11-17 22:13, Remi Forax wrote: >> Hi Claes, >> I fail to see how this code will not throw a CCE at runtime >>if (con instanceof Integer || con instanceof Byte || con instanceof >> Short || con instanceof Character) { >>

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

On 18/11/2015 10:26 PM, Peter Levart wrote: On 11/18/2015 12:22 PM, Remi Forax wrote: - Mail original - De: "David Holmes" À: "Mandy Chung" , "Peter Levart" Cc: "OpenJDK Dev list"

JEP 280: Indify String Concatenation

New JEP Candidate: http://openjdk.java.net/jeps/280 - Mark

Re: RFR: 8143253: java/lang/invoke/CompileThresholdBootstrapTest.java failing on mach5

lOOks ok On Nov 18, 2015, at 2:22 PM, Claes Redestad wrote: > Hi, > > seems I pushed out the wrong version of CompileThresholdBootstrapTest with > JDK-8143232 and didn't look twice enough. Any takers for this trivial test > fix? > > Webrev:

Re: Code Review for JEP 259: Stack-Walking API

> On Nov 18, 2015, at 11:00 AM, Brent Christian > wrote: > > Hi, Mandy > > I looked through the jdk code. I think it's looking quite good. I just > noticed some small details to consider fixing up before pushing. > > Docs: > >

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

> On Nov 18, 2015, at 6:32 PM, David Holmes wrote: > > > I agree with Remi. "state" doesn't have to mean fields - there are numerous > existing examples in the JDK. Calling a method in a context that is invalid > is an illegal state to me. IllegalThreadStateException

Re: RFR(L): 8139885: implement JEP 274: enhanced method handles

On Nov 13, 2015, at 8:39 AM, Michael Haupt wrote: > > Dear all, > > please review this change. > RFE: https://bugs.openjdk.java.net/browse/JDK-8139885 > Corresponding JEP: https://bugs.openjdk.java.net/browse/JDK-8130227 > Webrev:

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

On Nov 18, 2015, at 6:32 PM, David Holmes wrote: > >>> >>> Looks good to me too if IllegalStateException is used instead of >>> UnsupportedOperationException. >>> UnsuppportedOperationException is used when the operation is not >>> available, here, the same code can

Re: Code Review for JEP 259: Stack-Walking API

One of the things that I'm struggling with is that StackFrameInfo contains both the collected information from walking the stack frames, method id, bci, mirror, version and cpref, and the digested information: interned string for class name, method name, line number and source file name.

RFR: 8143253: java/lang/invoke/CompileThresholdBootstrapTest.java failing on mach5

Hi, seems I pushed out the wrong version of CompileThresholdBootstrapTest with JDK-8143232 and didn't look twice enough. Any takers for this trivial test fix? Webrev: cr.openjdk.java.net/~redestad/8143253/webrev.01 Bugs: https://bugs.openjdk.java.net/browse/JDK-8143253 /Claes

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi, Please review the latest iteration of the webrev for runtime support of multi-release jar files. Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ I