April 2016 - core-libs-dev

Re: RFR [9] 8150829: Enhanced drop-args, identity and default constant, varargs adjustment
by Paul Sandoz 12 Apr '16

12 Apr '16

Hi, Just minor comments, below. Paul. MethodHandle — 972 /** 973 * Adapts this method handle to be {@linkplain #asVarargsCollector variable arity} 974 * if the boolean flag is true, else {@linkplain #asFixedArity fixed arity}. 975 * If the method handle is already of the proper arity mode, it is returned 976 * unchanged. 977 * <p>This method is sometimes useful when adapting a method handle that 978 * may be variable arity, to ensure that the resulting adapter is also 979 * variable arity if and only if the original handle was. For example, 980 * this code changes the first argument of a handle , {@code mh}, to {@code int} without 981 * disturbing its variable arity property: 982 * {@code mh.asType(mh.type().changeParameterType(0,int.class)).withVarargs(mh.isVarargsCollector())} The above paragraph can be an @apiNote. Also can you format the code block over two lines to emphasise the last call., otherwise i think it is harder to read. 983 * @param makeVarargs true if the return method handle should have variable arity behavior 984 * @return a method handle of the same type, with possibly adjusted variable arity behavior 985 * @throws IllegalArgumentException if {@code makeVarargs} is true and 986 * this method handle does not have a trailing array parameter 987 * @since 9 Add @see #asVarargsCollector @see #asFixedArity ? 988 */ 989 public MethodHandle withVarargs(boolean makeVarargs) { MethodHandles — 2387 /** Produces a constant method handle of the requested return type which new line after ‘/**' 2388 * returns the default value for that type every time it is invoked. 2389 * The resulting constant method handle will have no side effects. 2390 * <p>The returned method handle is equivalent to {@code empty(methodType(type))}. 2391 * It is also equivalent to {@code explicitCastArguments(constant(Object.class, null), methodType(type))}, 2392 * since {@code explicitCastArguments} converts {@code null} to default values. Is this method more efficient than the other two? 2393 * @param type the expected return type of the desired method handle 2394 * @return a constant method handle that takes no arguments and returns the default value of the given type (or void, if the type is void) Can you format to be a little more consistent and not so long on the line length, as it becomes really tricky read. 2395 * @throws NullPointerException if the argument is null 2396 * @see MethodHandles#constant 2397 * @see MethodHandles#empty 2398 * @since 9 2399 */ 2400 public static MethodHandle zero(Class<?> type) { 2401 Objects.requireNonNull(type); 2402 return type.isPrimitive() ? zero(Wrapper.forPrimitiveType(type), type) : zero(Wrapper.OBJECT, type); 2403 } 2404 2409 /** 2410 * Produces a method handle of the requested type which ignores any arguments, does nothing, 2411 * and returns a suitable default depending on the return type. 2412 * That is, it returns a zero primitive value, a {@code null}, or {@code void}. 2413 * <p>The returned method handle is equivalent to 2414 * {@code dropArguments(zero(type.returnType()), 0, type.parameterList())}. 2415 * <p> 2416 * Example: Given a predicate and target, a useful "if-then" construct can be constructed as s/Example:/@apiNote (same applies to the method dropArgumentsToMatch) s/constructed/produced 2417 * {@code guardWithTest(pred, target, empty(target.type())}. 2418 * @param type the type of the desired method handle 2419 * @return a constant method handle of the given type, which returns a default value of the given return type 2420 * @throws NullPointerException if the argument is null 2421 * @see MethodHandles#zero 2422 * @see MethodHandles#constant 2423 * @since 9 2424 */ 2425 public static MethodHandle empty(MethodType type) { 2726 MethodHandle h0= constant(boolean.class, true); Space before '=' ConstantIdentityMHTest — You should test the signatures and values for all primitives, ref and void. > On 11 Apr 2016, at 07:47, shilpi.rastogi(a)oracle.com wrote: > > Gentle Reminder! > > -------- Forwarded Message -------- > Subject: RFR [9] 8150829: Enhanced drop-args, identity and default constant, varargs adjustment > Date: Thu, 24 Mar 2016 11:18:56 +0530 > From: shilpi.rastogi(a)oracle.com <shilpi.rastogi(a)oracle.com> > Reply-To: core-libs-dev(a)openjdk.java.net > To: mlvm-dev(a)openjdk.java.net > > Hi All, > > Please review the following- > > > https://bugs.openjdk.java.net/browse/JDK-8150829 > http://cr.openjdk.java.net/~srastogi/8150829/webrev.04 > > > > Thanks, > Shilpi > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev(a)openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

1 0

RFR: 8153213: Jar manifest attribute "Multi-Release" accepts any value
by Steve Drach 12 Apr '16

12 Apr '16

Hi, I’ve updated the following patch, incorporating code by Claes Redestad to handle some corner cases while processing the attribute value. Note that we’ve limited the location of the value part of the attribute to accommodate startup performance requirements. It’s not without precedent as at least one other attribute is also limited in amount of whitespace surrounding the value. > Please review this simple fix to require that the jar manifest Multi-Release attribute has a value of “true" in order to be effective, i.e. to assert the jar is a multi-release jar. issue: https://bugs.openjdk.java.net/browse/JDK-8153213 <https://bugs.openjdk.java.net/browse/JDK-8153213> webrev: http://cr.openjdk.java.net/~sdrach/8153213/webrev.01/index.html <http://cr.openjdk.java.net/~sdrach/8153213/webrev.01/index.html> Thanks Steve

3 2

RFR: 8151876: (tz) Support tzdata2016c
by Ramanand Patil 12 Apr '16

12 Apr '16

Hi all, Please review the latest TZDATA (tzdata2016c) integration to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ All the TimeZone related tests are passed after integration. Please note that this patch includes both tzdata2016b and tzdata2016c integration. The tzdata2016b review was abandoned because tzdata2016c was already released. As suggested by Masayoshi, changes are made such that, "GMT+hh:mm" is used for formatting of the newly added TimeZones in tzdata2016b. [This is done to accommodate the IANA's new trial system where the new zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] Regards, Ramanand.

3 4

[9] RFR 4154028: Several hotspot tests need to be updated after 8153737 (Unsupported Module)
by Alejandro Murillo 12 Apr '16

12 Apr '16

Can I get a quick review for this fix that's blocking the synching of jdk9/hs with jdk9/dev: Basically, https://bugs.openjdk.java.net/browse/JDK-8153737 introduced some changes that need to be applied to several hotspot tests that were not in jdk9/dev by the time that fix was pushed. They can't be fixed on either repo, the need to be fixed in the merging repo before being pushed back to jdk9/hs (first) Bug https://bugs.openjdk.java.net/browse/JDK-8154028 Webrev: http://cr.openjdk.java.net/~amurillo/9/8154028/ I'm running a sanity test job now, but wanted to get the review going as I need to get the synch done ASAP to start PIT Thanks -- Alejandro

3 4

JDK 9 RFR of JDK-8154031: Mark tools/pack200/BandIntegrity.java as intermittently failing
by Amy Lu 12 Apr '16

12 Apr '16

tools/pack200/BandIntegrity.java This test is known to fail intermittently (JDK-8153815). This patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8154031 webrev: http://cr.openjdk.java.net/~amlu/8154031/webrev.00/ Thanks, Amy --- old/test/tools/pack200/BandIntegrity.java 2016-04-12 09:45:31.000000000 +0800 +++ new/test/tools/pack200/BandIntegrity.java 2016-04-12 09:45:31.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -26,6 +26,7 @@ * @summary test ensures the proper sequencing of bands, dump bands as well. * @compile -XDignore.symbol.file Utils.java BandIntegrity.java * @run main BandIntegrity + * @key intermittent * @author ksrini */ import java.io.File;

2 1

PING: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place
by Langer, Christoph 11 Apr '16

11 Apr '16

Hi, Ping: Any comments on my changes? Thanks Christoph From: Langer, Christoph Sent: Donnerstag, 7. April 2016 22:45 To: core-libs-dev(a)openjdk.java.net Subject: RFR: JDK-8153781 Issue in XMLScanner: EXPECTED_SQUARE_BRACKET_TO_CLOSE_INTERNAL_SUBSET when skipping large DOCTYPE section with CRLF at wrong place Hi, I've run into a peculiar issue with Xerces. The problem is happening when a DTD shall be skipped, the DTD is larger than the buffer of the current entity and a CRLF sequence occurs just one char before the buffer end. The reason is that method skipDTD of class XMLDTDScannerImpl (about line 389) calls XMLEntityScanner.scanData() to scan for the next occurrence of ']'. The scanData method might return true which indicates that the delimiter ']' was not found yet and more data is to scan. Other users of scanData would handle this and call this method in a loop until it returns false or some other condition happens. So I've fixed that place like at the other callers of scanData. Nevertheless, the scanData method would usually load more data when it is at the end of the buffer. But in the special case when CRLF is found at the end of buffer - 1, scanData would just return true. So I also removed that check at line 1374 in XMLEntityScanner. Do you see any problem with that? Is there any reason behind it which I'm overseeing? Furthermore I took the chance for further little cleanups. I've added the new copyright header to the files... is that the correct one? I also aligned the calls to invokeListeners(position) in XMLEntityScanner to always pass the actual position from which the load is started. Do you think this is correct? Here is the bug: https://bugs.openjdk.java.net/browse/JDK-8153781 Here is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8153781.0/ Please give me some comments before I finalize my change including a jtreg testcase. Thanks & Best regards Christoph

1 0

RFR(S): 8153637: MethodHandles.countedLoop/3 initialises loop counter to 1 instead of 0
by Michael Haupt 11 Apr '16

11 Apr '16

Dear all, please review this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8153637 Webrev: http://cr.openjdk.java.net/~mhaupt/8153637/webrev.00/ The countedLoop implementation currently initialises the loop counter to the start value and, because this takes place in the very first loop clause, increments it immediately, leading to start+1 being passed to the first body invocation. The solution passes counter-1 to body. Alternatives that were considered include initialising the counter to start-1 (possible counting range is diminished), and to reorder loop clauses to move counter increment to the end of the loop (requires argument permutation). Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

3 2

RFR 8152645 VarHandle lookup access control tests
by Paul Sandoz 11 Apr '16

11 Apr '16

Hi, Please review a test to verify access control of looking up fields using a VarHandle: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8152645-VH-access-control/webr… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8152645-VH-access-control/webr…> For completeness i also added tests for MH as i could not find any such existing tests. Further follow on work might be to test lookup to fields across module boundaries. Paul.

3 4

RFR 8151706: Update VarHandle implementation to use @Stable arrays
by Paul Sandoz 11 Apr '16

11 Apr '16

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/w… <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8151706-VH-form-table-stable/w…> Now that @Stable arrays are supported by C1 (thanks Vladimir!) we can switch from the explicit use of MemberName fields in VarForm to a @Stable MemberName[] array. I also took the opportunity to simplify the linking from a VarHandle impl to MemberName[] array, now that the implementation has settled down. This will reduce initialization costs and memory churn. I held off making further improvements for now. For example, VarForm can probably go away (also removing the dependency on ClassValue). A VarHandle instance can directly hold a MemberName[] array whose source reference is statically held on the associated VarHandle implementation. It should also be possible to lazily create MemberName instances as required, rather than aggressively doing so, which may further reduce initialization costs and memory usage in common cases. Paul.

4 4

RFR: JDK-8152115 (proxy) Examine performance of dynamic proxy creation
by Peter Levart 11 Apr '16

11 Apr '16

Hi, With Mandy we have prepared the following patch to restore performance of java.lanf.reflect.Proxy class caching that has regressed with introduction of additional checks that have to be performed due to modules: http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.caching/webrev.05/ Jigsaw changed caching of proxy classes from ClassLoader+interfaces to Module+interfaces to accommodate possible future extension of the API that might take given Module as a parameter. Additional validation of constraints and derivation of dynamic module to host proxy class was performed on the fast path, degrading performance. This change restores the caching back to ClassLoader+interfaces, but also introduces new caching mechanism that allows simple derivation of other coexisting caching schemes that can support possible additions to the Proxy API. The new mechanism also simplifies caching by avoiding the need to reference ClassLoader and interfaces through WeakReference objects. Instead it uses a single ConcurrentHashMap per ClassLoader instance referenced directly from ClassLoader object. The caching API - ClassLoaderValue - is general enough to be used for other purposes where caching per ClassLoader is desired. Currently it is encapsulated as a java.lang.reflect package-private API, but could simply be promoted to a public API in an internal concealed package if desired. Performance of Proxy class caching is back to pre-jigsaw state and even better: http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.caching/ProxyBench.java @Mandy I haven't yet removed the superfluous checking and providing access from dynamic module to the modules/packages of transitive closure of interfaces implemented by proxy class. I think this should be done in a separate issue so that this change doesn't change the semantics of implementation. Regards, Peter

2 4