August 2014 - core-libs-dev

[9] RFR (S): 8056926: Improve caching of GuardWithTest combinator
by Vladimir Ivanov 01 Sep '14

01 Sep '14

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 associated MethodHandle Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}. Reviewed-by: vlivanov, ? Contributed-by: john.r.rose(a)oracle.com Thanks! Best regards, Vladimir Ivanov

2 4

Process API Updates (JEP 102)
by Ron Pressler 01 Sep '14

01 Sep '14

I might be a little late to this party, but recently I've had a (rather frustrating) need for the ability to execve a process rather than fork-exec it. I understand that the ability to exec (replace the current process's image) is also available on Windows. This operation (on ProcessBuilder?), which never returns, would have the same semantics as System.exit(pb.start().waitFor()), only it would replace the current JVM process (i.e. maintain the same pid/handle) with the command. This is required when a JVM process is used to set up and launch another, JVM or other, process, but we'd want the user running the program to be oblivious to the setup process (because, say, they want to monitor the running program with some OS tool). Ron

2 2

RFR 8056249 Improve CompletableFuture resource usage
by Paul Sandoz 01 Sep '14

01 Sep '14

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 exception handling methods (which most likely means a CCC is required). https://bugs.openjdk.java.net/browse/JDK-8056249 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8056249-cf-resource-usage/webr… -- Is the following snippet missing from the doc updates to the methods CompletationStage.handle and handleAsync? If the supplied function itself encounters an exception, then the returned stage exceptionally completes with this exception unless this stage also completed exceptionally. Paul.

4 7

RFR (7u): 8046070 - Class Data Sharing clean up and refactoring
by Ioi Lam 31 Aug '14

31 Aug '14

Bug: https://bugs.openjdk.java.net/browse/JDK-8046070 jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-August/0122… jdk9 webrev: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-vfinal/ jdk8u-40 webrev: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-backport-8u40/ The JDK 9 changes in the open source code applied mostly cleanly with some minor manual reshuffling of the source code but otherwise no semantic differences. Thanks Ioi

2 1

Re: [8u-dev] RFR: 8036981: JAXB not preserving formatting for xsd:any Mixed content
by Aleksej Efimov 31 Aug '14

31 Aug '14

Hi, I'm adding a core-libs-dev mail list - I might be lucky to find a JDK8 reviewer for my fix there. Thank you, Aleksej On 08/26/2014 06:12 PM, Aleksej Efimov wrote: > Hi Dalibor, > > It's a partial backport (logged with a different bugID) of JDK9 fix, I > got an approval from Miran (Thank you Miran!) and right now I'm > waiting for a JDK8 reviewer approval. > > -Aleksej > > On 08/26/2014 04:58 PM, dalibor topic wrote: >> Hi Aleksej - are you looking for approval to push into jdk8u-dev? >> >> cheers, >> dalibor topic >> >> On 22.08.2014 22:01, Miroslav Kos wrote: >>> Hi Aleksej, >>> looks good to me. >>> >>> Thanks >>> Miran >>> >>> >>> On 18/08/14 17:29, Aleksej Efimov wrote: >>>> Hi, >>>> >>>> Can I ask for a review of 8036981 bug [1] fix: >>>> JAXWS: >>>> http://cr.openjdk.java.net/~aefimov/8036981/8/webrev.00/jaxws/ >>>> JDK: http://cr.openjdk.java.net/~aefimov/8036981/8/webrev.00/jdk/ >>>> >>>> The proposed fix is a partial backport of "Update JAX-WS RI >>>> integration to latest version" bug [2] to JDK8. >>>> The proposed patch fixes the broken formatting of the input xml during >>>> JAXB marshalling/unmarshalling. Regression test is included. >>>> Testing: >>>> - regtests: xml related tests from 'core' testset - no failures >>>> - JCK: api/xinclude api/xsl api/javax_xml api/org_xml xml_schema >>>> api/xinclude - no failures >>>> >>>> Thank you, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8036981 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8044656 >>>> [3] 8044656 JDK9 review thread: >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027458.html >>>> >>>> >>>> >>> >> >

2 4

RFR: 8055949: ByteArrayOutputStream capacity should be maximal array size permitted by VM
by Martin Buchholz 29 Aug '14

29 Aug '14

Hi friends of ByteArrayOutputStream, I'm trying to clean up an apparent oversight when I tried to fix huge array resizing back in 6933217: Huge arrays handled poorly in core libraries https://bugs.openjdk.java.net/browse/JDK-8055949 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ByteArrayOutputStream-M… The 2x capacity gap was noticed by real users!

4 7

Re: Impact of code difference in Collection#contains() worth improving?
by Vitaly Davidovich 29 Aug '14

29 Aug '14

:) 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, "Martin Buchholz" <martinrb(a)google.com> wrote: 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 <Ulf.Zibis(a)cosoco.de> wrote: > > 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 jz, such as when counting a loop down to >> 0). Otherwise, I don't see any advantage from machine code perspective. >> >> > 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. > > So if unifying the code I agree to Martin's opinion. > > -Ulf > > The aforementioned cmov instruction is not without its own downsides, so >> it's unclear which is better when branch probability isn't known a priori. >> >> The 1 byte code is unlikely to make any difference, unless jit is turned >> off and you're running this through a tight loop in the interpreter (but if >> one does that, perf conversation is moot :)). >> >> Sent from my phone >> >> On Aug 28, 2014 1:28 PM, "Ulf Zibis" <Ulf.Zibis(a)cosoco.de <mailto: >> Ulf.Zibis(a)cosoco.de>> wrote: >> >> >> Am 27.08.2014 um 17:51 schrieb Martin Buchholz: >> >> The ArrayList version saves one byte of bytecode, and is >> therefore very >> slightly better. We should bless that version and use it >> consistently. >> >> >> +1 >> Additional argument: >> The LinkedList code requires to load 32/64-Bit -1 into CPU. This may >> take some time on some >> CPU and at least wastes memory footprint. >> Additionally register pressure increases. >> Vitaly, please correct me, if I'm wrong, just for learning more. >> >> Another advantage is that there is no problem if some implementation >> of indexOf() erroneously >> returns another negative value than -1. I remember some compare() >> implementations, which >> sometimes return different values than only -1, 0, +1. >> >> -Ulf >> >> ArrayList: >> >> public boolean contains(Object o) { >> return indexOf(o) >= 0; >> } >> >> LinkedList: >> >> public boolean contains(Object o) { >> return indexOf(o) != -1; >> } >> >> >> >

2 1

RFR 8037819: Xerces Update: jaxp/validation/XMLSchemaFactory
by huizhe wang 29 Aug '14

29 Aug '14

Hi, Please review update to XMLSchemaFactory along with changes to relevant classes. All new tests passed, as well as existing jaxp tests and JPRT. Note that this updates XMLSchemaFactory, related classes such as XMLShemaValidator are only updated to the related revisions. Full update of XMLSchemaValidator and XMLSchemaLoader will be done separately. http://cr.openjdk.java.net/~joehw/jdk9/8037819/webrev/ Thanks, Joe

2 2

RFR 8056248: Improve ForkJoin thread throttling
by Paul Sandoz 29 Aug '14

29 Aug '14

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 will only very rarely be used), so a CCC will be required: http://cs.oswego.edu/pipermail/concurrency-interest/2014-July/012838.html * <li>{@code java.util.concurrent.ForkJoinPool.common.maximumSpares} * - the maximum number of allowed extra threads to maintain target * parallelism (default 256). https://bugs.openjdk.java.net/browse/JDK-8056248 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8056248-fj-thread-throttling/w… -- Once this review is complete i think we should also backport to 8u40, and likewise for the CompletableFuture updates (which i forgot to mention in a previously related email). Both these updates have been soaking in the 166 repo for a month or two. No related test failures were reported for a JPRT run with both patches. Paul.

2 1

[9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms
by Vladimir Ivanov 29 Aug '14

29 Aug '14

http://cr.openjdk.java.net/~vlivanov/8037209/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8037209 440 lines changed: 313 ins; 67 del; 60 mod This is a cleanup of JSR292 code to improve bytecode assembly code for lambda forms. Contributed-by: john.r.rose(a)oracle.com Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby Configs: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30} -D...PROFILE_LEVEL={0,1} Best regards, Vladimir Ivanov

5 24