Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

Thanks for the explanation, and patience, Vladimir! Reworked: http://cr.openjdk.java.net/~redestad/8142334/webrev.09/ /Claes On 2015-11-16 13:49, Vladimir Ivanov wrote: The trick here is @Stable annotation. If the @Stable field is written to non-default value in constructor, it should be

Re: RFR: 8142996: move jdk java/util/streams tests into java.base directories

> On Nov 13, 2015, at 3:46 PM, Jonathan Gibbons > wrote: > > Please review the following fix to relocate some of the files in the > jdk/test/java/util/streams directory. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8142996 > Webrev:

Re: RFR 8143015/9: 5 tests fail with error "Can't find source for class: java.util.stream.OpTestCase"

+1 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Nov 15, 2015, at 10:44 PM, Felix Yang wrote: > > Hi, >please review the following

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

The trick here is @Stable annotation. If the @Stable field is written to non-default value in constructor, it should be equivalent to final field initialization. If the field is written to later, the initialization should be either idempotent or properly synchronized. I'd like to note that

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

On 11/16/2015 01:49 PM, Vladimir Ivanov wrote: The trick here is @Stable annotation. If the @Stable field is written to non-default value in constructor, it should be equivalent to final field initialization. That changes my view completely. Thanks for clarifying. Regards, Peter

Re: RFR:JDK-8071919 :Add java.time.Clock.tickMillis(ZoneId zone) method

Hi Nadeesh, This looks good to me. Best regards, -- daniel On 11/13/15 8:42 PM, nadeesh tv wrote: Hi , Please see the updated webrev http://cr.openjdk.java.net/~ntv/8071919/webrev.02/ Thanks and Regards, Nadeesh On 11/13/2015 9:23 PM, Roger Riggs wrote: Hi Nadeesh, One suggestion:

Re: RFR: 8142334: Improve lazy initialization of java.lang.invoke

NamedFunction.resolvedHandle should be usually pre-resolved, but for bootstrapping purposes it is done lazily in some cases. I don't see any reason why NamedFunction.resolve() should be called on a freshly created instance. Use proper constructor instead. NamedFunction(MethodHandle

Re: [9] RFR of 8032027: Add BigInteger square root methods

Returning to this review... On 10/7/2015 7:02 PM, Brian Burkhalter wrote: Joe / Andrew / Louis, Following up on the thread regarding https://bugs.openjdk.java.net/browse/JDK-8032027. I revised the algorithm similarly to what Louis suggested for the initial value of the iteration. I also

Re: RFR 8142927: Feed some text to STDIN in ProcessTools.executeProcess()

> On 2015年11月13日, at 下午9:44, Roger Riggs wrote: > > Hi Max, > > It would be cleaner to create and use a PrintStream to send the bytes > to the process. We don't want to encourage the poor practice of using > getBytes(). Like this?

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

> On Nov 15, 2015, at 10:59 AM, Peter Levart wrote: > > OTOH in the described cases, a caller of walker.getCallerClass() is actually > expecting to be called by a Java method, right? So what would it be if such > "caller-sensitive" method demanded to be called by a

Patch for adding SO_REUSEPORT socket option

Hello all, I request the community to review a patch for adding SO_REUSEPORT support. There is already an existing JBS opened at https://bugs.openjdk.java.net/browse/JDK-6432031 Details : SO_REUSEPORT removes 1:1 assignment between listen socket and IP:PORT pair and enable multiple sockets

RFR: jsr166 jdk9 integration wave 2

Smaller than wave 1, but still large. Nothing like a looming deadline to spur work ... Oracle folks will need to help with API review.

Re: RFR: 8066272: pack200 must support Multi-Release Jars

John, Steve, I have updated the webrev which fixes the version numbers and removes the duplicate manifest's in the jar-files. Full webrev: http://cr.openjdk.java.net/~ksrini/8066272/webrev.1/ Incremental webrev: http://cr.openjdk.java.net/~ksrini/8066272/webrev.1/webrev.delta/index.html

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

[CC'ing core-libs-dev] > On Nov 13, 2015, at 4:55 AM, Konstantin Shefov > wrote: > > Hello > > Please review an enhancement to add three new methods to > sun.reflect.ConstantPool class. > The following methods are suggested: > > public String[]

RFR: 8029574: TreeMap: optimization of method computeRedLevel()

https://bugs.openjdk.java.net/browse/JDK-8029574 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TreeMap-optimization/

Re: RFR: 8029574: TreeMap: optimization of method computeRedLevel()

Good, thanks! -Aleksey On 11/16/2015 11:16 PM, Martin Buchholz wrote: > I renamed sz to size and added > > + * > + * @param size the (non-negative) number of keys in the tree to be > built > > > On Mon, Nov 16, 2015 at 12:01 PM, Aleksey Shipilev >

Re: RFR: 8029574: TreeMap: optimization of method computeRedLevel()

I renamed sz to size and added + * + * @param size the (non-negative) number of keys in the tree to be built On Mon, Nov 16, 2015 at 12:01 PM, Aleksey Shipilev < aleksey.shipi...@oracle.com> wrote: > On 11/16/2015 10:46 PM, Martin Buchholz wrote: > >

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

StackWalker::getCallerClass is intended to find 2 frames below it and for a specific purpose. For anything else, you can build on top of StackWalker::walk easily. It doesn’t eagerly dump the entire stack and walk the stack one batch at a time. Mandy > On Nov 15, 2015, at 1:37 PM, Timo

Re: RFR: 8029574: TreeMap: optimization of method computeRedLevel()

On 11/16/2015 10:46 PM, Martin Buchholz wrote: > https://bugs.openjdk.java.net/browse/JDK-8029574 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TreeMap-optimization/ +1, cute. Need to mention this only works for non-negative "sz"? It's hard to define what is the result for negative "sz",

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

> On Nov 16, 2015, at 1:36 AM, Daniel Fuchs wrote: > > Hi Mandy, > > Sorry I was not clear. > I'm proposing the following changes: > > StackFrameInfo.java: > > 100 public OptionalInt getLineNumber() { > 101 ensureMethodInfoInitialized(); > 102

Re: RFR: jsr166 jdk9 integration wave 2

On Mon, Nov 16, 2015 at 2:42 PM, Aleksey Shipilev < aleksey.shipi...@oracle.com> wrote: > > > The primary focus is making jtreg tests more robust and faster. > > It also contains the changes to j.u.c.atomic that Aleksey is waiting for. > > Yes! Thank you. If you push everything in one batch,

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

On 11/16/2015 06:13 PM, Mandy Chung wrote: I’d like to get the code review done by this week. I renamed the static factory method from create to getInstance since “create” implies to create a new instance but the method returns a cached instance instead. I also changed the spec of

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

Hi Fred, On 11/11/2015 3:38 AM, frederic parain wrote: Hi David and Doug, Thank you for your feedback. I put some comments below. On 09/11/2015 08:12, David Holmes wrote: Hi Doug, On 9/11/2015 9:31 AM, Doug Lea wrote: On 11/06/2015 02:23 AM, David Holmes wrote: Before I look at the

Re: RFR (JAXP) : 8142900: Xerces Update: Xerces XPath

Thanks Lance! Joe On 11/14/2015 9:41 AM, Lance Andersen wrote: Hi Joe, Looks OK. Best Lance On Nov 13, 2015, at 6:15 PM, huizhe wang > wrote: Additional fix: Fixed all warnings in the group: [cast] redundant cast to char in REUtil,

Re: RFR: jsr166 jdk9 integration wave 2

Hi Martin, On 11/17/2015 12:39 AM, Martin Buchholz wrote: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ CancelledLockLoops/: OK CheckedMapBash/: OK CompletableFuture/: OK ConcurrentHashMap/: OK ReentrantReadWriteLock/: OK atomic/: OK! jtregTests/: Glanced over

Re: RFR: jsr166 jdk9 integration wave 2

On Mon, Nov 16, 2015 at 2:42 PM, Aleksey Shipilev < aleksey.shipi...@oracle.com> wrote: > > ForkJoinWorkerThread.newThread/: > * I think this one requires CCC, because it changes public API in > newThread. > > That's where someone from Oracle needs to help out ... > PhaserBasic/: > * Are

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

I’d like to get the code review done by this week. I renamed the static factory method from create to getInstance since “create” implies to create a new instance but the method returns a cached instance instead. I also changed the spec of getCallerClass per [1]. There is not much change

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

Hi Mandy, Sorry I was not clear. I'm proposing the following changes: StackFrameInfo.java: 100 public OptionalInt getLineNumber() { 101 ensureMethodInfoInitialized(); 102 return lineNumber != -1 && lineNumber != -2 ? OptionalInt.of(lineNumber)