Re: Impact of code difference in Collection#contains() worth improving?

On Aug 29, 2014, at 7:33 PM, John Rose wrote: > . . . > Changing source code on based on the difference between 0 and -1 is almost as > pointless as removing whitespace and comments . . . Well said, John! But I cannot resist recalling that one of the earliest pieces of software in the impleme

Re: Impact of code difference in Collection#contains() worth improving?

On Aug 29, 2014, at 5:27 PM, Martin Buchholz wrote: > I agree that the benefit is very small, but I am coming at this from source > code consistency and bytecode size (not jitted code performance), and I think > bytecode size is at least one of the problems with assert. We agree about JDK-6445

Re: Impact of code difference in Collection#contains() worth improving?

Hi John, I agree that the benefit is very small, but I am coming at this from source code consistency and bytecode size (not jitted code performance), and I think bytecode size is at least one of the problems with assert. ... I filed that bug long ago, but no action yet https://bugs.openjdk

Re: RFR: 8055949: ByteArrayOutputStream capacity should be maximal array size permitted by VM

I decided to care just enough about the last 2x of scalability, but not about the last 8 elements. Your code would resize the 2g elements 8 times before finally reaching MAX_VALUE... Now I'm back in not-caring-anymore mode. At least about MAX_ARRAY_SIZE. On Wed, Aug 27, 2014 at 3:41 AM, Ulf Zibi

Re: Impact of code difference in Collection#contains() worth improving?

On Aug 29, 2014, at 1:05 PM, Ulf Zibis wrote: > Thanks for explaining this, but a very little nit: the immediate (I.e. -1) > uses additional 32/64 bits in code which must be loaded from memory and > wastes space in CPU cache or am I wrong? This could be saved with >= 0. I have to say you're mo

RFR (7u): 8046070 - Class Data Sharing clean up and refactoring

Bug: https://bugs.openjdk.java.net/browse/JDK-8046070 jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-August/012235.html jdk9 webrev: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-vfinal/ jdk8u-40 webrev: http://cr.openjdk.java.net/~iklam/8046070-cds-

Re: Impact of code difference in Collection#contains() worth improving?

Refactoring the hierarchy should be separate (and much more controversial) change. This change is a clean win, just very small. Refactoring runs into space/time tradeoffs. On Fri, Aug 29, 2014 at 3:23 PM, Vitaly Davidovich wrote: > :) so if you're going to do this, is there no base class in t

Re: Impact of code difference in Collection#contains() worth improving?

:) so if you're going to do this, is there no base class in the hierarchy where this can be placed (I don't have source in front of me)? That way there's a higher likelihood that the pattern will stay consistent (with new implementations at least). Sent from my phone On Aug 29, 2014 5:56 PM, "Mart

Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

It's probably best to teach the JIT to handle more of these cases. The reason is I don't think the longer compile time will be worth it considering that, on a large codebase, there will inevitably be lots of places where these patterns appear but have no dominance at runtime (either because they'r

Re: Impact of code difference in Collection#contains() worth improving?

Just think - one whole byte saved for each individual change! I have a webrev! http://cr.openjdk.java.net/~martin/webrevs/openjdk9/pico-optimize-contains/ https://bugs.openjdk.java.net/browse/JDK-8056951 Can haz review please? On Fri, Aug 29, 2014 at 1:05 PM, Ulf Zibis wrote: > > Am 28.08.2014

Re: Impact of code difference in Collection#contains() worth improving?

Yes, the immediate is part of the instruction encoding, so takes up space. However, I believe the CMP instruction allows comparison of an immediate with a wider register (e.g. cmp $-1, %eax), in which case the immediate takes up 1 byte and is then sign extended to the size of the register. But ag

Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

Hi compiler people, is there some chance that javac could be enhanced to optimize better as discussed in this thread? Than refactoring of up to now better readable code to ugly StringBuilder@append() code would be superfluous. I really like the String concatenation syntax, but unfortunately it

Re: RFR 8056249 Improve CompletableFuture resource usage

> On 29 Aug 2014, at 16:56, Martin Buchholz wrote: > > Looks fine. +1 -Chris. > Instead of using Contributed-by: for Doug's work, you should make him the > hg "user", as is done in previous changesets. E.g. hg import has a --user > flag. > > All of jsr166 CVS src/main is ready for sync'ing

Re: Impact of code difference in Collection#contains() worth improving?

Am 28.08.2014 um 19:46 schrieb Vitaly Davidovich: There's no register pressure - the immediate (I.e. -1) is encoded directly into the instruction, just like 0 would be. The time when 0 is particularly useful is when you test for it in the zero bit of the flags register (e.g. dec followed by

Re: Impact of code difference in Collection#contains() worth improving?

Am 28.08.2014 um 19:30 schrieb Louis Wasserman: Comparator is spec'd to be allowed to return any number, positive, negative, or zero, but indexOf is specifically spec'd to return -1. Yes, I know. I wanted to say, that from this knowing some developer might assume the same for indexOf when suc

RFR: JDK-8056934: ZipInputStream does not correctly handle local header data descriptors with the optional signature missing

Hi Xueming and Alan, I'd like you to do a code review. https://bugs.openjdk.java.net/browse/JDK-8056934 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/ This seems like an atypical off-by-one, so I'm not sure how it happened, and I have the nagging feeling

Re: RFR 8037819: Xerces Update: jaxp/validation/XMLSchemaFactory

Thanks Lance. A TCK test I started when I saw your comment is just completed without any relevant failure. Have a good weekend! Best, Joe On 8/29/2014 9:47 AM, Lance Andersen wrote: Hi Joe, This looks OK. I assume all TCK/JCK tests have been run and still pass as an additional sanity chec

Re: Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests

Hi Tristan, Looks good. I left notes in the bug's comment section as a record and status of the original test development. Thanks, Joe On 8/29/2014 9:50 AM, Tristan Yan wrote: Hi Joe, Alan and others I took over Eric’s last work and did some refactor for his code. Please help to review the

[9] RFR (S): 8056926: Improve caching of GuardWithTest combinator

http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8056926 Cache GuardWithTest per erased to basic types signature. GWT shape is made friendly to sharing: * GWT MH is implemented as BMH which stores 3 method handles * LF loads them from the assoc

Re: Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests

Hi Joe, Alan and others I took over Eric’s last work and did some refactor for his code. Please help to review the code change again. webrev: http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/ bug: https://bugs.openjdk.java.net/brows

Re: RFR 8037819: Xerces Update: jaxp/validation/XMLSchemaFactory

Hi Joe, This looks OK. I assume all TCK/JCK tests have been run and still pass as an additional sanity check ? Have a good weekend. Best, Lance On Aug 26, 2014, at 1:41 PM, huizhe wang wrote: > Hi, > > Please review update to XMLSchemaFactory along with changes to relevant > classes. All

Re: RFR 8056248: Improve ForkJoin thread throttling

Approved. Thanks for doing this. On Fri, Aug 29, 2014 at 3:43 AM, Paul Sandoz wrote: > Hi, > > Please review fixes by Doug to For/Join to improve thread throttling (e.g. > for nested parallel streams). This fix resulted in a lot of internal > refactoring and clean up. > > In addition a new sys

Re: RFR 8056249 Improve CompletableFuture resource usage

Looks fine. Instead of using Contributed-by: for Doug's work, you should make him the hg "user", as is done in previous changesets. E.g. hg import has a --user flag. All of jsr166 CVS src/main is ready for sync'ing with openjdk9, i.e. there are no known bugs, even though some future improvements

Re: RFR: 5043030 (reflect) unnecessary object creation in reflection

Hi Joel, >> I have changed the test TestMethodReflectValueOf as you suggested and I have >> changed the summary of both tests too. You will find the changes in the >> attached patch. Here is the new webrev: https://db.tt/wQBLVceA >> >> And here is the coverage report in the HTML format: >> >>

Re: DMH to fields, casts and type profiling Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

On Aug 29, 2014, at 12:45 AM, John Rose wrote: > On Aug 28, 2014, at 7:38 AM, Paul Sandoz wrote: > >> On Jul 8, 2014, at 9:09 PM, John Rose wrote: >> >>> Regarding the extra cast in accessor logic that Paul picked up on: That >>> may be a left-over from obsolete versions of the code, or it

Re: A List from Iterator

ArrayList list = ... iterator.forEachRemaining(list::add); Rémi On 29 août 2014 00:22:11 UTC+02:00, Pavel Rappo wrote: >> If we were to provide a Collections util it would to wrap Enumeration >as an Iterator but that's it. > >Mike, that's what I'm talking about. It's just for convenience. > >-Pa

Re: RFR 8056249 Improve CompletableFuture resource usage

On Aug 29, 2014, at 3:38 PM, Chris Hegarty wrote: > > On 29/08/14 11:01, Paul Sandoz wrote: >> Hi, >> >> Please review fixes by Doug to j.u.c.CompletableFuture to better control >> resources for long completion chains (e.g. avoiding stack overflows). This >> fix resulted in a lot of internal

Re: RFR 8056249 Improve CompletableFuture resource usage

On Aug 29, 2014, at 3:35 PM, Doug Lea wrote: > >> Is the following snippet missing from the doc updates to the methods >> CompletationStage.handle and handleAsync? > > While touching up wording, we noticed that this sentence doesn't capture > all the cases that are described in the top-level Co

Re: RFR 8056249 Improve CompletableFuture resource usage

On 29/08/14 11:01, Paul Sandoz wrote: Hi, Please review fixes by Doug to j.u.c.CompletableFuture to better control resources for long completion chains (e.g. avoiding stack overflows). This fix resulted in a lot of internal refactoring and clean up. There are also some doc clarifications fo

Re: RFR 8056249 Improve CompletableFuture resource usage

On 08/29/2014 06:01 AM, Paul Sandoz wrote: Hi, Please review fixes by Doug to j.u.c.CompletableFuture to better control resources for long completion chains (e.g. avoiding stack overflows). This fix resulted in a lot of internal refactoring and clean up. There are also some doc clarification

Re: RFR: 5043030 (reflect) unnecessary object creation in reflection

Hi Andrej, On 22 jun 2014, at 00:00, Andrej Golovnin wrote: > Hi Joel, > > sorry for late response. I was too busy with other things. > Likewise! > I have changed the test TestMethodReflectValueOf as you suggested and I have > changed the summary of both tests too. You will find the changes

Re: RFR: [8056310] Cleanup in WinNTFileSystem_md.c

On 28/08/2014 23:28, Ivan Gerasimov wrote: Hello! This is a proposal to make some minor cleanup in WinNTFileSystem_md.c: - fix a typo in error message, Looks okay. - use wide char constant for consistency, Looks okay. - avoid an array reallocation for power-of-two sizes, It's a bit of corner

RFR 8056248: Improve ForkJoin thread throttling

Hi, Please review fixes by Doug to For/Join to improve thread throttling (e.g. for nested parallel streams). This fix resulted in a lot of internal refactoring and clean up. In addition a new system property was added "java.util.concurrent.ForkJoinPool.common.maximumSpares" (which i suspect

RFR 8056249 Improve CompletableFuture resource usage

Hi, Please review fixes by Doug to j.u.c.CompletableFuture to better control resources for long completion chains (e.g. avoiding stack overflows). This fix resulted in a lot of internal refactoring and clean up. There are also some doc clarifications for certain j.u.c.CompletationStage excepti

Re: Review request for JDK-8051540: Convert JAXP functin tests: org.xml.sax to jtreg (testNG) tests

On 28/08/2014 08:31, Michael Kay wrote: I haven't yet had a chance to look at the JAXP tests, but this kind of message suggests to me that they don't separate what is in JAXP (the interface) from what is in Xalan and Xerces (the implementations).Would that be a correct assumption? The "redire

Re: Replace concat String to append in StringBuilder parameters

So it's not that the optimization fails but there is no optimization on them yet. I do see the .append("x") case will be easy to deal with, but it looks like historically javac has not been a place to do many optimizations. It mostly converts the java source to byte codes in a 1-to-1 mapping an

Re: Review request: 8055856: checkdeps build target doesn't work for cross-compilation builds

Hello Mandy, Looks good. Just noticed another thing in CheckModules.gmk. You can remove the explicit FIXPATH as the variable JAVA already contains it. In general, only spec.gmk should need to worry about FIXPATH. If there are no other changes, I don't need to see another round before you pus