May 2014 - core-libs-dev

RFR (S) 9 and 8u: JDK-8038994: AnnotatedType.getType() of a TypeVariable boundary without annotations return null
by Joel Borggren-Franck 16 May '14

16 May '14

Hi, Here is a fix for: https://bugs.openjdk.java.net/browse/JDK-8038994 In short, getAnnotatedFoo.getType() is supposed to return the same Type as getGenericFoo(). This wasn't the case for a type variable bound without an annotation previously. Also cleaned up an allocation while in the neighborhood. Webrev here: http://cr.openjdk.java.net/~jfranck/8038994/webrev.00/ cheers /Joel

2 4

RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused
by Christian Thalinger 15 May '14

15 May '14

https://bugs.openjdk.java.net/browse/JDK-8032606 http://cr.openjdk.java.net/~twisti/8032606/webrev.00 8032606: ClassValue.ClassValueMap.type is unused Reviewed-by:

3 3

RFR JDK-7153400: ThreadPoolExecutor's setCorePoolSize method allows corePoolSize > maxPoolSize
by Pavel Rappo 15 May '14

15 May '14

Hi everyone, could you please review my change for JDK-7153400? http://cr.openjdk.java.net/~chegar/7153400/00/webrev/ http://ccc.us.oracle.com/7153400 It's a long expected fix for a minor issue in the ThreadPoolExecutor. This has been agreed with Doug Lea. The exact same change (except for the test) is already in jsr166 repo: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/conc… Thanks -Pavel

5 11

RFR 9: 8034903: Add Logging of Process.start arguments and resulting pid
by roger riggs 15 May '14

15 May '14

Hi, Having folks stumbling over process creation and problems of quoting, especially on windows, it seems useful to log the native commands and arguments. They are proposed to be logged using the PlatformLogger at Level.FINE which will not be logged by default. The environment is useful in some cases, but verbose, that it should be Logged at FINER. The pid of the spawned process logged as well for traceability. Please take a look at this first draft and comment on whether it is useful, a good idea and any improvements needed. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-log-processcreate/ Thanks, Roger

13 27

RFR: 8043012: (tz) Support tzdata2014c
by Aleksej Efimov 15 May '14

15 May '14

Hello, Can I have a review for the tzdata2014c integration to JDK9. This is a standard release of tzdata (except the hurry with Egypt rules - the main part in this release). The following set of tests was executed with no failures: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar Webrev: http://cr.openjdk.java.net/~aefimov/8043012/9/webrev.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8043012 Thank you, Aleksej

3 2

8043119: (props) Properties.storeToXML closes output stream
by Alan Bateman 14 May '14

14 May '14

This is a follow-up to the recent change to the modules motivated switch of the Properties XML methods to consistently use the UKit parser. An issue that has surfaced since is that the wrapper around UKit is incorrectly closing the output stream after writing the XML document, a basic assertion not covered by the tests in the jdk repository. Trivial fix: http://cr.openjdk.java.net/~alanb/8043119/webrev/ -Alan.

3 2

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache
by Vladimir Ivanov 14 May '14

14 May '14

Tobias, I agree with your evaluation. My only concern is that @Stable doesn't work for AtomicReferenceArray, so JIT doesn't see what is stored in the array. Maybe use a lock instead? Best regards, Vladimir Ivanov On 5/14/14 2:33 PM, Tobias Hartmann wrote: > Hi Remi, > > sorry, I accidentally reverted that part.. Here is the correct webrev: > > http://cr.openjdk.java.net/~anoll/8005873/webrev.01/ > > Thanks, > Tobias > > On 14.05.2014 12:04, Remi Forax wrote: >> your patch doesn't work ! >> >> the array is still allocated as an classical array in the constructor. >> >> cheers, >> Remi >> >> Envoyé avec AquaMail pour Android >> http://www.aqua-mail.com >> >> >> Le 14 mai 2014 11:04:41 Tobias Hartmann <tobias.hartmann(a)oracle.com> a >> écrit : >> >>> Hi, >>> >>> please review the following patch for bug 8005873. >>> >>> *Problem* >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8005873 >>> >>> The test creates multiple threads (~500) that repeatedly execute >>> invokeExact on a method handle referencing a static method. The call >>> to invokeExact is performed through an optimized inline cache >>> (CompiledStaticCall) that points to the LambdaForm generated for the >>> method handle. The IC is first set to interpreted code by >>> CompiledStaticCall::set_to_interpreted(...) but soon updated to refer >>> to the compiled version of the lambda form (-Xcomp). >>> >>> Because tiered compilation is enabled, the VM decides to compile the >>> LambdaForm at a different level and sets the old version to >>> not-entrant. The next call through the IC therefore triggers a >>> re-resolving of the call site finally performing a Java upcall to >>> java.lang.invoke.MethodHandleNatives::linkMethod(...) (see call >>> sequence [1]). A *new* LambdaForm is returned and >>> CompiledStaticCall::set_to_interpreted(...) is executed again to >>> update the IC. The assert is hit because the callee differs. >>> >>> The problem is that there are multiple LambdaForms created for the >>> same invokeExact instruction. Caching in the Java runtime code should >>> guarantee that only one LambdaForm is created and reused. >>> Instrumenting Invokers::invokeHandleForm(...) shows that almost all >>> requests result in a cache miss and return a new LambdaForm. >>> >>> This behaviour is caused by a race condition in >>> Invokers::invokeHandleForm(...). Threads may initially see a cache >>> miss when invoking MethodTypeForm::cachedLambdaForm(...), then create >>> a new LambdaForm and call MethodTypeForm::setCachedLambdaForm(...) to >>> update the cache without checking it again. In a high concurrency >>> setting, this leads to multiple LambdaForms being created for the >>> same invokeExact instruction because the cache entry is overwritten >>> by multiple threads. >>> >>> *Solution* >>> Webrev: http://cr.openjdk.java.net/~anoll/8005873/webrev.00/ >>> >>> An AtomicReferenceArray is used to cache the LambdaForms and >>> .get(...) and .compareAndSet(...) are used to retrieve and update the >>> cache entries. This allows only one thread to set the LambdaForm that >>> is then being used by all instances of the invokeExact. >>> >>> *Testing* >>> - Failing test (vm/mlvm/meth/stress/jni/nativeAndMH) >>> - Nashorn + Octane >>> - JPRT >>> >>> Many thanks to Christian Thalinger and Vladimir Ivanov! >>> >>> Best, >>> Tobias >>> >>> [1] Call sequence of reresolving the IC target >>> SharedRuntime::handle_wrong_method(...) >>> -> SharedRuntime::reresolve_call_site(...) >>> -> SharedRuntime::find_callee_method(...) >>> -> SharedRuntime::find_callee_info_helper(...) >>> -> LinkResolver::resolve_invoke(...) >>> -> LinkResolver::resolve_invokehandle(...) >>> -> LinkResolver::resolve_invokehandle(...) >>> -> LinkResolver::lookup_polymorphic_method(...) >>> -> SystemDictionary::find_method_handle_invoker(...) >>> -> Java upcall to java.lang.invoke.MethodHandleNatives::linkMethod(...) >>> -> Invokers::methodHandleInvokeLinkerMethod(...) >>> -> Invokers::invokeHandleForm(...) >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Backport? >> >> >

3 3

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache
by Remi Forax 14 May '14

14 May '14

your patch doesn't work ! the array is still allocated as an classical array in the constructor. cheers, Remi Envoyé avec AquaMail pour Android http://www.aqua-mail.com Le 14 mai 2014 11:04:41 Tobias Hartmann <tobias.hartmann(a)oracle.com> a écrit : > Hi, > > please review the following patch for bug 8005873. > > *Problem* > Bug: https://bugs.openjdk.java.net/browse/JDK-8005873 > > The test creates multiple threads (~500) that repeatedly execute > invokeExact on a method handle referencing a static method. The call to > invokeExact is performed through an optimized inline cache > (CompiledStaticCall) that points to the LambdaForm generated for the method > handle. The IC is first set to interpreted code by > CompiledStaticCall::set_to_interpreted(...) but soon updated to refer to > the compiled version of the lambda form (-Xcomp). > > Because tiered compilation is enabled, the VM decides to compile the > LambdaForm at a different level and sets the old version to not-entrant. > The next call through the IC therefore triggers a re-resolving of the call > site finally performing a Java upcall to > java.lang.invoke.MethodHandleNatives::linkMethod(...) (see call sequence > [1]). A *new* LambdaForm is returned and > CompiledStaticCall::set_to_interpreted(...) is executed again to update the > IC. The assert is hit because the callee differs. > > The problem is that there are multiple LambdaForms created for the same > invokeExact instruction. Caching in the Java runtime code should guarantee > that only one LambdaForm is created and reused. Instrumenting > Invokers::invokeHandleForm(...) shows that almost all requests result in a > cache miss and return a new LambdaForm. > > This behaviour is caused by a race condition in > Invokers::invokeHandleForm(...). Threads may initially see a cache miss > when invoking MethodTypeForm::cachedLambdaForm(...), then create a new > LambdaForm and call MethodTypeForm::setCachedLambdaForm(...) to update the > cache without checking it again. In a high concurrency setting, this leads > to multiple LambdaForms being created for the same invokeExact instruction > because the cache entry is overwritten by multiple threads. > > *Solution* > Webrev: http://cr.openjdk.java.net/~anoll/8005873/webrev.00/ > > An AtomicReferenceArray is used to cache the LambdaForms and .get(...) and > .compareAndSet(...) are used to retrieve and update the cache entries. This > allows only one thread to set the LambdaForm that is then being used by all > instances of the invokeExact. > > *Testing* > - Failing test (vm/mlvm/meth/stress/jni/nativeAndMH) > - Nashorn + Octane > - JPRT > > Many thanks to Christian Thalinger and Vladimir Ivanov! > > Best, > Tobias > > [1] Call sequence of reresolving the IC target > SharedRuntime::handle_wrong_method(...) > -> SharedRuntime::reresolve_call_site(...) > -> SharedRuntime::find_callee_method(...) > -> SharedRuntime::find_callee_info_helper(...) > -> LinkResolver::resolve_invoke(...) > -> LinkResolver::resolve_invokehandle(...) > -> LinkResolver::resolve_invokehandle(...) > -> LinkResolver::lookup_polymorphic_method(...) > -> SystemDictionary::find_method_handle_invoker(...) > -> Java upcall to java.lang.invoke.MethodHandleNatives::linkMethod(...) > -> Invokers::methodHandleInvokeLinkerMethod(...) > -> Invokers::invokeHandleForm(...) > > > > > > > > > > Backport?

1 0

RFR: 8042906: Remove use of reflection in ORB
by Seán Coffey 13 May '14

13 May '14

Now that JDK 8 is the official build bootstrap JDK for JDK 9, we can remove use of reflection in ORB code to access the applet context. bug report : https://bugs.openjdk.java.net/browse/JDK-8042906 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8042906/webrev/ regards, Sean.

6 12

8042889: (props) Properties.loadFromXML/storeToXML should consistently use the UKit parser
by Alan Bateman 13 May '14

13 May '14

In JDK 8 we brought in a tiny XML parser to support the Properties loadFromXML/storeToXML methods. We needed this for the Compact Profiles work, specifically builds of compact1 as they do not have JAXP/XML APIs. At the time we were a bit nervous about switching the XML parser for anything other than compact1 builds. One reason for this was that the original javadoc didn't constrain the encodings that has to be supported, another reason was confidence in the tests as we didn't have too many tests for these methods in the jdk repository. I'd like to revisit one and switch over the implementation to always use the small parser. This allows for some clean-up, specifically it removes the need for the JDK-internal service type that was needed to use the JAXP code. On the original concerns then the spec was clarified in 8 to only require UTF-8 and UTF-16. In addition there were several tests added to better exercise these methods and the implementation. Also I think switching this early in JDK 9 means that we maximize the time to hear about any issues. The webrev with the proposed changes is here, mostly red=removal so easy to review: http://cr.openjdk.java.net/~alanb/8042889/webrev/ -Alan.

4 5