From albert.noll at oracle.com Tue Oct 1 00:27:59 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 01 Oct 2013 09:27:59 +0200 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <524471E4.6060508@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> Message-ID: <524A797F.2010006@oracle.com> Hi Vladimir, thanks again for looking at the patch. See comments inline: webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ On 26.09.2013 19:41, Vladimir Kozlov wrote: > Albert, > > There is small window between check and set_state where state can > became initialized or still be uninitialized: > + if (!is_initialized()) { > + set_state(failed); > > so you may hit assert in set_state(). > > I think you need to call set_state(failed) only when C1 runtime is > initialized after lock: > > if (should_perform_init()) { > if (buffer_blob == NULL) { > set_state(failed); > } else { > init_c1_runtime(); > set_state(initialized); > } > } > You are right. I adapted the patch according to your suggestion. > In this case it will match behavior for C2 which means that you need > to shutdown compilation since you was not able to initialize > compilation runtime. It will require more code to do proper shutdown > not just exiting thread (free compilation queues, resetting flags). An > it will be more complicated for Tiered case (I think we can use simple > approach to shutdown all compilations even if only one Compiler is not > initialized since it is rare case). > I added code to shut-down compilation. If compiler runtime initialization fails, a flag is set which disables compilation forever. In the current version, all compilers are disabled if C1 and/or C2 runtime initialization fails (also in case of tiered compilation). I think this solution is fine for now, since a compiler runtime initialization failure should not happen in practice. If it ever turns out to be a problem, i.e., it is required that we we use one compiler if the other compiler failed to initialize, I suggest we fix this in another bug. The current bug appears only due to an artificial setting of the code cache size. Compiler shut-down is performed by one thread. This thread waits until all compiler threads have exited to compiler loop. The thread then deletes all tasks from the compile queue, deletes the compiler objects, and sets the objects to NULL. Please let me know if you think this solution is fine, or if there are other things that need to be considered. The current version passed jprt. Many thanks again, Albert > If C1 runtime was initialized but we was not able to allocate buffer > for some threads your current code in compileBroker.cpp will handle > such case. So you don't need to set state to 'failed'. > > thanks, > Vladimir > > On 9/26/13 8:25 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks for looking at the patch. >> Here is the new webrev: >> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >> >> >> See comments inline: >> >> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>> Thank you, Albert >>> >>> I would suggest to do TieredStartAtLevel changes separately, it is not >>> related to this bug. >>> >> Done. >>> Second, how we can guard the initialization with a field >>> (_compiler_state and original _is_initialized) which is not static? >>> >>> You don't need separate local do_init in C*_Compiler.cpp since it is >>> used only once: >>> >> Done. >>> + if (should_perform_init()) { >>> >>> abstractCompiler.cpp: >>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>> should_perform_init() and set_state(). Why? There is assert in >>> check_prelock_state() called from Monitor::lock(): >>> >>> assert((!thread->is_Java_thread() || ((JavaThread >>> *)thread)->thread_state() == _thread_in_vm) >>> || rank() == Mutex::special, "wrong thread state for using >>> locks"); >>> >>> Compiler threads are Java threads, so you should be in VM state when >>> lock. How you did not hit this assert? >>> >> The state transition from native to VM (and ResetNoHandleMark) is now in >> compileBroker.cpp:1543. >>> >>> Typo in abstractCompiler.hpp 'methos': >>> >>> + // This method returns true for the first compiler thread that >>> reaches that methos. >>> >>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>> before but it was not accurate, it could be mistaking for Compile >>> object created for each compilation): >>> >>> + // This thread will initialize the compiler object. >>> >>> Swap lines (and use 'runtime' in the comment): >>> >>> ! bool is_initialized () { return _compiler_state == >>> initialized; } >>> ! // Get/set state of compiler objects >>> >>> >>> c2compiler.cpp: >>> >>> C2Compiler:: is not needed: >>> >>> + bool successful = C2Compiler::init_c2_runtime(); >>> >>> >> Fixed the issues above. >>> Should we exit Compiler thread which failed local buffer allocation >>> instead parking? Why keep resources allocated for it? >>> >> You are right, there is no reason the keep these threads around. >> Compiler threads wo are not initialized correctly >> now exit the VM. >> >> The patch is currently in west queue. >> >> Many thanks again, >> Albert >> >>> Thanks, >>> Vladimir >>> >>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I have a review for this patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>> >>>> >>>> Problem: C1/C2 compiler initialization can fail if there is not enough >>>> memory in the code cache to generate all stubs. >>>> This problem occurs only with a small code cache size. >>>> >>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>> disable compiler (C1 and/or C2) if the compiler / thread >>>> was not initialized correctly. >>>> >>>> Testing: jprt, test case, benchmarks >>>> >>>> This patch also contains a refactored version of compiler >>>> object/thread >>>> initialization. In the new version, a compiler object/thread is >>>> initialized prior entering the main compiler loop. In the old version, >>>> the check if the compiler/thread is initialized was >>>> done in the main compiler loop (and hence before every compilation). >>>> >>>> To continue execution with a limited code cache size, the code types >>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>> be 'critical' allocations in the code cache, i.e., they must use space >>>> reserved by CodeCacheMinimumFreeSpace. >>>> >>>> In addition I removed some unued code. >>>> >>>> Many thanks in advance for reviewing. >>>> >>>> Best, >>>> Albert >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131001/8dabf887/attachment-0001.html From john.r.rose at oracle.com Tue Oct 1 03:53:45 2013 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 01 Oct 2013 10:53:45 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Message-ID: <20131001105355.652B862C39@hg.openjdk.java.net> Changeset: dc261f466b6d Author: drchase Date: 2013-09-27 13:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dc261f466b6d 8025260: Methodhandles/JSR292: NullPointerException (NPE) thrown instead of AbstractMethodError (AME) Summary: Copied null-checks from templateInterpreter_CPU into methodHandles_CPU Reviewed-by: jrose, twisti ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp + test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java + test/compiler/jsr292/methodHandleExceptions/C.java + test/compiler/jsr292/methodHandleExceptions/I.java + test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java From albert.noll at oracle.com Tue Oct 1 05:04:59 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 01 Oct 2013 14:04:59 +0200 Subject: RFR (S): 8025656: compiler/8013496/Test8013496.sh fails on assert Message-ID: <524ABA6B.3040701@oracle.com> Hi, could I have a review for this small patch? bug: https://bugs.openjdk.java.net/browse/JDK-8025656 webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.00/ Problem: handle_full_code_cache is called when the calling thread is in a wrong state. Solution: Switch to the right thread state before calling sweeper. I also re-wrote the corresponding test. In the new version, the arguments take a larger InitialCodeCacheSize and ReservedCodeCacheSize. Too small code cache sizes can fail the compiler runtime initialization and hence the test. Checking proper compiler runtime initialization is checked by 8023014. Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131001/b791d195/attachment.html From vladimir.kozlov at oracle.com Tue Oct 1 09:17:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Oct 2013 09:17:32 -0700 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <524A797F.2010006@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> Message-ID: <524AF59C.3040908@oracle.com> Albert, In general it looks good. Please, test it extensively with Tiered with codecache size enough to initialize one compiler but not an other to verify your code. I think you need to swap lock and decrement otherwise it will deadlock: +bool AbstractCompiler::should_perform_shutdown() { + MutexLocker only_one(CompileThread_lock); + _num_compiler_threads--; comp->set_shut_down(); and delete _compilers[0]; should be done by one thread I think. Small note, you accidentally removed nl in c2compiler.cpp: - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. Thanks, Vladimir On 10/1/13 12:27 AM, Albert Noll wrote: > Hi Vladimir, > > thanks again for looking at the patch. See comments inline: > webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ > > On 26.09.2013 19:41, Vladimir Kozlov wrote: >> Albert, >> >> There is small window between check and set_state where state can became initialized or still be uninitialized: >> + if (!is_initialized()) { >> + set_state(failed); >> >> so you may hit assert in set_state(). >> >> I think you need to call set_state(failed) only when C1 runtime is initialized after lock: >> >> if (should_perform_init()) { >> if (buffer_blob == NULL) { >> set_state(failed); >> } else { >> init_c1_runtime(); >> set_state(initialized); >> } >> } >> > You are right. I adapted the patch according to your suggestion. > >> In this case it will match behavior for C2 which means that you need to shutdown compilation since you was not able to >> initialize compilation runtime. It will require more code to do proper shutdown not just exiting thread (free >> compilation queues, resetting flags). An it will be more complicated for Tiered case (I think we can use simple >> approach to shutdown all compilations even if only one Compiler is not initialized since it is rare case). >> > I added code to shut-down compilation. If compiler runtime initialization fails, a flag is set which disables > compilation forever. In the current > version, all compilers are disabled if C1 and/or C2 runtime initialization fails (also in case of tiered compilation). I > think this solution is fine for > now, since a compiler runtime initialization failure should not happen in practice. If it ever turns out to be a > problem, i.e., it is required that we > we use one compiler if the other compiler failed to initialize, I suggest we fix this in another bug. The current bug > appears only due to an artificial > setting of the code cache size. > > Compiler shut-down is performed by one thread. This thread waits until all compiler threads have exited to compiler > loop. The thread then > deletes all tasks from the compile queue, deletes the compiler objects, and sets the objects to NULL. > > Please let me know if you think this solution is fine, or if there are other things that need to be considered. > The current version passed jprt. > > Many thanks again, > Albert > >> If C1 runtime was initialized but we was not able to allocate buffer for some threads your current code in >> compileBroker.cpp will handle such case. So you don't need to set state to 'failed'. >> >> thanks, >> Vladimir >> >> On 9/26/13 8:25 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for looking at the patch. >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>> >>> >>> See comments inline: >>> >>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>> Thank you, Albert >>>> >>>> I would suggest to do TieredStartAtLevel changes separately, it is not >>>> related to this bug. >>>> >>> Done. >>>> Second, how we can guard the initialization with a field >>>> (_compiler_state and original _is_initialized) which is not static? >>>> >>>> You don't need separate local do_init in C*_Compiler.cpp since it is >>>> used only once: >>>> >>> Done. >>>> + if (should_perform_init()) { >>>> >>>> abstractCompiler.cpp: >>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>> should_perform_init() and set_state(). Why? There is assert in >>>> check_prelock_state() called from Monitor::lock(): >>>> >>>> assert((!thread->is_Java_thread() || ((JavaThread >>>> *)thread)->thread_state() == _thread_in_vm) >>>> || rank() == Mutex::special, "wrong thread state for using >>>> locks"); >>>> >>>> Compiler threads are Java threads, so you should be in VM state when >>>> lock. How you did not hit this assert? >>>> >>> The state transition from native to VM (and ResetNoHandleMark) is now in >>> compileBroker.cpp:1543. >>>> >>>> Typo in abstractCompiler.hpp 'methos': >>>> >>>> + // This method returns true for the first compiler thread that >>>> reaches that methos. >>>> >>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>> before but it was not accurate, it could be mistaking for Compile >>>> object created for each compilation): >>>> >>>> + // This thread will initialize the compiler object. >>>> >>>> Swap lines (and use 'runtime' in the comment): >>>> >>>> ! bool is_initialized () { return _compiler_state == >>>> initialized; } >>>> ! // Get/set state of compiler objects >>>> >>>> >>>> c2compiler.cpp: >>>> >>>> C2Compiler:: is not needed: >>>> >>>> + bool successful = C2Compiler::init_c2_runtime(); >>>> >>>> >>> Fixed the issues above. >>>> Should we exit Compiler thread which failed local buffer allocation >>>> instead parking? Why keep resources allocated for it? >>>> >>> You are right, there is no reason the keep these threads around. >>> Compiler threads wo are not initialized correctly >>> now exit the VM. >>> >>> The patch is currently in west queue. >>> >>> Many thanks again, >>> Albert >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> could I have a review for this patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>> >>>>> >>>>> Problem: C1/C2 compiler initialization can fail if there is not enough >>>>> memory in the code cache to generate all stubs. >>>>> This problem occurs only with a small code cache size. >>>>> >>>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>> was not initialized correctly. >>>>> >>>>> Testing: jprt, test case, benchmarks >>>>> >>>>> This patch also contains a refactored version of compiler object/thread >>>>> initialization. In the new version, a compiler object/thread is >>>>> initialized prior entering the main compiler loop. In the old version, >>>>> the check if the compiler/thread is initialized was >>>>> done in the main compiler loop (and hence before every compilation). >>>>> >>>>> To continue execution with a limited code cache size, the code types >>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>> be 'critical' allocations in the code cache, i.e., they must use space >>>>> reserved by CodeCacheMinimumFreeSpace. >>>>> >>>>> In addition I removed some unued code. >>>>> >>>>> Many thanks in advance for reviewing. >>>>> >>>>> Best, >>>>> Albert >>> > From morris.meyer at oracle.com Tue Oct 1 09:41:31 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 01 Oct 2013 12:41:31 -0400 Subject: RFR(M): 8016602 - revert SPARC V8 patch Message-ID: <524AFB3B.7050705@oracle.com> Folks, My earlier change set below is responsible for two regressions. 8016602 (BigApps) and 8022644 java.util.streams InfiniteStreamWithLimitOpTest test. changeset: 4803:46c544b8fbfc user: morris date: Fri Jun 07 16:46:37 2013 -0700 summary: 8008407: remove SPARC V8 support As the V8 removal was really touchy and I had to work back from the whole V8 removal to what I pushed in June, I would like to remove this change set. This change has been tested with JPRT. We can decide later to remove V8 in HotSpot - or work forward with a V9 clean implementation in Graal. --morris WEBREV - http://cr.openjdk.java.net/~morris/8016602.01 JBS - https://bugs.openjdk.java.net/browse/JDK-8016602 JBS - https://bugs.openjdk.java.net/browse/JDK-8022644 From vladimir.kozlov at oracle.com Tue Oct 1 10:33:11 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Oct 2013 10:33:11 -0700 Subject: RFR (S): 8025656: compiler/8013496/Test8013496.sh fails on assert In-Reply-To: <524ABA6B.3040701@oracle.com> References: <524ABA6B.3040701@oracle.com> Message-ID: <524B0757.8010101@oracle.com> Albert, I think the only problem is call to handle_full_code_cache() in C1 Compiler::get_buffer_blob(). Please verify that. There are calls during adapters generation and I don't see which state at that time. If the problem only in get_buffer_blob() it will be solved when you remove the call in 8023014. On other hand it will not hurt to have transition here. You need to fix comment: "This ensures that handle_full_code_cache()" should be "This ensures that possibly_sweep()" Fixing the test is fine. Thanks, Vladimir On 10/1/13 5:04 AM, Albert Noll wrote: > Hi, > > could I have a review for this small patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8025656 > webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.00/ > > Problem: handle_full_code_cache is called when the calling thread is in a wrong state. > > Solution: Switch to the right thread state before calling sweeper. > > I also re-wrote the corresponding test. In the new version, the arguments take a larger InitialCodeCacheSize > and ReservedCodeCacheSize. Too small code cache sizes can fail the compiler runtime initialization and hence > the test. Checking proper compiler runtime initialization is checked by 8023014. > > Many thanks in advance, > Albert > > From vladimir.kozlov at oracle.com Tue Oct 1 10:45:50 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 01 Oct 2013 10:45:50 -0700 Subject: RFR(M): 8016602 - revert SPARC V8 patch In-Reply-To: <524AFB3B.7050705@oracle.com> References: <524AFB3B.7050705@oracle.com> Message-ID: <524B0A4E.4090808@oracle.com> Morris, You should be able to find the problem since 8022644 is reproducible. Where is guarantee that this rollback is not introducing an other problems since sources changed since then. At least you can find safe subset of changes which we can keep. Vladimir On 10/1/13 9:41 AM, Morris Meyer wrote: > Folks, > > My earlier change set below is responsible for two regressions. 8016602 (BigApps) and 8022644 java.util.streams > InfiniteStreamWithLimitOpTest test. > > changeset: 4803:46c544b8fbfc > user: morris > date: Fri Jun 07 16:46:37 2013 -0700 > summary: 8008407: remove SPARC V8 support > > > As the V8 removal was really touchy and I had to work back from the whole V8 removal to what I pushed in June, I would > like to remove this change set. This change has been tested with JPRT. > > We can decide later to remove V8 in HotSpot - or work forward with a V9 clean implementation in Graal. > > --morris > > WEBREV - http://cr.openjdk.java.net/~morris/8016602.01 > JBS - https://bugs.openjdk.java.net/browse/JDK-8016602 > JBS - https://bugs.openjdk.java.net/browse/JDK-8022644 From john.r.rose at oracle.com Tue Oct 1 14:29:04 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 14:29:04 -0700 Subject: RFR (S) 8001105: findVirtual of Object[].clone produces internal error In-Reply-To: <4AFDBF02-CFAE-40ED-9BCB-BC53B769AEC2@oracle.com> References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com> <4AFDBF02-CFAE-40ED-9BCB-BC53B769AEC2@oracle.com> Message-ID: <966D87E0-575B-41A3-B3AC-99927EDFBADE@oracle.com> Second call for reviews. I need two official Reviewers for this change. ? John P.S. Thanks for your comments Morris; I enhanced the comment: + // The JVM does this hack also. ++ // (See ClassVerifier::verify_invoke_instructions ++ // and LinkResolver::check_method_accessability.) ++ // Because the JVM does not allow separate methods on array types, + // there is no separate method for int[].clone. + // All arrays simply inherit Object.clone. + // But for access checking logic, we make Object.clone + // (normally protected) appear to be public. + // Later on, when the DirectMethodHandle is created, + // its leading argument will be restricted to the + // requested array type. ++ // N.B. The return type is not adjusted, because ++ // that is *not* the bytecode behavior. Oddly, the JVMS does not mention this hack explicitly. Maybe it's buried in the Prolog code. On Sep 21, 2013, at 2:34 AM, Morris Meyer wrote: > This looks good. Might want to point out where in HotSpot this change originates from in your comment. > > --mm > > >> On Sep 18, 2013, at 10:32 PM, John Rose wrote: >> >> http://cr.openjdk.java.net/~jrose/8001105/webrev.00/ >> >> Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type. >> >> See: http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-October/005035.html >> >> ? John >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Tue Oct 1 15:15:24 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 15:15:24 -0700 Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity Message-ID: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity. It also adjusts some unit tests. The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written. The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests. http://cr.openjdk.java.net/~jrose/8025112/webrev.00 For more background, see my JavaOne presentation: http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf Thanks, ? John From john.r.rose at oracle.com Tue Oct 1 15:19:30 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 15:19:30 -0700 Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8 References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com> Message-ID: http://cr.openjdk.java.net/~jrose/8024438/webrev.00 These are miscellaneous edits to javadoc and unit tests, clarifying various minor corner cases and improving presentation. There is also a single API change (already under review by CCC): Adding a missing wildcard to Constructor. Please review. Thanks, ? John From john.r.rose at oracle.com Tue Oct 1 22:19:56 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 1 Oct 2013 22:19:56 -0700 Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity In-Reply-To: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> Message-ID: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager". The result is more clearly correct and maintainable. Here is the respin: http://cr.openjdk.java.net/~jrose/8025112/webrev.01 ? John On Oct 1, 2013, at 3:15 PM, John Rose wrote: > This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity. > > It also adjusts some unit tests. > > The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written. > > The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests. > > http://cr.openjdk.java.net/~jrose/8025112/webrev.00 > > For more background, see my JavaOne presentation: > http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf > > Thanks, > ? John From albert.noll at oracle.com Wed Oct 2 02:47:46 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 02 Oct 2013 11:47:46 +0200 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <524AF59C.3040908@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> Message-ID: <524BEBC2.4030202@oracle.com> Hi Vladimir, thanks again for the feedback. I tested the patch as you proposed, i.e., make sure that the patch works if the C1 and/or C2 compiler fails to initialize. I tested with up to 256 compiler threads. To make sure that all compiler threads exit, I had to do additional modifications in CompileQueue::get() and the caller of this method. With these changes, one can also exit compiler threads if -XX:-UseCodeCacheFlushing is set, which is also contained in this webrev. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ See more comments inline: On 01.10.2013 18:17, Vladimir Kozlov wrote: > Albert, > > In general it looks good. Please, test it extensively with Tiered with > codecache size enough to initialize one compiler but not an other to > verify your code. > Done. > I think you need to swap lock and decrement otherwise it will deadlock: > > +bool AbstractCompiler::should_perform_shutdown() { > + MutexLocker only_one(CompileThread_lock); > + _num_compiler_threads--; > I simplified this function. In fact it is fine if the last thread (i.e., if _num_compiler_threads == 0) does the shutdown. The while() statement is really not necessary. However, we have to decrement _num_compiler_threads when we hold the lock. Otherwise we are not guaranteed to reach 0 (-- is not atomic). > comp->set_shut_down(); and delete _compilers[0]; should be done by one > thread I think. Done. > > Small note, you accidentally removed nl in c2compiler.cpp: > > - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights > reserved. > +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All > rights reserved. > > Fixed. Thanks again, Albert > Thanks, > Vladimir > > On 10/1/13 12:27 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks again for looking at the patch. See comments inline: >> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >> >> >> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>> Albert, >>> >>> There is small window between check and set_state where state can >>> became initialized or still be uninitialized: >>> + if (!is_initialized()) { >>> + set_state(failed); >>> >>> so you may hit assert in set_state(). >>> >>> I think you need to call set_state(failed) only when C1 runtime is >>> initialized after lock: >>> >>> if (should_perform_init()) { >>> if (buffer_blob == NULL) { >>> set_state(failed); >>> } else { >>> init_c1_runtime(); >>> set_state(initialized); >>> } >>> } >>> >> You are right. I adapted the patch according to your suggestion. >> >>> In this case it will match behavior for C2 which means that you need >>> to shutdown compilation since you was not able to >>> initialize compilation runtime. It will require more code to do >>> proper shutdown not just exiting thread (free >>> compilation queues, resetting flags). An it will be more complicated >>> for Tiered case (I think we can use simple >>> approach to shutdown all compilations even if only one Compiler is >>> not initialized since it is rare case). >>> >> I added code to shut-down compilation. If compiler runtime >> initialization fails, a flag is set which disables >> compilation forever. In the current >> version, all compilers are disabled if C1 and/or C2 runtime >> initialization fails (also in case of tiered compilation). I >> think this solution is fine for >> now, since a compiler runtime initialization failure should not >> happen in practice. If it ever turns out to be a >> problem, i.e., it is required that we >> we use one compiler if the other compiler failed to initialize, I >> suggest we fix this in another bug. The current bug >> appears only due to an artificial >> setting of the code cache size. >> >> Compiler shut-down is performed by one thread. This thread waits >> until all compiler threads have exited to compiler >> loop. The thread then >> deletes all tasks from the compile queue, deletes the compiler >> objects, and sets the objects to NULL. >> >> Please let me know if you think this solution is fine, or if there >> are other things that need to be considered. >> The current version passed jprt. >> >> Many thanks again, >> Albert >> >>> If C1 runtime was initialized but we was not able to allocate buffer >>> for some threads your current code in >>> compileBroker.cpp will handle such case. So you don't need to set >>> state to 'failed'. >>> >>> thanks, >>> Vladimir >>> >>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>> Hi Vladimir, >>>> >>>> thanks for looking at the patch. >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>> >>>> >>>> See comments inline: >>>> >>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>> Thank you, Albert >>>>> >>>>> I would suggest to do TieredStartAtLevel changes separately, it is >>>>> not >>>>> related to this bug. >>>>> >>>> Done. >>>>> Second, how we can guard the initialization with a field >>>>> (_compiler_state and original _is_initialized) which is not static? >>>>> >>>>> You don't need separate local do_init in C*_Compiler.cpp since it is >>>>> used only once: >>>>> >>>> Done. >>>>> + if (should_perform_init()) { >>>>> >>>>> abstractCompiler.cpp: >>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>> should_perform_init() and set_state(). Why? There is assert in >>>>> check_prelock_state() called from Monitor::lock(): >>>>> >>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>> *)thread)->thread_state() == _thread_in_vm) >>>>> || rank() == Mutex::special, "wrong thread state for using >>>>> locks"); >>>>> >>>>> Compiler threads are Java threads, so you should be in VM state when >>>>> lock. How you did not hit this assert? >>>>> >>>> The state transition from native to VM (and ResetNoHandleMark) is >>>> now in >>>> compileBroker.cpp:1543. >>>>> >>>>> Typo in abstractCompiler.hpp 'methos': >>>>> >>>>> + // This method returns true for the first compiler thread that >>>>> reaches that methos. >>>>> >>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>> before but it was not accurate, it could be mistaking for Compile >>>>> object created for each compilation): >>>>> >>>>> + // This thread will initialize the compiler object. >>>>> >>>>> Swap lines (and use 'runtime' in the comment): >>>>> >>>>> ! bool is_initialized () { return _compiler_state == >>>>> initialized; } >>>>> ! // Get/set state of compiler objects >>>>> >>>>> >>>>> c2compiler.cpp: >>>>> >>>>> C2Compiler:: is not needed: >>>>> >>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>> >>>>> >>>> Fixed the issues above. >>>>> Should we exit Compiler thread which failed local buffer allocation >>>>> instead parking? Why keep resources allocated for it? >>>>> >>>> You are right, there is no reason the keep these threads around. >>>> Compiler threads wo are not initialized correctly >>>> now exit the VM. >>>> >>>> The patch is currently in west queue. >>>> >>>> Many thanks again, >>>> Albert >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>> Hi, >>>>>> >>>>>> could I have a review for this patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>> >>>>>> >>>>>> Problem: C1/C2 compiler initialization can fail if there is not >>>>>> enough >>>>>> memory in the code cache to generate all stubs. >>>>>> This problem occurs only with a small code cache size. >>>>>> >>>>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>> was not initialized correctly. >>>>>> >>>>>> Testing: jprt, test case, benchmarks >>>>>> >>>>>> This patch also contains a refactored version of compiler >>>>>> object/thread >>>>>> initialization. In the new version, a compiler object/thread is >>>>>> initialized prior entering the main compiler loop. In the old >>>>>> version, >>>>>> the check if the compiler/thread is initialized was >>>>>> done in the main compiler loop (and hence before every compilation). >>>>>> >>>>>> To continue execution with a limited code cache size, the code types >>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>> be 'critical' allocations in the code cache, i.e., they must use >>>>>> space >>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>> >>>>>> In addition I removed some unued code. >>>>>> >>>>>> Many thanks in advance for reviewing. >>>>>> >>>>>> Best, >>>>>> Albert >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131002/d306c519/attachment-0001.html From albert.noll at oracle.com Wed Oct 2 03:47:13 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 02 Oct 2013 12:47:13 +0200 Subject: RFR (S): 8025656: compiler/8013496/Test8013496.sh fails on assert In-Reply-To: <524B0757.8010101@oracle.com> References: <524ABA6B.3040701@oracle.com> <524B0757.8010101@oracle.com> Message-ID: <524BF9B1.3060602@oracle.com> Hi Valdimir, thanks for your feedback. See comments inline. Here is the new webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.01/ On 01.10.2013 19:33, Vladimir Kozlov wrote: > Albert, > > I think the only problem is call to handle_full_code_cache() in C1 > Compiler::get_buffer_blob(). Please verify that. There are calls > during adapters generation and I don't see which state at that time. Yes, I think that this is the only call that causes the assertion to fail. I checked the state of the thread in AdapterHandlerLibrary::create_native_wrapper() and AdapterHandlerLibrary::get_adapter and in both functions the thread is in state '_thread_in_vm'. > If the problem only in get_buffer_blob() it will be solved when you > remove the call in 8023014. Yes, it will be removed. > On other hand it will not hurt to have transition here. I agree that's why I would keep it. It could help to fix JDK-8022968 more easily. > You need to fix comment: > > "This ensures that handle_full_code_cache()" should be "This ensures > that possibly_sweep()" > Fixing the test is fine. > Done. Thanks again, Albert Thanks, > Vladimir > > On 10/1/13 5:04 AM, Albert Noll wrote: >> Hi, >> >> could I have a review for this small patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8025656 >> webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.00/ >> >> >> Problem: handle_full_code_cache is called when the calling thread is >> in a wrong state. >> >> Solution: Switch to the right thread state before calling sweeper. >> >> I also re-wrote the corresponding test. In the new version, the >> arguments take a larger InitialCodeCacheSize >> and ReservedCodeCacheSize. Too small code cache sizes can fail the >> compiler runtime initialization and hence >> the test. Checking proper compiler runtime initialization is checked >> by 8023014. >> >> Many thanks in advance, >> Albert >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131002/4aff17ba/attachment.html From tobi.hartmann at gmail.com Wed Oct 2 07:06:44 2013 From: tobi.hartmann at gmail.com (Tobias Hartmann) Date: Wed, 2 Oct 2013 16:06:44 +0200 Subject: RFR (L): 8015774: Add support for multiple code heaps Message-ID: Hi, please review the following change. bug: https://bugs.openjdk.java.net/browse/JDK-8015774 webrev: http://cr.openjdk.java.net/~anoll/8015774/webrev.00/ This change implements support for multiple code heaps in the code cache. The interface of the code cache was changed accordingly and references from other components of the VM were adapted. This includes the indirect references from: - the Serviceability Agent: vmStructs and the Java code cache interface (sun.jvm.hotspot.code.CodeCache) - the dtrace ustack helper script (jhelper.d) - the pstack support library libjvm_db.c Currently the code cache contains the following three code heaps each of which contains CodeBlobs of a specific type: - Non-Profiled methods: nmethods that are not profiled, i.e., those compiled at tier 1 or 4 and native methods - Profiled methods: nmethods that are profiled, i.e., those compiled at tier 2 or 3 - Non-methods: Non-methods like Buffers, Adapters and Runtime Stubs By default, 2/3 of the ReservedCodeCacheSize is used for the non-profiled heap and 1/3 is used for the profiled heap. Experiments with a small code cache size have shown that this configuration performs best (see [1]). Sizes can be configured using the NonProfiledCodeHeapSize and ProfiledCodeHeapSize parameters. By now the non-method heap has a fixed size of 8mb. More tests have to be performed to determine reasonable default values for different build and runtime configurations. It would be also possible to add an additional heap for the CodeBlobs needed during VM startup (adapters, stubs, interpreter, ...) and use the non-method heap for non-method blobs allocated during runtime. The main benefit of this allocation is that functions operating on nmethods can now be optimized to only iterate over CodeBlobs on the nmethod heaps, avoiding a full scan of the code cache including the non-methods. Performance evaluation shows that this results in a great reduction of the sweeping time. Further it is now possible to extend the sweeper to selectively sweep nmethods of different compilation levels. Because it is more expensive to recompile a highly optimized method, it makes sense to first sweep those compiled at a lower level. Possible future optimizations may also include multithreaded sweeping and separation of nmethod code and metadata. The code was tested using Nashorn + Octane, DaCapo, SPECJvm2008 and jprt. Benchmark results: - [2] shows the score of the old and new version running Nashorn with the Octane benchmark at different code cache sizes (10 runs each, sizes < 32mb crash with the old version). An performance improvement of around 15% is reached. - [3] shows the sweep time of the NMethodSweeper during runs of the Octane benchmark with different code cache sizes (10 runs each). The time is greatly reduced with the new version. - [4] shows the time ratio (TOld / TNew - 1) of the DaCapo benchmarks with a code cache size of 64mb (30 runs with 20 warmups each). With the time differences being smaller than the confidence intervals it is not possible determine a difference between the two versions. - Multiple runs of the SPECJvm2008 benchmark with different code cache sizes did not show a difference between the two versions. This is probably due to the fact that not much code is compiled at runtime compared to Nashorn with the Octane benchmark. The error bars at each data point show the 95% confidence interval. [1] https://bugs.openjdk.java.net/secure/attachment/16372/OctaneRatio.png [2] https://bugs.openjdk.java.net/secure/attachment/16374/OctaneCCSizes_new.png [3] https://bugs.openjdk.java.net/secure/attachment/16373/OctaneSweepTime_new.png [4] https://bugs.openjdk.java.net/secure/attachment/16371/DaCapoCCSizes_64.png Thanks and best regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131002/11aeefbc/attachment.html From vladimir.kozlov at oracle.com Wed Oct 2 09:49:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Oct 2013 09:49:44 -0700 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <524BEBC2.4030202@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> <524BEBC2.4030202@oracle.com> Message-ID: <524C4EA8.1020109@oracle.com> Albert, In disable_compilation_forever() the comment does not correspond to code. In should_perform_shutdown() the _compiler_state could be changed before other threads reach "if (comp->is_state_failed())" check in init_compiler_runtime(). Yes, decrementing with lock is fine, you are right. The message should say why we do shutdown (no space to initialize compiler runtime): warning("Shutting down compiler Please, explain what references: + // We could delete compiler runtimes also. However, + // there are references to the compiler runtime(s) + // (e.g., by nmethods) which then fail. This can be It would be nice to have regression test for this. Thanks, Vladimir On 10/2/13 2:47 AM, Albert Noll wrote: > Hi Vladimir, > > thanks again for the feedback. I tested the patch as you proposed, i.e., make sure that > the patch works if the C1 and/or C2 compiler fails to initialize. I tested with up to 256 compiler > threads. > > To make sure that all compiler threads exit, I had to do additional modifications in CompileQueue::get() > and the caller of this method. With these changes, one can also exit compiler threads if -XX:-UseCodeCacheFlushing > is set, which is also contained in this webrev. > > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ > > See more comments inline: > > > On 01.10.2013 18:17, Vladimir Kozlov wrote: >> Albert, >> >> In general it looks good. Please, test it extensively with Tiered with codecache size enough to initialize one >> compiler but not an other to verify your code. >> > Done. >> I think you need to swap lock and decrement otherwise it will deadlock: >> >> +bool AbstractCompiler::should_perform_shutdown() { >> + MutexLocker only_one(CompileThread_lock); >> + _num_compiler_threads--; >> > I simplified this function. In fact it is fine if the last thread (i.e., if _num_compiler_threads == 0) > does the shutdown. The while() statement is really not necessary. However, we have to decrement > _num_compiler_threads when we hold the lock. Otherwise we are not guaranteed to reach 0 > (-- is not atomic). > >> comp->set_shut_down(); and delete _compilers[0]; should be done by one thread I think. > Done. > >> >> Small note, you accidentally removed nl in c2compiler.cpp: >> >> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. >> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. >> >> > Fixed. > > Thanks again, > Albert > >> Thanks, >> Vladimir >> >> On 10/1/13 12:27 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks again for looking at the patch. See comments inline: >>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>> >>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> There is small window between check and set_state where state can became initialized or still be uninitialized: >>>> + if (!is_initialized()) { >>>> + set_state(failed); >>>> >>>> so you may hit assert in set_state(). >>>> >>>> I think you need to call set_state(failed) only when C1 runtime is initialized after lock: >>>> >>>> if (should_perform_init()) { >>>> if (buffer_blob == NULL) { >>>> set_state(failed); >>>> } else { >>>> init_c1_runtime(); >>>> set_state(initialized); >>>> } >>>> } >>>> >>> You are right. I adapted the patch according to your suggestion. >>> >>>> In this case it will match behavior for C2 which means that you need to shutdown compilation since you was not able to >>>> initialize compilation runtime. It will require more code to do proper shutdown not just exiting thread (free >>>> compilation queues, resetting flags). An it will be more complicated for Tiered case (I think we can use simple >>>> approach to shutdown all compilations even if only one Compiler is not initialized since it is rare case). >>>> >>> I added code to shut-down compilation. If compiler runtime initialization fails, a flag is set which disables >>> compilation forever. In the current >>> version, all compilers are disabled if C1 and/or C2 runtime initialization fails (also in case of tiered compilation). I >>> think this solution is fine for >>> now, since a compiler runtime initialization failure should not happen in practice. If it ever turns out to be a >>> problem, i.e., it is required that we >>> we use one compiler if the other compiler failed to initialize, I suggest we fix this in another bug. The current bug >>> appears only due to an artificial >>> setting of the code cache size. >>> >>> Compiler shut-down is performed by one thread. This thread waits until all compiler threads have exited to compiler >>> loop. The thread then >>> deletes all tasks from the compile queue, deletes the compiler objects, and sets the objects to NULL. >>> >>> Please let me know if you think this solution is fine, or if there are other things that need to be considered. >>> The current version passed jprt. >>> >>> Many thanks again, >>> Albert >>> >>>> If C1 runtime was initialized but we was not able to allocate buffer for some threads your current code in >>>> compileBroker.cpp will handle such case. So you don't need to set state to 'failed'. >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks for looking at the patch. >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>> >>>>> >>>>> See comments inline: >>>>> >>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>> Thank you, Albert >>>>>> >>>>>> I would suggest to do TieredStartAtLevel changes separately, it is not >>>>>> related to this bug. >>>>>> >>>>> Done. >>>>>> Second, how we can guard the initialization with a field >>>>>> (_compiler_state and original _is_initialized) which is not static? >>>>>> >>>>>> You don't need separate local do_init in C*_Compiler.cpp since it is >>>>>> used only once: >>>>>> >>>>> Done. >>>>>> + if (should_perform_init()) { >>>>>> >>>>>> abstractCompiler.cpp: >>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>> check_prelock_state() called from Monitor::lock(): >>>>>> >>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>> || rank() == Mutex::special, "wrong thread state for using >>>>>> locks"); >>>>>> >>>>>> Compiler threads are Java threads, so you should be in VM state when >>>>>> lock. How you did not hit this assert? >>>>>> >>>>> The state transition from native to VM (and ResetNoHandleMark) is now in >>>>> compileBroker.cpp:1543. >>>>>> >>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>> >>>>>> + // This method returns true for the first compiler thread that >>>>>> reaches that methos. >>>>>> >>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>> object created for each compilation): >>>>>> >>>>>> + // This thread will initialize the compiler object. >>>>>> >>>>>> Swap lines (and use 'runtime' in the comment): >>>>>> >>>>>> ! bool is_initialized () { return _compiler_state == >>>>>> initialized; } >>>>>> ! // Get/set state of compiler objects >>>>>> >>>>>> >>>>>> c2compiler.cpp: >>>>>> >>>>>> C2Compiler:: is not needed: >>>>>> >>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>> >>>>>> >>>>> Fixed the issues above. >>>>>> Should we exit Compiler thread which failed local buffer allocation >>>>>> instead parking? Why keep resources allocated for it? >>>>>> >>>>> You are right, there is no reason the keep these threads around. >>>>> Compiler threads wo are not initialized correctly >>>>> now exit the VM. >>>>> >>>>> The patch is currently in west queue. >>>>> >>>>> Many thanks again, >>>>> Albert >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could I have a review for this patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Problem: C1/C2 compiler initialization can fail if there is not enough >>>>>>> memory in the code cache to generate all stubs. >>>>>>> This problem occurs only with a small code cache size. >>>>>>> >>>>>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>> was not initialized correctly. >>>>>>> >>>>>>> Testing: jprt, test case, benchmarks >>>>>>> >>>>>>> This patch also contains a refactored version of compiler object/thread >>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>> initialized prior entering the main compiler loop. In the old version, >>>>>>> the check if the compiler/thread is initialized was >>>>>>> done in the main compiler loop (and hence before every compilation). >>>>>>> >>>>>>> To continue execution with a limited code cache size, the code types >>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>> be 'critical' allocations in the code cache, i.e., they must use space >>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>> >>>>>>> In addition I removed some unued code. >>>>>>> >>>>>>> Many thanks in advance for reviewing. >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>> >>> > From roland.westrelin at oracle.com Wed Oct 2 10:02:35 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 2 Oct 2013 19:02:35 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> Message-ID: <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. http://cr.openjdk.java.net/~roland/8023657/webrev.01/ The output of -XX:+PrintMethodData is: 6 invokevirtual 2 0 bci: 6 VirtualCallData count(0) entries(1) 'TestProfiling'(4746 1.00) argument types 0: stack(1) 'TestProfiling$C' 1: stack(2) unknown (null seen) Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. Roland. From vladimir.kozlov at oracle.com Wed Oct 2 10:21:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 02 Oct 2013 10:21:23 -0700 Subject: RFR (S): 8025656: compiler/8013496/Test8013496.sh fails on assert In-Reply-To: <524BF9B1.3060602@oracle.com> References: <524ABA6B.3040701@oracle.com> <524B0757.8010101@oracle.com> <524BF9B1.3060602@oracle.com> Message-ID: <524C5613.3050902@oracle.com> Good. Can you aligh the comment a bit nicely before the push :) (no need to review). Thanks, Vladimir On 10/2/13 3:47 AM, Albert Noll wrote: > Hi Valdimir, > > thanks for your feedback. See comments inline. > Here is the new webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.01/ > > > On 01.10.2013 19:33, Vladimir Kozlov wrote: >> Albert, >> >> I think the only problem is call to handle_full_code_cache() in C1 Compiler::get_buffer_blob(). Please verify that. >> There are calls during adapters generation and I don't see which state at that time. > Yes, I think that this is the only call that causes the assertion to fail. I checked the state of the thread in > AdapterHandlerLibrary::create_native_wrapper() and AdapterHandlerLibrary::get_adapter and in both > functions the thread is in state '_thread_in_vm'. > >> If the problem only in get_buffer_blob() it will be solved when you remove the call in 8023014. > Yes, it will be removed. >> On other hand it will not hurt to have transition here. > I agree that's why I would keep it. It could help to fix JDK-8022968 more easily. >> You need to fix comment: >> >> "This ensures that handle_full_code_cache()" should be "This ensures that possibly_sweep()" >> Fixing the test is fine. >> > Done. > > Thanks again, > Albert > > Thanks, >> Vladimir >> >> On 10/1/13 5:04 AM, Albert Noll wrote: >>> Hi, >>> >>> could I have a review for this small patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025656 >>> webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.00/ >>> >>> Problem: handle_full_code_cache is called when the calling thread is in a wrong state. >>> >>> Solution: Switch to the right thread state before calling sweeper. >>> >>> I also re-wrote the corresponding test. In the new version, the arguments take a larger InitialCodeCacheSize >>> and ReservedCodeCacheSize. Too small code cache sizes can fail the compiler runtime initialization and hence >>> the test. Checking proper compiler runtime initialization is checked by 8023014. >>> >>> Many thanks in advance, >>> Albert >>> >>> > From forax at univ-mlv.fr Wed Oct 2 10:41:37 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 02 Oct 2013 19:41:37 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> Message-ID: <524C5AD1.2020907@univ-mlv.fr> On 10/02/2013 07:02 PM, Roland Westrelin wrote: > Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. > > http://cr.openjdk.java.net/~roland/8023657/webrev.01/ > > The output of -XX:+PrintMethodData is: > > 6 invokevirtual 2 > 0 bci: 6 VirtualCallData count(0) entries(1) > 'TestProfiling'(4746 1.00) > argument types 0: stack(1) 'TestProfiling$C' > 1: stack(2) unknown (null seen) > > Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. > Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. > Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. There is another case where this kind of profiling will be really helpful, for methods that takes a lambda as parameter like by example HashMap.computeIfAbsent, currently if this method is used more than 2 times with different lambdas, the profile of the receiver of the call of the lambda (an invokeinterface) is polluted. Detecting this kind of methods requires some work, the VM has to look for a method parameter which is a functional interface, which mean that the VM has to have a way to detect if an interface is a functional interface, but I think it worth the trouble. > Roland. > > R?mi From vladimir.x.ivanov at oracle.com Wed Oct 2 11:27:56 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Wed, 02 Oct 2013 18:27:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8025233: Move sun.invoke.Stable into java.lang.invoke package Message-ID: <20131002182801.CF63F62CB1@hg.openjdk.java.net> Changeset: cacc4c6bfc80 Author: vlivanov Date: 2013-10-02 06:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cacc4c6bfc80 8025233: Move sun.invoke.Stable into java.lang.invoke package Reviewed-by: twisti, iveresov ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp From christian.thalinger at oracle.com Wed Oct 2 11:39:16 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 11:39:16 -0700 Subject: RFR (S) 8001105: findVirtual of Object[].clone produces internal error In-Reply-To: <966D87E0-575B-41A3-B3AC-99927EDFBADE@oracle.com> References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com> <4AFDBF02-CFAE-40ED-9BCB-BC53B769AEC2@oracle.com> <966D87E0-575B-41A3-B3AC-99927EDFBADE@oracle.com> Message-ID: Looks good. On Oct 1, 2013, at 2:29 PM, John Rose wrote: > Second call for reviews. I need two official Reviewers for this change. ? John > > P.S. Thanks for your comments Morris; I enhanced the comment: > > + // The JVM does this hack also. > ++ // (See ClassVerifier::verify_invoke_instructions > ++ // and LinkResolver::check_method_accessability.) > ++ // Because the JVM does not allow separate methods on array types, > + // there is no separate method for int[].clone. > + // All arrays simply inherit Object.clone. > + // But for access checking logic, we make Object.clone > + // (normally protected) appear to be public. > + // Later on, when the DirectMethodHandle is created, > + // its leading argument will be restricted to the > + // requested array type. > ++ // N.B. The return type is not adjusted, because > ++ // that is *not* the bytecode behavior. > > Oddly, the JVMS does not mention this hack explicitly. Maybe it's buried in the Prolog code. > > On Sep 21, 2013, at 2:34 AM, Morris Meyer wrote: > >> This looks good. Might want to point out where in HotSpot this change originates from in your comment. >> >> --mm >> >> >>> On Sep 18, 2013, at 10:32 PM, John Rose wrote: >>> >>> http://cr.openjdk.java.net/~jrose/8001105/webrev.00/ >>> >>> Summary: Replicate JVM logic for access control that makes Object.clone appear public when applied to an array type. >>> >>> See: http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-October/005035.html >>> >>> ? John >>> >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.x.ivanov at oracle.com Wed Oct 2 11:55:14 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 02 Oct 2013 22:55:14 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Message-ID: <524C6C12.9050200@oracle.com> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ 7 lines changed: 4 ins; 0 del; 3 mod If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ overflows and j <= r->hi() succeeds again (leading to extra iterations and infinite loop in the product). The fix is to check whether upper limit is reached (j >= r->hi()) and stop iterating, if necessary. Also, did a small cleanup: eliminated unused parameter from SwitchRange::print. Testing: failing test case. Reviewed-by: iveresov, ? Best regards, Vladimir Ivanov From christian.thalinger at oracle.com Wed Oct 2 12:14:33 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 12:14:33 -0700 Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8 In-Reply-To: References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com> Message-ID: <35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com> src/share/classes/java/lang/invoke/MethodHandles.java: + * lookup expression Apparently the name attribute is obsolete for in HTML5: http://dev.w3.org/html5/markup/a.html I think they want you to use . + *

+ * + * Discussion of private access: Same here. + *

Security manager interactions

And here. + * because the desired class member is missing, because the Did you want an "or" before "because" like the others? Otherwise this looks good. On Oct 1, 2013, at 3:19 PM, John Rose wrote: > http://cr.openjdk.java.net/~jrose/8024438/webrev.00 > > These are miscellaneous edits to javadoc and unit tests, clarifying various minor corner cases and improving presentation. > > There is also a single API change (already under review by CCC): Adding a missing wildcard to Constructor. > > Please review. > > Thanks, > ? John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From christian.thalinger at oracle.com Wed Oct 2 12:17:57 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 12:17:57 -0700 Subject: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity In-Reply-To: <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> References: <3AEAB674-3E51-4688-9052-F79EF02A9B68@oracle.com> <0CDAF6E9-24B7-41BA-BDD1-E71A95FD91F5@oracle.com> Message-ID: <5CD24332-806B-47A5-B3B6-150E98993BFD@oracle.com> Thank you for doing this; it is much clearer now. Looks good. On Oct 1, 2013, at 10:19 PM, John Rose wrote: > Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager". The result is more clearly correct and maintainable. > > Here is the respin: > http://cr.openjdk.java.net/~jrose/8025112/webrev.01 > > ? John > > On Oct 1, 2013, at 3:15 PM, John Rose wrote: > >> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity. >> >> It also adjusts some unit tests. >> >> The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written. >> >> The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests. >> >> http://cr.openjdk.java.net/~jrose/8025112/webrev.00 >> >> For more background, see my JavaOne presentation: >> http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf >> >> Thanks, >> ? John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From vladimir.x.ivanov at oracle.com Wed Oct 2 13:15:11 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 00:15:11 +0400 Subject: RFR (S): 8024943: ciReplay: fails to dump replay data during safepointing Message-ID: <524C7ECF.80004@oracle.com> http://cr.openjdk.java.net/~vlivanov/8024943/webrev.00/ 15 lines changed: 11 ins; 0 del; 4 mod In some situations VM fails to dump compiler replay file (produces empty replay_pid%p.log). The reason is that ciEnv::dump_replay_data tries to do thread state transition to VM unconditionally and acquire Compile_lock. It doesn't always work in context of VM error reporter. The fix is to provide new method specifically for VM error reporter (ciEnv::dump_replay_data_unsafe) which doesn't perform aforementioned actions. Testing: manual (checked that a valid dump is produced for a crash during safepointing). Thanks! Best regards, Vladimir Ivanov From john.r.rose at oracle.com Wed Oct 2 13:57:03 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 2 Oct 2013 13:57:03 -0700 Subject: RFR (S): 8024943: ciReplay: fails to dump replay data during safepointing In-Reply-To: <524C7ECF.80004@oracle.com> References: <524C7ECF.80004@oracle.com> Message-ID: On Oct 2, 2013, at 1:15 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8024943/webrev.00/ > 15 lines changed: 11 ins; 0 del; 4 mod > > In some situations VM fails to dump compiler replay file (produces empty replay_pid%p.log). The reason is that ciEnv::dump_replay_data tries to do thread state transition to VM unconditionally and acquire Compile_lock. It doesn't always work in context of VM error reporter. > > The fix is to provide new method specifically for VM error reporter (ciEnv::dump_replay_data_unsafe) which doesn't perform aforementioned actions. > > Testing: manual (checked that a valid dump is produced for a crash during safepointing). Is is possible that you've pushed a bug further into the CI code? I would like you to take a look at this (if you haven't already) and either make code adjustments or describe current assumptions in comments, for the next maintainer. What I mean about "pushed a bug" is that the CI is (generally speaking) sensitive to the thread state. (Note the GUARDED_VM_ENTRY macros everywhere.) The dump_replay_data function calls a bunch of dump_replay_data subroutines on lots of little data structures in the CI. Are any of them also sensitive to thread state? If so, perhaps you want to have your Also, the ciEnv::current() call returns something to the error reporter, and if that something is non-null, it is assumed to be (up to high probability, of course) a valid ciEnv structure. Are there any places where the ciEnv guy is in an inconsistent state but still published by ciEnv::current()? Probably not, but it might be worth a comment noting the appropriate conditions. My specific worry is that the call to remove_symbols in ~ciEnv might leave a space where the dumper would not see valid state. This crash dumper stuff cannot be nailed down 100%, of course, but this might be a good moment to make sure we've at least stomped on it a bit. Reviewed, pending resolution of the above. Thanks, ? John From john.r.rose at oracle.com Wed Oct 2 14:31:06 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 2 Oct 2013 14:31:06 -0700 Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8 In-Reply-To: <35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com> References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com> <35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com> Message-ID: <3C5298FB-3149-4FED-920F-4254D07C3956@oracle.com> On Oct 2, 2013, at 12:14 PM, Christian Thalinger wrote: > src/share/classes/java/lang/invoke/MethodHandles.java: > > + * lookup expression > > Apparently the name attribute is obsolete for in HTML5: > > http://dev.w3.org/html5/markup/a.html > > I think they want you to use . > > + *

> + * > + * Discussion of private access: > > Same here. > > + *

Security manager interactions

> > And here. Wow; I don't know where HTML5 fits in the javadoc story. That might be nice to upgrade, but I'm not gonna go first: -------- fgrep ' On Oct 2, 2013, at 1:15 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8024943/webrev.00/ >> 15 lines changed: 11 ins; 0 del; 4 mod >> >> In some situations VM fails to dump compiler replay file (produces empty replay_pid%p.log). The reason is that ciEnv::dump_replay_data tries to do thread state transition to VM unconditionally and acquire Compile_lock. It doesn't always work in context of VM error reporter. >> >> The fix is to provide new method specifically for VM error reporter (ciEnv::dump_replay_data_unsafe) which doesn't perform aforementioned actions. >> >> Testing: manual (checked that a valid dump is produced for a crash during safepointing). > > Is is possible that you've pushed a bug further into the CI code? I would like you to take a look at this (if you haven't already) and either make code adjustments or describe current assumptions in comments, for the next maintainer. > > What I mean about "pushed a bug" is that the CI is (generally speaking) sensitive to the thread state. (Note the GUARDED_VM_ENTRY macros everywhere.) The dump_replay_data function calls a bunch of dump_replay_data subroutines on lots of little data structures in the CI. Are any of them also sensitive to thread state? If so, perhaps you want to have your > > Also, the ciEnv::current() call returns something to the error reporter, and if that something is non-null, it is assumed to be (up to high probability, of course) a valid ciEnv structure. Are there any places where the ciEnv guy is in an inconsistent state but still published by ciEnv::current()? Probably not, but it might be worth a comment noting the appropriate conditions. My specific worry is that the call to remove_symbols in ~ciEnv might leave a space where the dumper would not see valid state. > > This crash dumper stuff cannot be nailed down 100%, of course, but this might be a good moment to make sure we've at least stomped on it a bit. > > Reviewed, pending resolution of the above. > > Thanks, > ? John > From christian.thalinger at oracle.com Wed Oct 2 16:04:01 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 16:04:01 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Message-ID: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8011138 http://cr.openjdk.java.net/~twisti/8011138 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: The fix is to walk the JVM states when inlining compiled lambda forms and try to figure out if the "receiver" of the same inlinee (static method in the compiled lambda form) is the same as the current one. If that's the case we have a recursion. I was tempted to remove the InlineTree::_caller_jvms completely but that might be too intrusive for now. Tested with the failing test case and Octane on Nashorn to verify that I didn't break anything. From christian.thalinger at oracle.com Wed Oct 2 20:17:16 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 2 Oct 2013 20:17:16 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Message-ID: https://bugs.openjdk.java.net/browse/JDK-8025566 http://cr.openjdk.java.net/~twisti/8025566 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. From john.r.rose at oracle.com Wed Oct 2 23:38:03 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 2 Oct 2013 23:38:03 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: References: Message-ID: <985B4B9F-9E00-4930-9062-9979C005CDF6@oracle.com> Reviewed. On Oct 2, 2013, at 8:17 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8025566 > http://cr.openjdk.java.net/~twisti/8025566 > > 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method > Reviewed-by: > > The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. > > I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. > From roland.westrelin at oracle.com Thu Oct 3 01:07:36 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 3 Oct 2013 10:07:36 +0200 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524C6C12.9050200@oracle.com> References: <524C6C12.9050200@oracle.com> Message-ID: <870DA6EA-495F-4C56-BC0D-4807FEF275F7@oracle.com> > http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Thu Oct 3 01:40:58 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 3 Oct 2013 10:40:58 +0200 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> Message-ID: <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> > I was tempted to remove the InlineTree::_caller_jvms completely but that might be too intrusive for now. Why do you need to pass a jvms rather than use caller_jvms()? Does a lambda form always have a receiver? You should probably use: caller_argument0->uncast() == callee_argument0->uncast() Roland. From vladimir.x.ivanov at oracle.com Thu Oct 3 02:52:38 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 13:52:38 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <870DA6EA-495F-4C56-BC0D-4807FEF275F7@oracle.com> References: <524C6C12.9050200@oracle.com> <870DA6EA-495F-4C56-BC0D-4807FEF275F7@oracle.com> Message-ID: <524D3E66.4070108@oracle.com> Thank you, Roland. Best regards, Vladimir Ivanov On 10/3/13 12:07 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ > > That looks good to me. > > Roland. > From albert.noll at oracle.com Thu Oct 3 05:59:30 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 03 Oct 2013 14:59:30 +0200 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <524C4EA8.1020109@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> <524BEBC2.4030202@oracle.com> <524C4EA8.1020109@oracle.com> Message-ID: <524D6A32.5080003@oracle.com> Hi Vladimir, thanks for looking at the patch. See comments inline. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.04/ On 02.10.2013 18:49, Vladimir Kozlov wrote: > Albert, > > In disable_compilation_forever() the comment does not correspond to code. > I removed the comment. > In should_perform_shutdown() the _compiler_state could be changed > before other threads reach "if (comp->is_state_failed())" check in > init_compiler_runtime(). True. I added a function should_exit(), which returns true if the state if failed, or shutting down. > Yes, decrementing with lock is fine, you are right. > > The message should say why we do shutdown (no space to initialize > compiler runtime): > warning("Shutting down compiler > The warning messages are now: - "Shutting down compiler %s (no space to run compiler)" or - "Initialization of %s thread failed (no space to run compiler thread)" if a C1 compiler thread fails to allocate memory. > Please, explain what references: > > + // We could delete compiler runtimes also. However, > + // there are references to the compiler runtime(s) > + // (e.g., by nmethods) which then fail. This can be > Done. > It would be nice to have regression test for this. I added a regression test, which checks that compiler threads exit, if there is not sufficient free code cache to init all threads. Testing a failing initialization of C2 is tricky, since a C2 initialization failure depends on the scheduling of the compiler threads. Thanks again, Albert > > Thanks, > Vladimir > > On 10/2/13 2:47 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks again for the feedback. I tested the patch as you proposed, >> i.e., make sure that >> the patch works if the C1 and/or C2 compiler fails to initialize. I >> tested with up to 256 compiler >> threads. >> >> To make sure that all compiler threads exit, I had to do additional >> modifications in CompileQueue::get() >> and the caller of this method. With these changes, one can also exit >> compiler threads if -XX:-UseCodeCacheFlushing >> is set, which is also contained in this webrev. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ >> >> >> See more comments inline: >> >> >> On 01.10.2013 18:17, Vladimir Kozlov wrote: >>> Albert, >>> >>> In general it looks good. Please, test it extensively with Tiered >>> with codecache size enough to initialize one >>> compiler but not an other to verify your code. >>> >> Done. >>> I think you need to swap lock and decrement otherwise it will deadlock: >>> >>> +bool AbstractCompiler::should_perform_shutdown() { >>> + MutexLocker only_one(CompileThread_lock); >>> + _num_compiler_threads--; >>> >> I simplified this function. In fact it is fine if the last thread >> (i.e., if _num_compiler_threads == 0) >> does the shutdown. The while() statement is really not necessary. >> However, we have to decrement >> _num_compiler_threads when we hold the lock. Otherwise we are not >> guaranteed to reach 0 >> (-- is not atomic). >> >>> comp->set_shut_down(); and delete _compilers[0]; should be done by >>> one thread I think. >> Done. >> >>> >>> Small note, you accidentally removed nl in c2compiler.cpp: >>> >>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>> rights reserved. >>> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>> rights reserved. >>> >>> >> Fixed. >> >> Thanks again, >> Albert >> >>> Thanks, >>> Vladimir >>> >>> On 10/1/13 12:27 AM, Albert Noll wrote: >>>> Hi Vladimir, >>>> >>>> thanks again for looking at the patch. See comments inline: >>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>>> >>>> >>>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> There is small window between check and set_state where state can >>>>> became initialized or still be uninitialized: >>>>> + if (!is_initialized()) { >>>>> + set_state(failed); >>>>> >>>>> so you may hit assert in set_state(). >>>>> >>>>> I think you need to call set_state(failed) only when C1 runtime is >>>>> initialized after lock: >>>>> >>>>> if (should_perform_init()) { >>>>> if (buffer_blob == NULL) { >>>>> set_state(failed); >>>>> } else { >>>>> init_c1_runtime(); >>>>> set_state(initialized); >>>>> } >>>>> } >>>>> >>>> You are right. I adapted the patch according to your suggestion. >>>> >>>>> In this case it will match behavior for C2 which means that you >>>>> need to shutdown compilation since you was not able to >>>>> initialize compilation runtime. It will require more code to do >>>>> proper shutdown not just exiting thread (free >>>>> compilation queues, resetting flags). An it will be more >>>>> complicated for Tiered case (I think we can use simple >>>>> approach to shutdown all compilations even if only one Compiler is >>>>> not initialized since it is rare case). >>>>> >>>> I added code to shut-down compilation. If compiler runtime >>>> initialization fails, a flag is set which disables >>>> compilation forever. In the current >>>> version, all compilers are disabled if C1 and/or C2 runtime >>>> initialization fails (also in case of tiered compilation). I >>>> think this solution is fine for >>>> now, since a compiler runtime initialization failure should not >>>> happen in practice. If it ever turns out to be a >>>> problem, i.e., it is required that we >>>> we use one compiler if the other compiler failed to initialize, I >>>> suggest we fix this in another bug. The current bug >>>> appears only due to an artificial >>>> setting of the code cache size. >>>> >>>> Compiler shut-down is performed by one thread. This thread waits >>>> until all compiler threads have exited to compiler >>>> loop. The thread then >>>> deletes all tasks from the compile queue, deletes the compiler >>>> objects, and sets the objects to NULL. >>>> >>>> Please let me know if you think this solution is fine, or if there >>>> are other things that need to be considered. >>>> The current version passed jprt. >>>> >>>> Many thanks again, >>>> Albert >>>> >>>>> If C1 runtime was initialized but we was not able to allocate >>>>> buffer for some threads your current code in >>>>> compileBroker.cpp will handle such case. So you don't need to set >>>>> state to 'failed'. >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thanks for looking at the patch. >>>>>> Here is the new webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>>> >>>>>> >>>>>> See comments inline: >>>>>> >>>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>>> Thank you, Albert >>>>>>> >>>>>>> I would suggest to do TieredStartAtLevel changes separately, it >>>>>>> is not >>>>>>> related to this bug. >>>>>>> >>>>>> Done. >>>>>>> Second, how we can guard the initialization with a field >>>>>>> (_compiler_state and original _is_initialized) which is not static? >>>>>>> >>>>>>> You don't need separate local do_init in C*_Compiler.cpp since >>>>>>> it is >>>>>>> used only once: >>>>>>> >>>>>> Done. >>>>>>> + if (should_perform_init()) { >>>>>>> >>>>>>> abstractCompiler.cpp: >>>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>>> check_prelock_state() called from Monitor::lock(): >>>>>>> >>>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>>> || rank() == Mutex::special, "wrong thread state for using >>>>>>> locks"); >>>>>>> >>>>>>> Compiler threads are Java threads, so you should be in VM state >>>>>>> when >>>>>>> lock. How you did not hit this assert? >>>>>>> >>>>>> The state transition from native to VM (and ResetNoHandleMark) is >>>>>> now in >>>>>> compileBroker.cpp:1543. >>>>>>> >>>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>>> >>>>>>> + // This method returns true for the first compiler thread that >>>>>>> reaches that methos. >>>>>>> >>>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>>> object created for each compilation): >>>>>>> >>>>>>> + // This thread will initialize the compiler object. >>>>>>> >>>>>>> Swap lines (and use 'runtime' in the comment): >>>>>>> >>>>>>> ! bool is_initialized () { return _compiler_state == >>>>>>> initialized; } >>>>>>> ! // Get/set state of compiler objects >>>>>>> >>>>>>> >>>>>>> c2compiler.cpp: >>>>>>> >>>>>>> C2Compiler:: is not needed: >>>>>>> >>>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>>> >>>>>>> >>>>>> Fixed the issues above. >>>>>>> Should we exit Compiler thread which failed local buffer allocation >>>>>>> instead parking? Why keep resources allocated for it? >>>>>>> >>>>>> You are right, there is no reason the keep these threads around. >>>>>> Compiler threads wo are not initialized correctly >>>>>> now exit the VM. >>>>>> >>>>>> The patch is currently in west queue. >>>>>> >>>>>> Many thanks again, >>>>>> Albert >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> could I have a review for this patch? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Problem: C1/C2 compiler initialization can fail if there is not >>>>>>>> enough >>>>>>>> memory in the code cache to generate all stubs. >>>>>>>> This problem occurs only with a small code cache size. >>>>>>>> >>>>>>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>>> was not initialized correctly. >>>>>>>> >>>>>>>> Testing: jprt, test case, benchmarks >>>>>>>> >>>>>>>> This patch also contains a refactored version of compiler >>>>>>>> object/thread >>>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>>> initialized prior entering the main compiler loop. In the old >>>>>>>> version, >>>>>>>> the check if the compiler/thread is initialized was >>>>>>>> done in the main compiler loop (and hence before every >>>>>>>> compilation). >>>>>>>> >>>>>>>> To continue execution with a limited code cache size, the code >>>>>>>> types >>>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>>> be 'critical' allocations in the code cache, i.e., they must >>>>>>>> use space >>>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>>> >>>>>>>> In addition I removed some unued code. >>>>>>>> >>>>>>>> Many thanks in advance for reviewing. >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/3b0b38d4/attachment-0001.html From vladimir.x.ivanov at oracle.com Thu Oct 3 07:30:30 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 18:30:30 +0400 Subject: RFR (S): 8024943: ciReplay: fails to dump replay data during safepointing In-Reply-To: References: <524C7ECF.80004@oracle.com> Message-ID: <524D7F86.4080003@oracle.com> Updated webrev: http://cr.openjdk.java.net/~vlivanov/8024943/webrev.01/ Verified that replay data is dumped correctly in the following combinations: - thread_in_native - thread_in_vm - thread_in_vm + Compile_lock Regarding ciEnv in invalid state (leaving aside the cases when the instance is corrupted), the only case when it is possible is when the VM crashed in ~ciEnv(). Don't know whether fixing it is worth the effort - in both cases we don't get valid replay data file. Best regards, Vladimir Ivanov On 10/3/13 12:57 AM, John Rose wrote: > On Oct 2, 2013, at 1:15 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8024943/webrev.00/ >> 15 lines changed: 11 ins; 0 del; 4 mod >> >> In some situations VM fails to dump compiler replay file (produces empty replay_pid%p.log). The reason is that ciEnv::dump_replay_data tries to do thread state transition to VM unconditionally and acquire Compile_lock. It doesn't always work in context of VM error reporter. >> >> The fix is to provide new method specifically for VM error reporter (ciEnv::dump_replay_data_unsafe) which doesn't perform aforementioned actions. >> >> Testing: manual (checked that a valid dump is produced for a crash during safepointing). > > Is is possible that you've pushed a bug further into the CI code? I would like you to take a look at this (if you haven't already) and either make code adjustments or describe current assumptions in comments, for the next maintainer. > > What I mean about "pushed a bug" is that the CI is (generally speaking) sensitive to the thread state. (Note the GUARDED_VM_ENTRY macros everywhere.) The dump_replay_data function calls a bunch of dump_replay_data subroutines on lots of little data structures in the CI. Are any of them also sensitive to thread state? If so, perhaps you want to have your > > Also, the ciEnv::current() call returns something to the error reporter, and if that something is non-null, it is assumed to be (up to high probability, of course) a valid ciEnv structure. Are there any places where the ciEnv guy is in an inconsistent state but still published by ciEnv::current()? Probably not, but it might be worth a comment noting the appropriate conditions. My specific worry is that the call to remove_symbols in ~ciEnv might leave a space where the dumper would not see valid state. > > This crash dumper stuff cannot be nailed down 100%, of course, but this might be a good moment to make sure we've at least stomped on it a bit. > > Reviewed, pending resolution of the above. > > Thanks, > ? John > From vladimir.kozlov at oracle.com Thu Oct 3 09:57:10 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 09:57:10 -0700 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524C6C12.9050200@oracle.com> References: <524C6C12.9050200@oracle.com> Message-ID: <524DA1E6.1050903@oracle.com> I don't think it is right. You need to have check before the loop's body execution. Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. I think we should use int64 type for these expressions as in other lines of this method. Thanks, Vladimir On 10/2/13 11:55 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ > 7 lines changed: 4 ins; 0 del; 3 mod > > If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ overflows and j <= r->hi() succeeds again (leading to > extra iterations and infinite loop in the product). > > The fix is to check whether upper limit is reached (j >= r->hi()) and stop iterating, if necessary. > > Also, did a small cleanup: eliminated unused parameter from SwitchRange::print. > > Testing: failing test case. > > Reviewed-by: iveresov, ? > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Oct 3 10:03:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 10:03:34 -0700 Subject: RFR (S): 8024943: ciReplay: fails to dump replay data during safepointing In-Reply-To: <524D7F86.4080003@oracle.com> References: <524C7ECF.80004@oracle.com> <524D7F86.4080003@oracle.com> Message-ID: <524DA366.9030903@oracle.com> Looks good to me. I will need old method with state transition for my changes to dump replay per request. Thanks, Vladimir On 10/3/13 7:30 AM, Vladimir Ivanov wrote: > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8024943/webrev.01/ > > Verified that replay data is dumped correctly in the following combinations: > - thread_in_native > - thread_in_vm > - thread_in_vm + Compile_lock > > Regarding ciEnv in invalid state (leaving aside the cases when the instance is corrupted), the only case when it is > possible is when the VM crashed in ~ciEnv(). Don't know whether fixing it is worth the effort - in both cases we don't > get valid replay data file. > > Best regards, > Vladimir Ivanov > > On 10/3/13 12:57 AM, John Rose wrote: >> On Oct 2, 2013, at 1:15 PM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8024943/webrev.00/ >>> 15 lines changed: 11 ins; 0 del; 4 mod >>> >>> In some situations VM fails to dump compiler replay file (produces empty replay_pid%p.log). The reason is that >>> ciEnv::dump_replay_data tries to do thread state transition to VM unconditionally and acquire Compile_lock. It >>> doesn't always work in context of VM error reporter. >>> >>> The fix is to provide new method specifically for VM error reporter (ciEnv::dump_replay_data_unsafe) which doesn't >>> perform aforementioned actions. >>> >>> Testing: manual (checked that a valid dump is produced for a crash during safepointing). >> >> Is is possible that you've pushed a bug further into the CI code? I would like you to take a look at this (if you >> haven't already) and either make code adjustments or describe current assumptions in comments, for the next maintainer. >> >> What I mean about "pushed a bug" is that the CI is (generally speaking) sensitive to the thread state. (Note the >> GUARDED_VM_ENTRY macros everywhere.) The dump_replay_data function calls a bunch of dump_replay_data subroutines on >> lots of little data structures in the CI. Are any of them also sensitive to thread state? If so, perhaps you want to >> have your >> >> Also, the ciEnv::current() call returns something to the error reporter, and if that something is non-null, it is >> assumed to be (up to high probability, of course) a valid ciEnv structure. Are there any places where the ciEnv guy >> is in an inconsistent state but still published by ciEnv::current()? Probably not, but it might be worth a comment >> noting the appropriate conditions. My specific worry is that the call to remove_symbols in ~ciEnv might leave a space >> where the dumper would not see valid state. >> >> This crash dumper stuff cannot be nailed down 100%, of course, but this might be a good moment to make sure we've at >> least stomped on it a bit. >> >> Reviewed, pending resolution of the above. >> >> Thanks, >> ? John >> From christian.thalinger at oracle.com Thu Oct 3 10:18:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 10:18:53 -0700 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DA1E6.1050903@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> Message-ID: <0F35D9CC-DBFB-4A1B-A257-D00126F6A146@oracle.com> I agree with Vladimir here. The code looks even more fragile after the fix. On Oct 3, 2013, at 9:57 AM, Vladimir Kozlov wrote: > I don't think it is right. You need to have check before the loop's body execution. > Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. > I think we should use int64 type for these expressions as in other lines of this method. > > Thanks, > Vladimir > > On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >> 7 lines changed: 4 ins; 0 del; 3 mod >> >> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ overflows and j <= r->hi() succeeds again (leading to >> extra iterations and infinite loop in the product). >> >> The fix is to check whether upper limit is reached (j >= r->hi()) and stop iterating, if necessary. >> >> Also, did a small cleanup: eliminated unused parameter from SwitchRange::print. >> >> Testing: failing test case. >> >> Reviewed-by: iveresov, ? >> >> Best regards, >> Vladimir Ivanov From christian.thalinger at oracle.com Thu Oct 3 10:40:39 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 10:40:39 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: <985B4B9F-9E00-4930-9062-9979C005CDF6@oracle.com> References: <985B4B9F-9E00-4930-9062-9979C005CDF6@oracle.com> Message-ID: <559B327A-C586-434D-84F4-34AF1BA9AF99@oracle.com> Thank you, John. On Oct 2, 2013, at 11:38 PM, John Rose wrote: > Reviewed. > > On Oct 2, 2013, at 8:17 PM, Christian Thalinger wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8025566 >> http://cr.openjdk.java.net/~twisti/8025566 >> >> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >> Reviewed-by: >> >> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >> >> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >> > From vladimir.x.ivanov at oracle.com Thu Oct 3 11:04:27 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 22:04:27 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DA1E6.1050903@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> Message-ID: <524DB1AB.8060406@oracle.com> Vladimir, I like the idea to convert j to int64. It looks much cleaner now. Here's updated webrev: http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 Best regards, Vladimir Ivanov On 10/3/13 8:57 PM, Vladimir Kozlov wrote: > I don't think it is right. You need to have check before the loop's body > execution. > Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. > I think we should use int64 type for these expressions as in other lines > of this method. > > Thanks, > Vladimir > > On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >> 7 lines changed: 4 ins; 0 del; 3 mod >> >> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >> overflows and j <= r->hi() succeeds again (leading to >> extra iterations and infinite loop in the product). >> >> The fix is to check whether upper limit is reached (j >= r->hi()) and >> stop iterating, if necessary. >> >> Also, did a small cleanup: eliminated unused parameter from >> SwitchRange::print. >> >> Testing: failing test case. >> >> Reviewed-by: iveresov, ? >> >> Best regards, >> Vladimir Ivanov From albert.noll at oracle.com Thu Oct 3 11:17:26 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 03 Oct 2013 20:17:26 +0200 Subject: RFR(XS): 8024008: Nashorn V8 (Crypto) benchmark crashes with small CodeCache size In-Reply-To: <522FA629.10509@oracle.com> References: <522DD453.4010809@oracle.com> <522E09C4.1070700@oracle.com> <522EC44F.2060005@oracle.com> <522F1612.4030606@oracle.com> <522FA629.10509@oracle.com> Message-ID: <524DB4B6.7040201@oracle.com> Hi, I think I found the reason for the crash. Please forget the previous suggestions. See the following webrev: Problem: http://cr.openjdk.java.net/~anoll/8024008/webrev.02/ If the code cache gets full, this code in compileBroker.cpp is not executed. 1318 (void) AdapterHandlerLibrary::create_native_wrapper(method, compile_id); As a result, we get the following error "i2c adapter must return to an interpreter frame" if the JVM is called with "-XX:+UnlockDiagnosticVMOptions -XX:+VerifyAdapterCalls" I do not yet fully understand why that's the case, so please if you know let me know. Solution: Move the code cache is full-check after line 1318. Many thanks, Albert Am 11.09.2013 01:07, schrieb Vladimir Kozlov: > Albert, > > I would suggest to run as many tests as possible to verify correctness > of changes because this code is very important. > > Thanks, > Vladimir > > On 9/10/13 5:52 AM, Albert Noll wrote: >> Hi, >> >> the current version causes a serious performance regression. >> I have to figure out what's wrong. >> >> Best, >> Albert >> >> On 10.09.2013 09:03, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for looking at this. I checked all call sites of >>> 'make_not_entrant()' and 'make_zombie()'. I do not see any problems. >>> The worst thing that can happen is that an nmethod for which the call >>> returns fals gets removed later than expected. >>> >>> I updated the comment and did some minor code refactoring. >>> >>> Also I think that it is worth considering to backport this change, >>> since the bug can appear any time >>> the code cache fills up. If that bug appears, it is extremely hard to >>> reproduce and debug. >>> >>> Here is the updated webrev. >>> http://cr.openjdk.java.net/~anoll/8024008/webrev.01/ >>> >>> >>> Best, >>> Albert >>> >>> >>> >>> On 09.09.2013 19:47, Vladimir Kozlov wrote: >>>> Several places in sources do not check returned result of >>>> make_not_entrant_or_zombie(). And they may assume that method marked >>>> as non-entrant, for example, because before we returned 'false' only >>>> when an other thread already changed the state to one we need. >>>> >>>> Can you check all call sites to make sure they work correctly with >>>> this change? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/9/13 6:59 AM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> thanks for reviewing this patch. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8024008 >>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.00/ >>>>> >>>>> >>>>> Many thanks in advance, >>>>> Albert >>>>> >>>>> Problem: >>>>> The state of nmethods that are currently locked by the VM must not >>>>> change. >>>>> Some operations such as setting ICs (e.g., >>>>> SharedRuntime::resolve_sub_helper()) >>>>> rely on this fact. 'nmethod::make_not_entrant_or_zombie does not >>>>> make this >>>>> check. >>>>> >>>>> Solution: >>>>> Do method state unchanged of nmethod is locked by the VM. >>>>> >>>>> Testing: Run Octane benchmarks on top of Nashorn with small code >>>>> cache size (16m). >>>>> >>> >> From christian.thalinger at oracle.com Thu Oct 3 11:21:50 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 11:21:50 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> Message-ID: <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> On Oct 3, 2013, at 1:40 AM, Roland Westrelin wrote: >> I was tempted to remove the InlineTree::_caller_jvms completely but that might be too intrusive for now. > > Why do you need to pass a jvms rather than use caller_jvms()? InlineTree::_caller_jvms is not a deep clone of the JVMS and thus has no map; it's just used as a container for method and bci. In fact, as I mentioned in my original email, we should remove InlineTree::_caller_jvms since it's not of much use but that's for another bug. > Does a lambda form always have a receiver? "receiver", yes. The methods are static but the first argument is always a MethodHandle. > You should probably use: > caller_argument0->uncast() == callee_argument0->uncast() I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? > > Roland. From christian.thalinger at oracle.com Thu Oct 3 11:24:00 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 11:24:00 -0700 Subject: RFR (S): 8025656: compiler/8013496/Test8013496.sh fails on assert In-Reply-To: <524BF9B1.3060602@oracle.com> References: <524ABA6B.3040701@oracle.com> <524B0757.8010101@oracle.com> <524BF9B1.3060602@oracle.com> Message-ID: Looks good. On Oct 2, 2013, at 3:47 AM, Albert Noll wrote: > Hi Valdimir, > > thanks for your feedback. See comments inline. > Here is the new webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.01/ > > On 01.10.2013 19:33, Vladimir Kozlov wrote: >> Albert, >> >> I think the only problem is call to handle_full_code_cache() in C1 Compiler::get_buffer_blob(). Please verify that. There are calls during adapters generation and I don't see which state at that time. > Yes, I think that this is the only call that causes the assertion to fail. I checked the state of the thread in > AdapterHandlerLibrary::create_native_wrapper() and AdapterHandlerLibrary::get_adapter and in both > functions the thread is in state '_thread_in_vm'. > >> If the problem only in get_buffer_blob() it will be solved when you remove the call in 8023014. > Yes, it will be removed. >> On other hand it will not hurt to have transition here. > I agree that's why I would keep it. It could help to fix JDK-8022968 more easily. >> You need to fix comment: >> >> "This ensures that handle_full_code_cache()" should be "This ensures that possibly_sweep()" >> Fixing the test is fine. >> > Done. > > Thanks again, > Albert > > Thanks, >> Vladimir >> >> On 10/1/13 5:04 AM, Albert Noll wrote: >>> Hi, >>> >>> could I have a review for this small patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8025656 >>> webrev: http://cr.openjdk.java.net/~anoll/8025656/webrev.00/ >>> >>> Problem: handle_full_code_cache is called when the calling thread is in a wrong state. >>> >>> Solution: Switch to the right thread state before calling sweeper. >>> >>> I also re-wrote the corresponding test. In the new version, the arguments take a larger InitialCodeCacheSize >>> and ReservedCodeCacheSize. Too small code cache sizes can fail the compiler runtime initialization and hence >>> the test. Checking proper compiler runtime initialization is checked by 8023014. >>> >>> Many thanks in advance, >>> Albert >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/e581dde1/attachment.html From vladimir.kozlov at oracle.com Thu Oct 3 11:24:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 11:24:53 -0700 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DB1AB.8060406@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> Message-ID: <524DB675.6090101@oracle.com> You need to add cast (int)(j - lowval) since argument type is int. Some C++ compiler will complain if no cast. Thanks, Vladimir K On 10/3/13 11:04 AM, Vladimir Ivanov wrote: > Vladimir, > > I like the idea to convert j to int64. It looks much cleaner now. > > Here's updated webrev: > http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 > > Best regards, > Vladimir Ivanov > > On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >> I don't think it is right. You need to have check before the loop's body >> execution. >> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >> I think we should use int64 type for these expressions as in other lines >> of this method. >> >> Thanks, >> Vladimir >> >> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>> 7 lines changed: 4 ins; 0 del; 3 mod >>> >>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>> overflows and j <= r->hi() succeeds again (leading to >>> extra iterations and infinite loop in the product). >>> >>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>> stop iterating, if necessary. >>> >>> Also, did a small cleanup: eliminated unused parameter from >>> SwitchRange::print. >>> >>> Testing: failing test case. >>> >>> Reviewed-by: iveresov, ? >>> >>> Best regards, >>> Vladimir Ivanov From john.coomes at oracle.com Thu Oct 3 11:25:20 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 18:25:20 +0000 Subject: hg: hsx/hotspot-comp: 5 new changesets Message-ID: <20131003182521.753CD62D17@hg.openjdk.java.net> Changeset: 5ec3c4948863 Author: ksrini Date: 2013-09-27 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/5ec3c4948863 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, erikj ! common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk Changeset: 72c2495c86c9 Author: katleman Date: 2013-10-01 12:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/72c2495c86c9 Merge Changeset: 0f704e36bc5d Author: ihse Date: 2013-10-01 10:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/0f704e36bc5d 8006661: Use LC_ALL=C instead of LANG=C compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 4faa09c7fe55 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4faa09c7fe55 Merge Changeset: 669e3e3d4459 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/669e3e3d4459 Added tag jdk8-b110 for changeset 4faa09c7fe55 ! .hgtags From john.coomes at oracle.com Thu Oct 3 11:25:58 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 18:25:58 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b110 for changeset 3d2b7ce93c5c Message-ID: <20131003182601.C0B7862D18@hg.openjdk.java.net> Changeset: 85c1c94e7235 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/85c1c94e7235 Added tag jdk8-b110 for changeset 3d2b7ce93c5c ! .hgtags From john.coomes at oracle.com Thu Oct 3 11:26:23 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 18:26:23 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b110 for changeset 4c84c5b447b0 Message-ID: <20131003182643.1321962D19@hg.openjdk.java.net> Changeset: 17ee0d3e97fd Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/17ee0d3e97fd Added tag jdk8-b110 for changeset 4c84c5b447b0 ! .hgtags From john.coomes at oracle.com Thu Oct 3 11:27:00 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 18:27:00 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b110 for changeset cc682329886b Message-ID: <20131003182709.5E30362D1A@hg.openjdk.java.net> Changeset: 32edc7a2c866 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/32edc7a2c866 Added tag jdk8-b110 for changeset cc682329886b ! .hgtags From roland.westrelin at oracle.com Thu Oct 3 11:28:06 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 3 Oct 2013 20:28:06 +0200 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> Message-ID: <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> >> You should probably use: >> caller_argument0->uncast() == callee_argument0->uncast() > > I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. Roland. From vladimir.x.ivanov at oracle.com Thu Oct 3 11:35:27 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 03 Oct 2013 22:35:27 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DB675.6090101@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> Message-ID: <524DB8EF.7030908@oracle.com> Thanks for catching that. How about that? http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 Best regards, Vladimir Ivanov On 10/3/13 10:24 PM, Vladimir Kozlov wrote: > You need to add cast (int)(j - lowval) since argument type is int. Some > C++ compiler will complain if no cast. > > Thanks, > Vladimir K > > On 10/3/13 11:04 AM, Vladimir Ivanov wrote: >> Vladimir, >> >> I like the idea to convert j to int64. It looks much cleaner now. >> >> Here's updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 >> >> Best regards, >> Vladimir Ivanov >> >> On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >>> I don't think it is right. You need to have check before the loop's body >>> execution. >>> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >>> I think we should use int64 type for these expressions as in other lines >>> of this method. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>> >>>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>>> overflows and j <= r->hi() succeeds again (leading to >>>> extra iterations and infinite loop in the product). >>>> >>>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>>> stop iterating, if necessary. >>>> >>>> Also, did a small cleanup: eliminated unused parameter from >>>> SwitchRange::print. >>>> >>>> Testing: failing test case. >>>> >>>> Reviewed-by: iveresov, ? >>>> >>>> Best regards, >>>> Vladimir Ivanov From john.coomes at oracle.com Thu Oct 3 11:31:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 18:31:41 +0000 Subject: hg: hsx/hotspot-comp/jdk: 115 new changesets Message-ID: <20131003190030.07EE762D1D@hg.openjdk.java.net> Changeset: 529cd4de1823 Author: prr Date: 2013-09-26 15:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/529cd4de1823 7092764: java.awt.font.TransformAttribute.equals(null) throws NPE Reviewed-by: jgodinez, jchen ! src/share/classes/java/awt/font/TransformAttribute.java + test/java/awt/font/TransformAttribute/TransformEqualityTest.java Changeset: 1bcd48cfb7be Author: ceisserer Date: 2013-09-26 16:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1bcd48cfb7be 8024895: xrender MaskImage cache isn't accounting for change in alpha Reviewed-by: prr, jchen ! src/solaris/classes/sun/java2d/xr/XRMaskImage.java + test/java/awt/image/DrawImage/EABlitTest.java Changeset: dae020405903 Author: lana Date: 2013-09-26 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dae020405903 Merge Changeset: 0151f12bd392 Author: malenkov Date: 2013-08-22 17:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0151f12bd392 8023536: Some regression tests have a wrong header Reviewed-by: alexsch ! test/java/beans/Performance/Test7122740.java ! test/java/beans/Performance/Test7184799.java ! test/javax/swing/JTree/8013571/Test8013571.java Changeset: b71f112dab2a Author: malenkov Date: 2013-08-22 21:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b71f112dab2a 7057769: JScrollBar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/javax/swing/JScrollBar.java Changeset: f983fd18dd81 Author: malenkov Date: 2013-08-23 19:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f983fd18dd81 7080613: java.beans.DefaultPersistenceDelegate.instantiate(..) doesn't throw NPE Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/PersistenceDelegate.java Changeset: 22ef5187a3e6 Author: dmarkov Date: 2013-08-26 17:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/22ef5187a3e6 8023474: First mousepress doesn't start editing in JTree Reviewed-by: alexp, anthony ! src/share/classes/java/awt/Component.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/basic/BasicTreeUI/8023474/bug8023474.java Changeset: abd068530590 Author: malenkov Date: 2013-08-27 12:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/abd068530590 7195179: ClassCastException for null values in JComboBox Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java + test/javax/swing/JComboBox/7195179/Test7195179.java Changeset: 92adff44c841 Author: malenkov Date: 2013-08-27 13:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/92adff44c841 8021379: JFileChooser Create New Folder button enabled in write proteced directory Reviewed-by: alexsch ! src/share/classes/sun/swing/FilePane.java Changeset: 4bfcf9c5ced3 Author: malenkov Date: 2013-08-27 13:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4bfcf9c5ced3 8022398: javax/swing/JFileChooser/8013442/Test8013442.java fails Reviewed-by: alexsch ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java + src/share/classes/sun/swing/AbstractFilterComboBoxModel.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: e11ed7187b0c Author: lana Date: 2013-08-27 21:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e11ed7187b0c Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 43de418f1345 Author: ptbrunet Date: 2013-08-28 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/43de418f1345 8011955: Lunar screen reader crashes intermittently in WindowsAccessBridge-32.DLL 6995891: JAWS will occasionally stop speaking focused objects as user TABs -> problem with message queue 8014738: Combobox menu items are not announced with JAWS 8011938: Java Ferret example corrupts JCombobox of the running application 8012011: JAB 2.0.2 incompletely shows kbd accelerator in menus 8022966: Java Access Bridge no longer usable with screen magnifiers Reviewed-by: raginip, tbell, erikj, art ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcMisc.gmk Changeset: 35644adc3269 Author: malenkov Date: 2013-08-28 17:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/35644adc3269 6968363: ClassCastException while entering HINDI characters with CustomDocument Reviewed-by: alexsch ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/GlyphPainter2.java ! src/share/classes/javax/swing/text/ParagraphView.java + test/javax/swing/text/AbstractDocument/6968363/Test6968363.java Changeset: 6432f8749e1d Author: pchelko Date: 2013-08-30 11:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6432f8749e1d 8023966: JViewPort.BLIT_SCROLL_MODE does not work in JLightweightFrame Reviewed-by: anthony, ant ! src/share/classes/javax/swing/JViewport.java Changeset: 7151f08eeadf Author: alexsch Date: 2013-08-30 13:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7151f08eeadf 8022401: [macosx] javax/swing/text/JTextComponent/5074573/bug5074573.java fails Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTEvent.m + test/java/awt/event/KeyEvent/KeyChar/KeyCharTest.java Changeset: f2f614e31522 Author: malenkov Date: 2013-09-02 14:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f2f614e31522 7156658: JTextComponent.setFocusAccelerator() spec does not state that focus accelerator is L&F dependent Reviewed-by: alexsch ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 6ffa2680e139 Author: art Date: 2013-09-02 16:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6ffa2680e139 8022184: Fix static , Raw warnings in classes belonging to java.awt Reviewed-by: art, anthony Contributed-by: Srikalyan Chandrashekar ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/CardLayout.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/GradientPaintContext.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/TexturePaintContext.java ! src/share/classes/java/awt/WaitDispatchSupport.java Changeset: b5ed8686cc01 Author: malenkov Date: 2013-09-03 11:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b5ed8686cc01 6943780: JTabbedPane throws ArrayIndexOutOfBoundsException sometimes Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/plaf/basic/BasicTabbedPaneUI/Test6943780.java Changeset: 80a8c4ff3b51 Author: alexsch Date: 2013-09-03 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/80a8c4ff3b51 8007156: [macosx] Wrong events in processKeyBinding of JTable Submit Date Reviewed-by: leonidr ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/java/awt/event/KeyEvent/ExtendedKeyCode/ExtendedKeyCodeTest.java Changeset: 2ad01ecbaf90 Author: malenkov Date: 2013-09-03 21:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2ad01ecbaf90 7172865: PropertyDescriptor fails to work with setter method name if setter is non-void Reviewed-by: art, alexsch ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java + src/share/classes/java/beans/MethodRef.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test7172865.java Changeset: ba711056009f Author: pchelko Date: 2013-09-04 14:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ba711056009f 8021943: FileDialog getFile returns corrupted string after previous setFile Reviewed-by: anthony, serb Contributed-by: alexander.zvegintsev at oracle.com ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: ba041df8a554 Author: mcherkas Date: 2013-09-04 18:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ba041df8a554 8023565: JPG causes javax.imageio.IIOException: ICC APP2 encoutered without prior JFIF Reviewed-by: bae, vadim ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java Changeset: e4ba3d9ea041 Author: mcherkas Date: 2013-09-05 15:37 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e4ba3d9ea041 8023392: Swing text components printed with spaces between chars Reviewed-by: alexsch, alexp Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/sun/swing/SwingUtilities2.java + test/java/awt/print/bug8023392/bug8023392.html + test/java/awt/print/bug8023392/bug8023392.java Changeset: d267c066b006 Author: lana Date: 2013-09-06 15:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d267c066b006 Merge - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java Changeset: fbb6f976d780 Author: alexsch Date: 2013-09-09 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fbb6f976d780 8024413: Add tests for issues JDK-8002077 and JDK-7199708 Reviewed-by: malenkov, leonidr + test/javax/swing/JFileChooser/7199708/bug7199708.java + test/javax/swing/JFileChooser/8002077/bug8002077.java Changeset: 3ea08767fc0d Author: alexsch Date: 2013-09-09 18:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3ea08767fc0d 8020060: MoleculeViewerTest demo doesn't work due to SecurityPermissions Reviewed-by: malenkov, erikj ! makefiles/CompileDemos.gmk ! src/share/demo/applets/MoleculeViewer/XYZApp.java ! src/share/demo/applets/MoleculeViewer/example1.html ! src/share/demo/applets/MoleculeViewer/example2.html ! src/share/demo/applets/MoleculeViewer/example3.html ! src/share/demo/applets/WireFrame/ThreeD.java ! src/share/demo/applets/WireFrame/example1.html ! src/share/demo/applets/WireFrame/example2.html ! src/share/demo/applets/WireFrame/example3.html ! src/share/demo/applets/WireFrame/example4.html Changeset: fc5d16fec25f Author: serb Date: 2013-09-09 21:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fc5d16fec25f 8023042: Inaccuracy in documentation in a sound area Reviewed-by: prr ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java Changeset: 9d0d961fb1cd Author: pchelko Date: 2013-09-10 11:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9d0d961fb1cd 8024381: The test for 8020210 does not have @bug tag Reviewed-by: anthony, serb ! test/java/awt/Window/MaximizeOffscreen/MaximizeOffscreenTest.java Changeset: 8b6dace81d6c Author: alexsch Date: 2013-09-10 14:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8b6dace81d6c 8021253: JFileChooser does not react on pressing enter since java 7 Reviewed-by: malenkov ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/8021253/bug8021253.java Changeset: 1daffcf035c4 Author: malenkov Date: 2013-09-10 17:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1daffcf035c4 7057770: (spec)Scrollbar spec should specify that unit increment & decrement functionality may not be present Reviewed-by: alexsch ! src/share/classes/java/awt/Scrollbar.java Changeset: eedb2b6d93ec Author: malenkov Date: 2013-09-10 17:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eedb2b6d93ec 8024407: [macosx] javax/swing/JScrollBar/7163696/Test7163696.java failed intermittently on macos Reviewed-by: alexsch ! test/javax/swing/JScrollBar/7163696/Test7163696.java Changeset: 0cc00c11e17e Author: leonidr Date: 2013-09-10 20:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0cc00c11e17e 8003901: [macosx] Need test for JDK-8002114 Reviewed-by: anthony, serb ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 04fbd34fda7b Author: bagiras Date: 2013-09-12 14:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/04fbd34fda7b 8003965: Toolkit.beep() documentation is ambiguous Reviewed-by: anthony ! src/share/classes/java/awt/Toolkit.java Changeset: def1fa9854f7 Author: bagiras Date: 2013-09-12 15:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/def1fa9854f7 7064312: Cleanup: avoid using unsafe string function Reviewed-by: serb, pchelko ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_ole.cpp Changeset: 6321e4429a38 Author: serb Date: 2013-09-12 18:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6321e4429a38 7124537: [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled Reviewed-by: anthony, leonidr ! src/macosx/classes/sun/lwawt/macosx/CMenu.java ! src/macosx/classes/sun/lwawt/macosx/CMenuItem.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: 3213c388740a Author: dmarkov Date: 2013-09-12 18:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3213c388740a 8024395: Improve fix for line break calculations Reviewed-by: alexp, alexsch ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/View.java ! test/javax/swing/text/View/8014863/bug8014863.java Changeset: ef2f0c15b332 Author: pchelko Date: 2013-09-13 11:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ef2f0c15b332 8024170: [SwingNode] Implement cursor change Reviewed-by: anthony, ant ! src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java ! src/share/classes/sun/swing/SwingAccessor.java ! src/solaris/classes/sun/awt/X11/XLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WLightweightFramePeer.java Changeset: 12788c245d67 Author: pchelko Date: 2013-09-13 17:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/12788c245d67 8015453: java/awt/DataFlavor/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java failed on windows with jdk8 since b86 Reviewed-by: art, serb ! src/share/classes/sun/awt/datatransfer/DataTransferer.java Changeset: df107b1f2f2e Author: pchelko Date: 2013-09-13 17:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/df107b1f2f2e 8015371: The HTML text without tags does not appear inside the WordPad application, and we try to click the button, but the case exits. Reviewed-by: anthony, serb ! src/windows/classes/sun/awt/windows/WDataTransferer.java Changeset: 40fdf56c09a9 Author: pchelko Date: 2013-09-13 17:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/40fdf56c09a9 8015455: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java hangs on windows Reviewed-by: serb, anthony ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/javax/swing/TransferHandler.java Changeset: 915d13946f18 Author: mcherkas Date: 2013-09-13 17:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/915d13946f18 8015601: [macosx] Test javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java fails on MacOS X Reviewed-by: alexp, alexsch ! test/javax/swing/JInternalFrame/InternalFrameIsNotCollectedTest.java Changeset: ad52e924c55a Author: kshefov Date: 2013-09-13 17:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ad52e924c55a 8006087: [TEST_BUG] The BACKSPACE key doesn't work and after pressing 'cancel' and 'DONE' button, the case pass automatically. Reviewed-by: alexsch, serb ! test/javax/swing/JFileChooser/4150029/bug4150029.html ! test/javax/swing/JFileChooser/4150029/bug4150029.java Changeset: c8a85165b725 Author: kshefov Date: 2013-09-13 17:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c8a85165b725 8015597: [TEST_BUG] [macosx] Test closed/javax/swing/JMenuBar/4750590/bug4750590.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/JMenuBar/4750590/bug4750590.java Changeset: 17cc8f13e4e7 Author: pchelko Date: 2013-09-13 18:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/17cc8f13e4e7 8012026: [macosx] Component.getMousePosition() does not work in an applet on MacOS Reviewed-by: anthony, serb ! make/sun/lwawt/FILES_export_macosx.gmk - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java + test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: a46d22ee4d4b Author: alexsch Date: 2013-09-16 17:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a46d22ee4d4b 8008728: [macosx] Swing. JDialog. Modal dialog goes to background Reviewed-by: serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java Changeset: 8f5b4e7623cf Author: ant Date: 2013-09-16 18:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8f5b4e7623cf 8022512: JLightweightFrame: the content pane should be transparent Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java Changeset: 49c7d299a504 Author: kshefov Date: 2013-09-16 19:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/49c7d299a504 7020060: [TEST_BUG] java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java failed Reviewed-by: anthony, serb ! test/java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java Changeset: 98080e9367be Author: kshefov Date: 2013-09-16 19:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/98080e9367be 8015588: [TEST_BUG] [macosx] Test java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java fails on MacOSX Reviewed-by: anthony, serb ! test/java/awt/MenuBar/MenuBarSetFont/MenuBarSetFont.java Changeset: 04612a52e7bd Author: pchelko Date: 2013-09-16 19:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/04612a52e7bd 8024779: [macosx] SwingNode crashes on exit Reviewed-by: anthony, ant ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 4e88bf592830 Author: pchelko Date: 2013-09-16 19:44 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4e88bf592830 8024485: For 5-1 step: if input something into the 'File:' and 'Dir:', the dir output isn't empty in the output window after showing and canceling the file dialog Reviewed-by: serb, anthony ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java Changeset: 8530456e0091 Author: omajid Date: 2013-09-16 15:43 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8530456e0091 8024863: X11: Support GNOME Shell as mutter Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XWM.java Changeset: 4899f6734a14 Author: ant Date: 2013-09-18 12:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4899f6734a14 8024839: [Unified Swing/Fx threading] don't schedule an event dispatching from the event dispatch thread Reviewed-by: anthony, pchelko ! src/share/classes/java/awt/EventQueue.java Changeset: cc7a15f4c735 Author: mcherkas Date: 2013-09-18 15:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cc7a15f4c735 8016746: Test javax/swing/JTable/7068740/bug7068740.java fails Reviewed-by: serb, alexsch ! test/javax/swing/JTable/7068740/bug7068740.java Changeset: 2c240454c192 Author: leonidr Date: 2013-09-18 18:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2c240454c192 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java Changeset: 20b1135647fa Author: lana Date: 2013-09-18 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/20b1135647fa Merge ! src/share/classes/java/awt/Toolkit.java - src/share/classes/java/util/stream/CloseableStream.java - src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/windows/native/sun/windows/awt_PrintControl.cpp - test/java/util/Collection/ListDefaults.java - test/java/util/Map/CheckRandomHashSeed.java - test/java/util/Map/TreeBinSplitBackToEntries.java - test/java/util/concurrent/ConcurrentHashMap/toArray.java - test/sun/tools/jconsole/ImmutableResourceTest.java - test/sun/tools/jconsole/ImmutableResourceTest.sh Changeset: e292d504ad68 Author: leonidr Date: 2013-09-19 22:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e292d504ad68 7144065: [macosx] Orphaned Choice popup window Reviewed-by: anthony, serb Contributed-by: alexander.potochkin at oracle.com ! src/macosx/classes/sun/lwawt/LWChoicePeer.java Changeset: 602e5d0141d3 Author: leonidr Date: 2013-09-19 23:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/602e5d0141d3 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Reviewed-by: anthony, serb ! makefiles/GensrcProperties.gmk + src/macosx/classes/sun/awt/resources/awtosx.properties ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/sun/awt/AWTAccessor.java + test/java/awt/Toolkit/ToolkitPropertyTest/bug7129133.java Changeset: c04e55e17066 Author: kshefov Date: 2013-09-20 17:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c04e55e17066 7124314: [TEST_BUG] [macosx] Aqua LAF: JTree doesn't select element by keyboards left and right keys Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JTree/4927934/bug4927934.java Changeset: 6c1f9468f3de Author: kshefov Date: 2013-09-20 17:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6c1f9468f3de 8017180: [macosx] [TEST_BUG] alt-key doesn't work on macos for menu Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/java/awt/Focus/KeyEventForBadFocusOwnerTest/KeyEventForBadFocusOwnerTest.java + test/javax/swing/JMenuItem/4171437/bug4171437.java + test/javax/swing/JPopupMenu/4458079/bug4458079.java Changeset: f139aef966fd Author: kshefov Date: 2013-09-20 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f139aef966fd 7124232: [TEST_BUG] [macosx] JSplitPane has wrong divider location Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JSplitPane/4816114/bug4816114.java Changeset: abebe03818f6 Author: malenkov Date: 2013-09-20 18:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/abebe03818f6 7024235: Nimbus L&F: wrong "packing" of a frame containing tabbed pane Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java + test/javax/swing/JTabbedPane/7024235/Test7024235.java Changeset: 2ac59698de38 Author: kshefov Date: 2013-09-23 16:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2ac59698de38 8015600: [TEST_BUG] [macosx] Test closed/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java Changeset: eac52fe3990c Author: serb Date: 2013-09-23 16:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/eac52fe3990c 8005255: [macosx] Cleanup warnings in sun.lwawt Reviewed-by: alexsch, anthony ! make/sun/lwawt/FILES_export_macosx.gmk ! src/macosx/classes/sun/lwawt/LWButtonPeer.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java ! src/macosx/classes/sun/lwawt/LWChoicePeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWContainerPeer.java ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWListPeer.java ! src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java ! src/macosx/classes/sun/lwawt/LWPanelPeer.java ! src/macosx/classes/sun/lwawt/LWRepaintArea.java ! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java - src/macosx/classes/sun/lwawt/SelectionClearListener.java Changeset: 2684fd4e9f3b Author: serb Date: 2013-09-23 17:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2684fd4e9f3b 7172833: For default java.awt.Toolkit impl methods java.awt.Toolkit.is/setDynamicLayout() are not consistent Reviewed-by: alexsch, anthony ! src/share/classes/java/awt/Toolkit.java + test/java/awt/Toolkit/DynamicLayout/bug7172833.java Changeset: d73d3a29065c Author: serb Date: 2013-09-23 21:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d73d3a29065c 8019282: keyRelesed is reached even though key was NOT released Reviewed-by: serb, anthony Contributed-by: alexander.zvegintsev at oracle.com ! make/sun/xawt/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: 8c0b943a0090 Author: yan Date: 2013-09-24 12:25 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8c0b943a0090 8025114: Eliminate doclint errors in java.awt.dnd package javadoc Reviewed-by: serb, alexsch ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/DragSourceContext.java ! src/share/classes/java/awt/dnd/DragSourceDragEvent.java ! src/share/classes/java/awt/dnd/DragSourceDropEvent.java ! src/share/classes/java/awt/dnd/DragSourceEvent.java ! src/share/classes/java/awt/dnd/DropTarget.java ! src/share/classes/java/awt/dnd/DropTargetDragEvent.java ! src/share/classes/java/awt/dnd/DropTargetDropEvent.java Changeset: 1303823e89da Author: yan Date: 2013-09-24 16:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1303823e89da 8025230: [cleanup] some more javadoc formatting fixes for swing Reviewed-by: alexsch ! src/share/classes/javax/swing/JPanel.java ! src/share/classes/javax/swing/JPasswordField.java ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/JRadioButton.java ! src/share/classes/javax/swing/JRadioButtonMenuItem.java ! src/share/classes/javax/swing/JRootPane.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JSeparator.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JToolBar.java ! src/share/classes/javax/swing/JToolTip.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/KeyStroke.java ! src/share/classes/javax/swing/OverlayLayout.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SizeRequirements.java ! src/share/classes/javax/swing/SizeSequence.java Changeset: d580e0bc85d9 Author: yan Date: 2013-09-24 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d580e0bc85d9 8025117: [cleanup] Eliminate doclint errors in javax/swing/text classes Reviewed-by: alexsch ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/RowFilter.java ! src/share/classes/javax/swing/plaf/TextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/text/AttributeSet.java ! src/share/classes/javax/swing/text/BadLocationException.java ! src/share/classes/javax/swing/text/BoxView.java ! src/share/classes/javax/swing/text/Caret.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/CompositeView.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/Document.java ! src/share/classes/javax/swing/text/DocumentFilter.java ! src/share/classes/javax/swing/text/EditorKit.java ! src/share/classes/javax/swing/text/FieldView.java ! src/share/classes/javax/swing/text/FlowView.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/Highlighter.java ! src/share/classes/javax/swing/text/IconView.java ! src/share/classes/javax/swing/text/NavigationFilter.java ! src/share/classes/javax/swing/text/ParagraphView.java ! src/share/classes/javax/swing/text/PasswordView.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/PlainView.java ! src/share/classes/javax/swing/text/Position.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/StyledDocument.java ! src/share/classes/javax/swing/text/StyledEditorKit.java ! src/share/classes/javax/swing/text/TabExpander.java ! src/share/classes/javax/swing/text/TabableView.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/BlockView.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java Changeset: 58178aec7e81 Author: kshefov Date: 2013-09-24 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/58178aec7e81 7124320: [TEST_BUG] [macosx] JComboBox doesn't change selection on mouse over Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JComboBox/6236162/bug6236162.java Changeset: f500844c2253 Author: kshefov Date: 2013-09-24 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f500844c2253 7133154: [TEST_BUG] [macosx] closed/javax/swing/JInternalFrame/4251301/bug4251301.java fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4251301/bug4251301.java Changeset: 967557d5b90a Author: kshefov Date: 2013-09-24 18:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/967557d5b90a 7133146: [macosx] closed/javax/swing/JInternalFrame/4193219/IconCoord fails on MacOS Reviewed-by: alexsch, serb Contributed-by: vera.akulova at oracle.com + test/javax/swing/JInternalFrame/4193219/IconCoord.java Changeset: 3982dd1210ba Author: kshefov Date: 2013-09-24 18:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3982dd1210ba 8015599: [TEST_BUG] [macosx] Test closed/javax/swing/Popup/TaskbarPositionTest.java fails since JDK 8 b75 on MacOSX Reviewed-by: alexsch, serb + test/javax/swing/Popup/TaskbarPositionTest.java Changeset: 2ed1584d62c5 Author: leonidr Date: 2013-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2ed1584d62c5 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily Reviewed-by: anthony, serb ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java Changeset: a284da808700 Author: malenkov Date: 2013-09-25 14:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a284da808700 8023310: Thread contention in the method Beans.IsDesignTime() Reviewed-by: art, sfriberg ! src/share/classes/java/beans/ThreadGroupContext.java ! src/share/classes/java/beans/WeakIdentityMap.java Changeset: 10e66428ddb0 Author: alexsch Date: 2013-09-25 16:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/10e66428ddb0 8007155: [macosx] Disabled panel takes mouse input in JLayeredPane Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/LWCursorManager.java ! src/share/classes/java/awt/Container.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/GlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/windows/classes/sun/awt/windows/WGlobalCursorManager.java ! src/windows/native/sun/windows/awt_Container.cpp ! src/windows/native/sun/windows/awt_Container.h ! src/windows/native/sun/windows/awt_Cursor.cpp + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.html + test/java/awt/Cursor/CursorOverlappedPanelsTest/CursorOverlappedPanelsTest.java Changeset: 7cad8ef127a9 Author: pchelko Date: 2013-09-25 16:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7cad8ef127a9 8024987: Copy/paste regression since JDK8 b86 Reviewed-by: serb, anthony ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java Changeset: cff4f079fa3f Author: kshefov Date: 2013-09-25 16:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cff4f079fa3f 8004032: [TEST_BUG] [macosx] There is no effect when double clicking on the Icon, after right clicking on the Icon and the Icon disappear Reviewed-by: anthony, serb + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.html + test/java/awt/TrayIcon/ShowAfterDisposeTest/ShowAfterDisposeTest.java Changeset: 681ac9f9c452 Author: alexsch Date: 2013-09-25 17:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/681ac9f9c452 8025070: [javadoc] fix some javadoc errors in javax/swing/plaf/synth Reviewed-by: serb, alexsch Contributed-by: Alexander Stepanov ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthCheckBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthFormattedTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuLayout.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPainter.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPasswordFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRadioButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToggleButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 2f8803ebd98c Author: yan Date: 2013-09-25 17:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2f8803ebd98c 8025085: [javadoc] some errors in javax/swing Reviewed-by: alexsch Contributed-by: Dmitry Zinkevich ! src/share/classes/javax/swing/JButton.java ! src/share/classes/javax/swing/JCheckBox.java ! src/share/classes/javax/swing/JCheckBoxMenuItem.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JToggleButton.java ! src/share/classes/javax/swing/SpinnerDateModel.java ! src/share/classes/javax/swing/SpinnerListModel.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UnsupportedLookAndFeelException.java ! src/share/classes/javax/swing/ViewportLayout.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicBorders.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopIconUI.java ! src/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicIconFactory.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicProgressBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarSeparatorUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DefaultMenuLayout.java ! src/share/classes/javax/swing/plaf/metal/MetalBorders.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLabelUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/metal/MetalPopupMenuSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSeparatorUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolTipUI.java ! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ImageView.java ! src/share/classes/javax/swing/text/html/InlineView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/ContentModel.java ! src/share/classes/javax/swing/text/html/parser/DocumentParser.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/tree/AbstractLayoutCache.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeCellRenderer.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/TreeCellRenderer.java ! src/share/classes/javax/swing/tree/TreeModel.java ! src/share/classes/javax/swing/undo/UndoManager.java Changeset: c40ed21f2939 Author: alexsch Date: 2013-09-25 17:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c40ed21f2939 7083457: Incomplete specification for javax/swing/text/DefaultCaret.html#setVisible(boolean) Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/text/DefaultCaret.java + test/javax/swing/text/DefaultCaret/7083457/bug7083457.java Changeset: 09fb25645717 Author: ptbrunet Date: 2013-09-26 10:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/09fb25645717 8025160: Recent Java Accessibility Bridge push has make failures Reviewed-by: tbell, erikj ! make/bridge/AccessBridgeJava/Makefile ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 0270e9b0891b Author: yan Date: 2013-09-26 16:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0270e9b0891b 8025218: [javadoc] some errors in java/awt classes Reviewed-by: yan Contributed-by: Dmitry Zinkevich ! src/share/classes/java/awt/AWTKeyStroke.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Event.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/GridBagLayout.java ! src/share/classes/java/awt/GridLayout.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/ScrollPaneAdjustable.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/java/awt/event/MouseMotionListener.java Changeset: 3b22833f2695 Author: lana Date: 2013-09-26 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b22833f2695 Merge - src/macosx/classes/sun/lwawt/SelectionClearListener.java - src/macosx/classes/sun/lwawt/macosx/CMouseInfoPeer.java Changeset: 8708569b5524 Author: sjiang Date: 2013-09-18 08:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8708569b5524 8023954: MBean*Info.equals: throw NPE Reviewed-by: dfuchs, dholmes ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanFeatureInfo.java ! src/share/classes/javax/management/MBeanNotificationInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java ! src/share/classes/javax/management/MBeanParameterInfo.java + test/javax/management/MBeanInfo/MBeanInfoEqualsNPETest.java Changeset: ee8b292ee568 Author: weijun Date: 2013-09-18 18:22 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ee8b292ee568 8012615: Realm.getRealmsList returns realms list in wrong Reviewed-by: valeriep, xuelei ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! test/sun/security/krb5/ParseCAPaths.java ! test/sun/security/krb5/krb5-capaths.conf Changeset: e92635d6834c Author: alanb Date: 2013-09-18 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e92635d6834c 8024883: (se) SelectableChannel.register throws NPE if fd >= 64k (lnx) Reviewed-by: alanb, coffeys Contributed-by: nmaurer at redhat.com, alan.bateman at oracle.com ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/SelectorLimit.java Changeset: 07d73060e0da Author: weijun Date: 2013-09-18 21:37 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/07d73060e0da 8011402: Move blacklisting certificate logic from hard code to data Reviewed-by: erikj, mullan ! make/java/security/Makefile ! makefiles/CopyFiles.gmk ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/sun/security/util/UntrustedCertificates.java ! src/share/classes/sun/security/x509/X509CertImpl.java + src/share/lib/security/BlacklistedCertsConverter.java + src/share/lib/security/blacklisted.certs + src/share/lib/security/blacklisted.certs.pem + test/lib/security/CheckBlacklistedCerts.java Changeset: b3a506a30fda Author: ewang Date: 2013-09-18 15:13 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b3a506a30fda 8015762: TEST_BUG: java/nio/channels/DatagramChannel/AdaptDatagramSocket.java failing intermittently [win] Reviewed-by: chegar, alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java Changeset: 22e9f0067b5a Author: kizune Date: 2013-09-19 17:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/22e9f0067b5a 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/sun/launcher/LauncherHelper.java + test/tools/launcher/8017248/ClassA??.java + test/tools/launcher/8017248/test.sh Changeset: 7557062d2dd2 Author: plevart Date: 2013-09-19 16:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7557062d2dd2 8011940: java.lang.Class.getAnnotations() always enters synchronized method Reviewed-by: jfranck, chegar, psandoz, shade ! src/share/classes/java/lang/Class.java + test/java/lang/annotation/AnnotationsInheritanceOrderRedefinitionTest.java Changeset: 278873b2b3f8 Author: sherman Date: 2013-09-19 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/278873b2b3f8 8023113: tools/jar/ChangeDir.java fails if /tmp/a exists Summary: updated the test case Reviewed-by: alanb ! test/tools/jar/ChangeDir.java Changeset: f36714707c38 Author: psandoz Date: 2013-09-18 10:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f36714707c38 8025002: "".codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException Reviewed-by: henryjen, alanb ! src/share/classes/java/lang/CharSequence.java ! test/java/lang/CharSequence/DefaultTest.java Changeset: 0ef7ddef9de0 Author: psandoz Date: 2013-09-19 20:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0ef7ddef9de0 8024405: Spliterators.spliterator should support CONCURRENT characteristic Reviewed-by: martin ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/Spliterators.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 58fd427b454d Author: sla Date: 2013-09-20 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/58fd427b454d 8024985: com/sun/jdi/StepTest.java failed since jdk8b107 Reviewed-by: dcubed ! test/com/sun/jdi/ExceptionEvents.java ! test/com/sun/jdi/FilterNoMatch.java ! test/com/sun/jdi/JDIScaffold.java ! test/com/sun/jdi/PopAndStepTest.java ! test/com/sun/jdi/RepStep.java ! test/com/sun/jdi/TestScaffold.java Changeset: 6a1c70e191d4 Author: sla Date: 2013-09-20 10:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6a1c70e191d4 8024416: TESTBUG: com/sun/jdi/MethodEntryExitEvents.java: method entry count mismatch Reviewed-by: dcubed ! test/com/sun/jdi/MethodEntryExitEvents.java Changeset: afe857b13b62 Author: kizune Date: 2013-09-20 17:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/afe857b13b62 8025076: Fix for JDK-8017248 breaks jprt submission for non-unicode locales Reviewed-by: naoto, ksrini - test/tools/launcher/8017248/ClassA??.java - test/tools/launcher/8017248/test.sh + test/tools/launcher/DiacriticTest.java Changeset: 94cc251d0c45 Author: sla Date: 2013-09-20 16:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/94cc251d0c45 7200277: [parfait] potential buffer overflow in npt/utf.c Reviewed-by: dsamersoff, dcubed ! src/share/npt/utf.c Changeset: 7913855ff66c Author: psandoz Date: 2013-09-20 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7913855ff66c 8024253: ThreadLocal random can use SecureRandom for the initial seed Reviewed-by: psandoz, chegar, alanb Contributed-by: Doug Lea
, Peter Levart , Guy Steele ! src/share/classes/java/util/SplittableRandom.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java Changeset: 2552cd270350 Author: bpb Date: 2013-09-20 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2552cd270350 8024331: j.u.Map.computeIfPresent() default/nondefault implementations don't throw NPE if the remappingFunction is null and the key is absent Summary: Explicitly check for null remappingFunction parameter. Reviewed-by: mduigou, forax, psandoz Contributed-by: Brian Burkhalter ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Map.java ! test/java/util/Map/Defaults.java Changeset: c30dc8e7744e Author: psandoz Date: 2013-09-20 17:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c30dc8e7744e 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/PatternStreamTest.java - test/java/util/regex/PatternTest.java Changeset: 56d247821694 Author: alanb Date: 2013-09-23 04:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/56d247821694 8023130: (process) ProcessBuilder#inheritIO does not work on Windows Reviewed-by: alanb, martin Contributed-by: ivan.gerasimov at oracle.com ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.java + test/java/lang/ProcessBuilder/InheritIO/InheritIO.sh Changeset: a3b17b91127d Author: lana Date: 2013-09-20 19:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a3b17b91127d Merge Changeset: f1b251affc6a Author: lana Date: 2013-09-22 20:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f1b251affc6a Merge Changeset: b606775fd1a3 Author: stefank Date: 2013-08-29 11:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b606775fd1a3 8014659: NPG: performance counters for compressed klass space Reviewed-by: jmasa, sla Contributed-by: erik.helin at oracle.com ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcCapacityOutput1.awk ! test/sun/tools/jstat/gcCauseOutput1.awk ! test/sun/tools/jstat/gcMetaCapacityOutput1.awk ! test/sun/tools/jstat/gcOldOutput1.awk ! test/sun/tools/jstat/gcOutput1.awk ! test/sun/tools/jstat/lineCounts1.awk ! test/sun/tools/jstat/lineCounts2.awk ! test/sun/tools/jstat/lineCounts3.awk ! test/sun/tools/jstat/lineCounts4.awk ! test/sun/tools/jstat/timeStamp1.awk ! test/sun/tools/jstatd/jstatGcutilOutput1.awk Changeset: 76619d71a7c5 Author: dfuchs Date: 2013-09-25 09:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/76619d71a7c5 8025140: TEST_BUG: java/util/logging/Logger/getGlobal tests fail due to timeout Summary: Arbitrary timeouts in the tests @run lines where too agressive for some configurations. The tests will now run with default timeout. Reviewed-by: alanb, mchung ! test/java/util/logging/Logger/getGlobal/TestGetGlobal.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalByName.java ! test/java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java Changeset: 2b928330970a Author: mfang Date: 2013-09-24 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2b928330970a 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/macosx/classes/com/apple/laf/resources/aqua_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties + src/share/classes/com/sun/java/util/jar/pack/DriverResource_ja.java + src/share/classes/com/sun/java/util/jar/pack/DriverResource_zh_CN.java ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/security/tools/jarsigner/Resources_ja.java ! src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_de.java ! src/share/classes/sun/security/tools/keytool/Resources_es.java ! src/share/classes/sun/security/tools/keytool/Resources_fr.java ! src/share/classes/sun/security/tools/keytool/Resources_it.java ! src/share/classes/sun/security/tools/keytool/Resources_ja.java ! src/share/classes/sun/security/tools/keytool/Resources_ko.java ! src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/keytool/Resources_sv.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_es.java ! src/share/classes/sun/security/tools/policytool/Resources_fr.java ! src/share/classes/sun/security/tools/policytool/Resources_it.java ! src/share/classes/sun/security/tools/policytool/Resources_ja.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java ! src/share/classes/sun/security/tools/policytool/Resources_sv.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java ! src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties Changeset: 9765801f209f Author: mfang Date: 2013-09-24 14:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9765801f209f Merge - test/java/util/regex/PatternTest.java Changeset: d16a53d1762f Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d16a53d1762f Merge Changeset: 8f27030686a6 Author: bchristi Date: 2013-09-26 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8f27030686a6 8025173: HashMap.put() replacing an existing key can trigger a resize() Summary: Ensure that HashMap is not resized if we're just replacing a value Reviewed-by: alanb, martin ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/ReplaceExisting.java Changeset: 8edd604bf960 Author: lana Date: 2013-09-26 17:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8edd604bf960 Merge - test/java/util/regex/PatternTest.java Changeset: 9684ed81cd21 Author: ksrini Date: 2013-09-27 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9684ed81cd21 8020552: [launcher] changes to support removal of Solaris 32-bit distribution 8023495: [infra] create 64-bit solaris bits with symlinks Reviewed-by: ihse, tbell, dholmes, darcy, alanb, erikj, sla, martin ! makefiles/Images.gmk ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/solaris/bin/java_md_solinux.c ! test/com/sun/jdi/BadHandshakeTest.java ! test/com/sun/jdi/DoubleAgentTest.java ! test/com/sun/jdi/ExclusiveBind.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/RunToExit.java - test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/SimpleLaunchingConnector.java ! test/demo/jvmti/DemoRun.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/Makefile + test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/tools/jhat/HatRun.java ! test/tools/launcher/6842838/Test6842838.sh ! test/tools/launcher/ChangeDataModel.java ! test/tools/launcher/ExecutionEnvironment.java ! test/tools/launcher/FXLauncherTest.java ! test/tools/launcher/RunpathTest.java ! test/tools/launcher/Test7029048.java ! test/tools/launcher/TestHelper.java Changeset: 2c7c7b813eb3 Author: katleman Date: 2013-10-01 12:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2c7c7b813eb3 Merge - test/com/sun/jdi/Solaris32AndSolaris64Test.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so Changeset: dd43ccb3bac9 Author: ihse Date: 2013-10-01 11:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dd43ccb3bac9 8019219: Fix typo in jdk/makefiles "default" targets Reviewed-by: erikj ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk Changeset: 54e099776f08 Author: erikj Date: 2013-10-02 15:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/54e099776f08 Merge Changeset: 9f57d2774603 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9f57d2774603 Added tag jdk8-b110 for changeset 54e099776f08 ! .hgtags From john.coomes at oracle.com Thu Oct 3 12:05:11 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 19:05:11 +0000 Subject: hg: hsx/hotspot-comp/langtools: 35 new changesets Message-ID: <20131003190729.CC19C62D1E@hg.openjdk.java.net> Changeset: fdfbc5f0c4ed Author: jjg Date: 2013-09-17 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fdfbc5f0c4ed 8024538: -Xdoclint + -Xprefer:source + incremental compilation == FAIL Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java + test/tools/javac/doclint/implicitSource/ImplicitSourceTest.java + test/tools/javac/doclint/implicitSource/Other.java Changeset: ac6ec071c2b2 Author: alundblad Date: 2013-09-18 14:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ac6ec071c2b2 8024127: javac, Code_attribute.exception_table_langth should be Code_attribute.exception_table_length Summary: exception_table_langth renamed to exception_table_length Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! test/tools/javac/T7093325.java ! test/tools/javac/T8024039/NoDeadCodeGenerationOnTrySmtTest.java ! test/tools/javac/multicatch/Pos05.java Changeset: a2a5ad0853ed Author: bpatel Date: 2013-09-18 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a2a5ad0853ed 8015249: javadoc fails to document static final fields in annotation types Reviewed-by: jjg + src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeFieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! test/com/sun/javadoc/testAnnotationTypes/TestAnnotationTypes.java + test/com/sun/javadoc/testAnnotationTypes/pkg/AnnotationTypeField.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java Changeset: 8df12c315ea3 Author: bpatel Date: 2013-09-18 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8df12c315ea3 8024096: some javadoc tests may contain false positive results Reviewed-by: jjg ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java ! test/com/sun/javadoc/testEncoding/EncodeTest.java ! test/com/sun/javadoc/testEncoding/TestEncoding.java ! test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 36e342dd57e2 Author: kizune Date: 2013-09-19 17:05 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/36e342dd57e2 8017248: Compiler Diacritics Issue Reviewed-by: naoto ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java Changeset: 8d1c48de706d Author: jlahoda Date: 2013-09-19 17:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8d1c48de706d 8022567: Javac Should Generate Warnings For Raw Array Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/warnings/6747671/T6747671.java ! test/tools/javac/warnings/6747671/T6747671.out Changeset: 0cfd5baa7154 Author: ohrstrom Date: 2013-09-19 08:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0cfd5baa7154 8024609: sjavac assertion fails during call to BuildState.collectArtifacts Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/BuildState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! src/share/classes/com/sun/tools/sjavac/server/JavacServer.java Changeset: 2375ce96e80d Author: vromero Date: 2013-09-19 20:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2375ce96e80d 8024437: Inferring the exception thrown: sometimes fails to compile Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/T8024437/ExceptionInferenceFromClassFileTest.java Changeset: 9a75bdb249a2 Author: jjg Date: 2013-09-19 19:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9a75bdb249a2 8025110: TreeCopier does not correctly copy LabeledStatementTree Reviewed-by: jjg Contributed-by: Werner Dietl ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java Changeset: 41599b57d262 Author: jlahoda Date: 2013-09-20 16:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/41599b57d262 8023835: TreeMaker.QualIdent() too leafy Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/tree/MakeQualIdent.java + test/tools/javac/tree/ScopeTest.java Changeset: 571f8ebc2d51 Author: vromero Date: 2013-09-22 12:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/571f8ebc2d51 8024696: Missing null check in bound method reference capture Reviewed-by: jjg, briangoetz ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! test/tools/javac/lambda/8023558/T8023558a.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceNullCheckTest.java Changeset: 86dd72166267 Author: lana Date: 2013-09-20 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/86dd72166267 Merge Changeset: 20b72bae83d7 Author: lana Date: 2013-09-22 20:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/20b72bae83d7 Merge Changeset: 1fe358ea75ff Author: alundblad Date: 2013-09-23 10:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1fe358ea75ff 8024988: javac, LVT test harness should generate tests .class files in the scratch folder Summary: Set the CLASS_OUTPUT location to the scratch directory. Changed the argument to checkClassFile accordingly. Reviewed-by: jjg, vromero ! test/tools/javac/flow/LVTHarness.java Changeset: 5f915a0c9615 Author: alundblad Date: 2013-09-23 10:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5f915a0c9615 6386236: Please rename com.sun.tools.javac.util.ListBuffer.lb() Summary: Static factory method ListBuffer.lb removed. Replaced by constructor calls. Reviewed-by: jfranck, jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/ListBuffer.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java ! test/tools/javac/scope/7017664/CompoundScopeTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 809a50f24d6f Author: kizune Date: 2013-09-23 17:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/809a50f24d6f 7154966: CRs found to be in Fixed state with no test and no noreg- keyword. Reviewed-by: ksrini + test/tools/javac/T7090499.java + test/tools/javac/T7090499.out + test/tools/javac/T7120463.java + test/tools/javac/T7120463.out + test/tools/javac/T7126754.java Changeset: 64e79d38bd07 Author: kizune Date: 2013-09-23 18:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/64e79d38bd07 4881267: improve diagnostic for "instanceof T" for type parameter T Reviewed-by: vromero, jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T4881267.java + test/tools/javac/T4881267.out Changeset: 09301757bb32 Author: emc Date: 2013-09-23 15:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/09301757bb32 6499673: Assertion check for TypeVariable.getUpperBound() fails. Summary: Fix TypeVariable.getUpperBound to return results as specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/processing/model/type/BoundsTest.java + test/tools/javac/processing/model/type/IntersectionPropertiesTest.java Changeset: 96dcb66e6b0a Author: jjg Date: 2013-09-24 10:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/96dcb66e6b0a 8025050: Doclint doesn't recognize tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/InlineTagsTest.java Changeset: 503338f16d2b Author: jjg Date: 2013-09-24 10:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/503338f16d2b 8025246: [doclint] doclint is showing error on anchor already defined when it's not Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/anchorTests/p/Test.java + test/tools/doclint/anchorTests/p/Test.javac.out + test/tools/doclint/anchorTests/p/Test.out + test/tools/doclint/anchorTests/p/package-info.java + test/tools/doclint/anchorTests/p/package-info.javac.out + test/tools/doclint/anchorTests/p/package-info.out Changeset: 6a05a713450d Author: jjg Date: 2013-09-24 11:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6a05a713450d 8025272: doclint needs to check for valid usage of @value tag Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/ValueTest.java + test/tools/doclint/ValueTest.out Changeset: 3ae62331a56f Author: jjg Date: 2013-09-24 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3ae62331a56f 8002154: [doclint] doclint should check for issues which are errors in javadoc Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/ReferenceTest.java ! test/tools/doclint/ReferenceTest.out Changeset: 184c0d6698c3 Author: bpatel Date: 2013-09-24 16:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/184c0d6698c3 8016328: Regression : Javadoc i18n regression caused by fix for 8012375 Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testUseOption/TestUseOption.java Changeset: 5043e7056be8 Author: jjg Date: 2013-09-25 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5043e7056be8 8025407: TypeAnnotations does not use Context Reviewed-by: jfranck ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java Changeset: 1332a99572c5 Author: mfang Date: 2013-09-24 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/1332a99572c5 8025215: jdk8 l10n resource file translation update 4 Reviewed-by: naoto, yhuang ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_ja.properties ! src/share/classes/com/sun/tools/doclint/resources/doclint_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties ! src/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties Changeset: daa3bfb82e58 Author: mfang Date: 2013-09-24 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/daa3bfb82e58 Merge Changeset: 6b702ace3e45 Author: mfang Date: 2013-09-25 07:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6b702ace3e45 Merge Changeset: 68292726000e Author: mfang Date: 2013-09-25 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/68292726000e Merge Changeset: 3d61984b077c Author: jjg Date: 2013-09-25 14:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/3d61984b077c 8025412: Add legal header and comments to test/tools/doclint/tidy/util/Main.java Reviewed-by: bpatel ! test/tools/doclint/tidy/util/Main.java ! test/tools/doclint/tidy/util/tidy.sh Changeset: 9e884d3ddb0b Author: bpatel Date: 2013-09-25 22:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9e884d3ddb0b 8004825: javadoc crash DocletAbortException Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testValueTag/pkg1/Class1.java Changeset: 9235ae08a449 Author: jlahoda Date: 2013-09-26 20:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9235ae08a449 8025491: Javac regression test tools/javac/T8003967/DetectMutableStaticFields.java failing Summary: Making HtmlTree.NONENCODING_CHARS final Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java Changeset: 13eba2e322e6 Author: vromero Date: 2013-09-26 19:06 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/13eba2e322e6 8025139: javac patch for using bootstrap compiler for debugging is not working properly Reviewed-by: jjg ! make/netbeans/langtools/build.xml ! make/tools/anttasks/SelectToolTask.java Changeset: 17653c4c22ec Author: sogoel Date: 2013-09-26 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/17653c4c22ec 8011738: Write test to check for bootstrap attributes for lambda expressions in class file Reviewed-by: mcimadamore + test/tools/javac/lambda/ByteCodeTest.java Changeset: 41541097533a Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/41541097533a Merge Changeset: af6244ba81b6 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/af6244ba81b6 Added tag jdk8-b110 for changeset 41541097533a ! .hgtags From john.coomes at oracle.com Thu Oct 3 12:08:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 03 Oct 2013 19:08:06 +0000 Subject: hg: hsx/hotspot-comp/nashorn: 21 new changesets Message-ID: <20131003190837.A648462D1F@hg.openjdk.java.net> Changeset: 1971c2d770ae Author: sundar Date: 2013-09-18 13:06 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/1971c2d770ae 8024972: for (LeftHandSideExpression in Expression) crashes the compiler Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8024972.js + test/script/basic/JDK-8024972.js.EXPECTED Changeset: a62172fe5bae Author: sundar Date: 2013-09-18 16:36 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/a62172fe5bae 8024973: Using a different ScriptContext with a CompiledScript results in ScriptException Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Source.java ! test/script/trusted/JDK-8008305.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: f954d3f4d192 Author: sundar Date: 2013-09-19 13:34 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/f954d3f4d192 8025048: true as case label results in ClassCastException Reviewed-by: lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-8025048-2.js + test/script/basic/JDK-8025048.js Changeset: 740b1133f1b6 Author: hannesw Date: 2013-09-19 15:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/740b1133f1b6 8023154: compileAllTests fails with: 2 tests failed to compile Reviewed-by: sundar, jlaskey ! make/build-benchmark.xml ! make/build.xml ! make/project.properties Changeset: 821b0b610861 Author: sundar Date: 2013-09-19 21:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/821b0b610861 8025080: Object literal getter, setter function with number format property name results in ClassFormatError Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8025080.js + test/script/basic/JDK-8025080.js.EXPECTED ! test/script/basic/parser/objectLitExpr.js.EXPECTED Changeset: 18d64bc4937d Author: sundar Date: 2013-09-19 23:48 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/18d64bc4937d 8025090: 'while' statement with 'test' using var before being declared in body results in VerifyError Reviewed-by: jlaskey ! src/jdk/nashorn/internal/ir/WhileNode.java + test/script/basic/JDK-8025090.js Changeset: 195be8ca5c97 Author: sundar Date: 2013-09-20 12:56 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/195be8ca5c97 8025111: undefined or null 'with' expression in empty with block should throw TypeError Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8025111.js Changeset: fa491b75d3e4 Author: hannesw Date: 2013-09-20 12:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/fa491b75d3e4 8022587: ClassCache is not optimal and leaks Source instances Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java Changeset: 13210550765c Author: lana Date: 2013-09-20 19:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/13210550765c Merge Changeset: 279f47b353f3 Author: sundar Date: 2013-09-20 20:55 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/279f47b353f3 8025147: Trailing comma is not allowed in JSONArray and JSONObject Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8025147.js + test/script/basic/JDK-8025147.js.EXPECTED Changeset: 16b6db9f7225 Author: sundar Date: 2013-09-20 22:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/16b6db9f7225 8025149: JSON.stringify does not handle 'space' argument as per the spec. Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/NativeJSON.java + test/script/basic/JDK-8025149.js + test/script/basic/JDK-8025149.js.EXPECTED Changeset: b8d9a63578e2 Author: hannesw Date: 2013-09-21 10:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/b8d9a63578e2 8025163: Date methods should not return -0 Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeDate.java + test/script/basic/JDK-8025163.js + test/script/basic/JDK-8025163.js.EXPECTED Changeset: 8f6304373671 Author: sundar Date: 2013-09-23 14:20 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/8f6304373671 Merge Changeset: c5475f5d4647 Author: sundar Date: 2013-09-24 20:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/c5475f5d4647 8025312: parseInt should convert 'radix' argument to ToInt32 even if empty string is parsed Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + test/script/basic/JDK-8025312.js + test/script/basic/JDK-8025312.js.EXPECTED Changeset: 754ecd62bde3 Author: sundar Date: 2013-09-25 08:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/754ecd62bde3 8025325: parseFloat does not handle '.' in exponent part Reviewed-by: hannesw ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + test/script/basic/JDK-8025325.js + test/script/basic/JDK-8025325.js.EXPECTED Changeset: 2f8f99e5ed76 Author: hannesw Date: 2013-09-25 16:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/2f8f99e5ed76 8025434: RegExp lastIndex can exceed int range Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025434.js Changeset: 712f5e31739b Author: hannesw Date: 2013-09-26 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/712f5e31739b 8025197: String replace method fails with regexp /$/gi Reviewed-by: sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025197.js + test/script/basic/JDK-8025197.js.EXPECTED Changeset: 23958764f866 Author: hannesw Date: 2013-09-26 11:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/23958764f866 8025486: RegExp constructor arguments are not evaluated in right order Reviewed-by: sundar ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8025486.js + test/script/basic/JDK-8025486.js.EXPECTED Changeset: f1f027907a69 Author: sundar Date: 2013-09-26 16:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/f1f027907a69 Merge Changeset: d49a8c2173f5 Author: lana Date: 2013-09-26 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/d49a8c2173f5 Merge Changeset: 75fd3486e584 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/75fd3486e584 Added tag jdk8-b110 for changeset d49a8c2173f5 ! .hgtags From vladimir.kozlov at oracle.com Thu Oct 3 12:27:50 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 12:27:50 -0700 Subject: RFR(XS): 8024008: Nashorn V8 (Crypto) benchmark crashes with small CodeCache size In-Reply-To: <524DB4B6.7040201@oracle.com> References: <522DD453.4010809@oracle.com> <522E09C4.1070700@oracle.com> <522EC44F.2060005@oracle.com> <522F1612.4030606@oracle.com> <522FA629.10509@oracle.com> <524DB4B6.7040201@oracle.com> Message-ID: <524DC536.5030602@oracle.com> Albert, I don't see connection between not generating wrapper (which is fine, it is only needed for hot calls to native method) and wrong return address when calling i2c adapter (failed message). Can you find what return address is? It could be a different problem (or not) from what this bug about. Several things can go bad when codecache is full. Also attached to bug report hs_err files shows different crushes. Was you able to reproduce it with fastdebug VM? Switch off -XX:-CheckCompressedOops to get the same code generation as with product 64-bit VM. And switch off -XX:-VerifyDependencies to speed testing (10x, this test is very expensive). Also can you try to run with latest VM version which has fixes to produce more info for call stack in hs_err. To have only next lines is not useful: C 0x0000000648baace0 [error occurred during error reporting (printing native stack), id 0xb] Thanks, Vladimir On 10/3/13 11:17 AM, Albert Noll wrote: > Hi, > > I think I found the reason for the crash. Please forget the previous > suggestions. > > See the following webrev: > > Problem: > http://cr.openjdk.java.net/~anoll/8024008/webrev.02/ > > If the code cache gets full, this code in compileBroker.cpp is not > executed. > > 1318 (void) > AdapterHandlerLibrary::create_native_wrapper(method, compile_id); > > As a result, we get the following error "i2c adapter must return to > an interpreter frame" > if the JVM is called with "-XX:+UnlockDiagnosticVMOptions > -XX:+VerifyAdapterCalls" > > I do not yet fully understand why that's the case, so please if you > know let me know. > > Solution: > Move the code cache is full-check after line 1318. > > Many thanks, > Albert > > > Am 11.09.2013 01:07, schrieb Vladimir Kozlov: >> Albert, >> >> I would suggest to run as many tests as possible to verify correctness >> of changes because this code is very important. >> >> Thanks, >> Vladimir >> >> On 9/10/13 5:52 AM, Albert Noll wrote: >>> Hi, >>> >>> the current version causes a serious performance regression. >>> I have to figure out what's wrong. >>> >>> Best, >>> Albert >>> >>> On 10.09.2013 09:03, Albert Noll wrote: >>>> Hi Vladimir, >>>> >>>> thanks for looking at this. I checked all call sites of >>>> 'make_not_entrant()' and 'make_zombie()'. I do not see any problems. >>>> The worst thing that can happen is that an nmethod for which the call >>>> returns fals gets removed later than expected. >>>> >>>> I updated the comment and did some minor code refactoring. >>>> >>>> Also I think that it is worth considering to backport this change, >>>> since the bug can appear any time >>>> the code cache fills up. If that bug appears, it is extremely hard to >>>> reproduce and debug. >>>> >>>> Here is the updated webrev. >>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.01/ >>>> >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> >>>> On 09.09.2013 19:47, Vladimir Kozlov wrote: >>>>> Several places in sources do not check returned result of >>>>> make_not_entrant_or_zombie(). And they may assume that method marked >>>>> as non-entrant, for example, because before we returned 'false' only >>>>> when an other thread already changed the state to one we need. >>>>> >>>>> Can you check all call sites to make sure they work correctly with >>>>> this change? >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/9/13 6:59 AM, Albert Noll wrote: >>>>>> Hi, >>>>>> >>>>>> thanks for reviewing this patch. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8024008 >>>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.00/ >>>>>> >>>>>> >>>>>> Many thanks in advance, >>>>>> Albert >>>>>> >>>>>> Problem: >>>>>> The state of nmethods that are currently locked by the VM must not >>>>>> change. >>>>>> Some operations such as setting ICs (e.g., >>>>>> SharedRuntime::resolve_sub_helper()) >>>>>> rely on this fact. 'nmethod::make_not_entrant_or_zombie does not >>>>>> make this >>>>>> check. >>>>>> >>>>>> Solution: >>>>>> Do method state unchanged of nmethod is locked by the VM. >>>>>> >>>>>> Testing: Run Octane benchmarks on top of Nashorn with small code >>>>>> cache size (16m). >>>>>> >>>> >>> > From christian.thalinger at oracle.com Thu Oct 3 12:38:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 12:38:02 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> Message-ID: src/share/vm/c1/c1_GraphBuilder.cpp: + Values* GraphBuilder::args_list_for_profiling(ciMethod* target, int& start, bool may_have_receiver) { + Values* GraphBuilder::collect_args_for_profiling(Values* args, ciMethod* target, bool may_have_receiver) { Both methods take a target as argument but never use it. src/share/vm/c1/c1_Instruction.hpp: + bool arg_needs_null_check(int i) const { + if (i >= 0 && i < (int)sizeof(_nonnull_state) * BitsPerByte) { This means that arguments after the 32nd position always need a null check. Can you add a comment to these methods explaining that as we do for Java API methods? Maybe use Doxygen style. + virtual void input_values_do(ValueVisitor* f) { + if (_recv != NULL) f->visit(&_recv); + for (int i = 0; i < nb_profiled_args(); i++) f->visit(_obj_args->adr_at(i)); + } Can you use some line breaks and curly braces here too? src/share/vm/c1/c1_LIR.hpp: + intptr_t _current_klass; // what the profiling currently reports Why is the type intptr_t? Can't we use a more specific type here? Hmm, you tag klass pointers: + static intptr_t with_status(intptr_t k, intptr_t in) { + return k | (in & status_bits); + } src/share/vm/c1/c1_LIRGenerator.cpp: + static ciKlass* sig_next_klass(ciSignature* sig, ciKlass*& first_sig_k, int& j) { We should move this method into ciSignature. Or better ciSignatureStream. src/share/vm/ci/ciMethodData.hpp: + // If the compiler finds a profiled type is known statically for "type that is known" src/share/vm/oops/methodData.cpp: + SignatureStream ss(inv.signature()); + int args_count = 0; + for ( ; !ss.at_return_type(); ss.next()) { + if (ss.is_object() || ss.is_array()) { + args_count++; + if (args_count >= max) { + break; + } + } + } This would be a nice utility method in SignatureStream (sans the >= max part). Maybe reference_parameter_count(). Oh, btw., arrays are treated as objects: bool SignatureStream::is_object() const { return _type == T_OBJECT || _type == T_ARRAY; } It could be reused here right away: + #ifdef ASSERT + int count = 0; + for (SignatureStream ss(inv.signature()); !ss.at_return_type(); ss.next()) { + if (ss.is_object() || ss.is_array()) { + count++; + Bytecodes::Code bc = m->code_at(bci); + assert(Bytecodes::is_invoke(m->java_code_at(bci)), "arguments only make sense at call"); + + return bc == Bytecodes::_invokedynamic || bc == Bytecodes::_invokehandle; Instead of this code you can use Bytecode_invoke and then query inv.is_invokedynamic() || inv.is_invokehandle(). + int MethodData::profile_arguments_flag() { + return TypeProfile % 10; + } Why 10? + bool MethodData::profile_arguments() { + return profile_arguments_flag() > 0 && profile_arguments_flag() <= 2; + } + + bool MethodData::profile_arguments_jsr292_only() { + return profile_arguments_flag() == 1; + } + + bool MethodData::profile_all_arguments() { + return profile_arguments_flag() == 2; + } I think you should have an enum for all of these constants. src/share/vm/oops/methodData.hpp: + void set_int_at_unchecked(int index, int value) { + data()->set_cell_at(index, (intptr_t) value); + } This method is not used. + return _args.set_type(i, TypeEntries::with_status((intptr_t)k, current)); Maybe you should add another with_status method that takes a Klass* and do the cast there. src/share/vm/runtime/globals.hpp: + develop(bool, PrintMethodDataStats, false, \ Most of these flags are named *Statistics. + product_pd(uintx, TypeProfile, \ + "Type profiling of arguments at call:" \ + "0->off ; 1->js292 only; 2->all methods") \ + product(intx, TypeProfileArgsLimit, 2, \ + "max number of call arguments to consider for type profiling") \ + \ Empty line missing between. On Oct 2, 2013, at 10:02 AM, Roland Westrelin wrote: > Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. > > http://cr.openjdk.java.net/~roland/8023657/webrev.01/ > > The output of -XX:+PrintMethodData is: > > 6 invokevirtual 2 > 0 bci: 6 VirtualCallData count(0) entries(1) > 'TestProfiling'(4746 1.00) > argument types 0: stack(1) 'TestProfiling$C' > 1: stack(2) unknown (null seen) > > Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. > Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. > Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. > > Roland. > > From vladimir.kozlov at oracle.com Thu Oct 3 13:35:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 13:35:19 -0700 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DB8EF.7030908@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> Message-ID: <524DD507.60408@oracle.com> Good. Thanks, Vladimir On 10/3/13 11:35 AM, Vladimir Ivanov wrote: > Thanks for catching that. > > How about that? > http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 > > Best regards, > Vladimir Ivanov > > On 10/3/13 10:24 PM, Vladimir Kozlov wrote: >> You need to add cast (int)(j - lowval) since argument type is int. Some >> C++ compiler will complain if no cast. >> >> Thanks, >> Vladimir K >> >> On 10/3/13 11:04 AM, Vladimir Ivanov wrote: >>> Vladimir, >>> >>> I like the idea to convert j to int64. It looks much cleaner now. >>> >>> Here's updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >>>> I don't think it is right. You need to have check before the loop's >>>> body >>>> execution. >>>> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >>>> I think we should use int64 type for these expressions as in other >>>> lines >>>> of this method. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>> >>>>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>>>> overflows and j <= r->hi() succeeds again (leading to >>>>> extra iterations and infinite loop in the product). >>>>> >>>>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>>>> stop iterating, if necessary. >>>>> >>>>> Also, did a small cleanup: eliminated unused parameter from >>>>> SwitchRange::print. >>>>> >>>>> Testing: failing test case. >>>>> >>>>> Reviewed-by: iveresov, ? >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From christian.thalinger at oracle.com Thu Oct 3 13:41:11 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 13:41:11 -0700 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DB8EF.7030908@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> Message-ID: Looks good. On Oct 3, 2013, at 11:35 AM, Vladimir Ivanov wrote: > Thanks for catching that. > > How about that? > http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 > > Best regards, > Vladimir Ivanov > > On 10/3/13 10:24 PM, Vladimir Kozlov wrote: >> You need to add cast (int)(j - lowval) since argument type is int. Some >> C++ compiler will complain if no cast. >> >> Thanks, >> Vladimir K >> >> On 10/3/13 11:04 AM, Vladimir Ivanov wrote: >>> Vladimir, >>> >>> I like the idea to convert j to int64. It looks much cleaner now. >>> >>> Here's updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >>>> I don't think it is right. You need to have check before the loop's body >>>> execution. >>>> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >>>> I think we should use int64 type for these expressions as in other lines >>>> of this method. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>> >>>>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>>>> overflows and j <= r->hi() succeeds again (leading to >>>>> extra iterations and infinite loop in the product). >>>>> >>>>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>>>> stop iterating, if necessary. >>>>> >>>>> Also, did a small cleanup: eliminated unused parameter from >>>>> SwitchRange::print. >>>>> >>>>> Testing: failing test case. >>>>> >>>>> Reviewed-by: iveresov, ? >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From christian.thalinger at oracle.com Thu Oct 3 13:41:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 13:41:52 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> Message-ID: <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> On Oct 3, 2013, at 11:28 AM, Roland Westrelin wrote: >>> You should probably use: >>> caller_argument0->uncast() == callee_argument0->uncast() >> >> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? > > With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. Fair enough. I've added the uncast() calls: http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ > > Roland. From christian.thalinger at oracle.com Thu Oct 3 13:51:51 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 13:51:51 -0700 Subject: RFR (S): 8024943: ciReplay: fails to dump replay data during safepointing In-Reply-To: <524D7F86.4080003@oracle.com> References: <524C7ECF.80004@oracle.com> <524D7F86.4080003@oracle.com> Message-ID: Looks good. On Oct 3, 2013, at 7:30 AM, Vladimir Ivanov wrote: > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8024943/webrev.01/ > > Verified that replay data is dumped correctly in the following combinations: > - thread_in_native > - thread_in_vm > - thread_in_vm + Compile_lock > > Regarding ciEnv in invalid state (leaving aside the cases when the instance is corrupted), the only case when it is possible is when the VM crashed in ~ciEnv(). Don't know whether fixing it is worth the effort - in both cases we don't get valid replay data file. > > Best regards, > Vladimir Ivanov > > On 10/3/13 12:57 AM, John Rose wrote: >> On Oct 2, 2013, at 1:15 PM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8024943/webrev.00/ >>> 15 lines changed: 11 ins; 0 del; 4 mod >>> >>> In some situations VM fails to dump compiler replay file (produces empty replay_pid%p.log). The reason is that ciEnv::dump_replay_data tries to do thread state transition to VM unconditionally and acquire Compile_lock. It doesn't always work in context of VM error reporter. >>> >>> The fix is to provide new method specifically for VM error reporter (ciEnv::dump_replay_data_unsafe) which doesn't perform aforementioned actions. >>> >>> Testing: manual (checked that a valid dump is produced for a crash during safepointing). >> >> Is is possible that you've pushed a bug further into the CI code? I would like you to take a look at this (if you haven't already) and either make code adjustments or describe current assumptions in comments, for the next maintainer. >> >> What I mean about "pushed a bug" is that the CI is (generally speaking) sensitive to the thread state. (Note the GUARDED_VM_ENTRY macros everywhere.) The dump_replay_data function calls a bunch of dump_replay_data subroutines on lots of little data structures in the CI. Are any of them also sensitive to thread state? If so, perhaps you want to have your >> >> Also, the ciEnv::current() call returns something to the error reporter, and if that something is non-null, it is assumed to be (up to high probability, of course) a valid ciEnv structure. Are there any places where the ciEnv guy is in an inconsistent state but still published by ciEnv::current()? Probably not, but it might be worth a comment noting the appropriate conditions. My specific worry is that the call to remove_symbols in ~ciEnv might leave a space where the dumper would not see valid state. >> >> This crash dumper stuff cannot be nailed down 100%, of course, but this might be a good moment to make sure we've at least stomped on it a bit. >> >> Reviewed, pending resolution of the above. >> >> Thanks, >> ? John >> From vladimir.x.ivanov at oracle.com Thu Oct 3 13:57:42 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 00:57:42 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> Message-ID: <524DDA46.2030705@oracle.com> Thank you, Chris. Best regards, Vladimir Ivanov On 10/4/13 12:41 AM, Christian Thalinger wrote: > Looks good. > > On Oct 3, 2013, at 11:35 AM, Vladimir Ivanov wrote: > >> Thanks for catching that. >> >> How about that? >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 >> >> Best regards, >> Vladimir Ivanov >> >> On 10/3/13 10:24 PM, Vladimir Kozlov wrote: >>> You need to add cast (int)(j - lowval) since argument type is int. Some >>> C++ compiler will complain if no cast. >>> >>> Thanks, >>> Vladimir K >>> >>> On 10/3/13 11:04 AM, Vladimir Ivanov wrote: >>>> Vladimir, >>>> >>>> I like the idea to convert j to int64. It looks much cleaner now. >>>> >>>> Here's updated webrev: >>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >>>>> I don't think it is right. You need to have check before the loop's body >>>>> execution. >>>>> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >>>>> I think we should use int64 type for these expressions as in other lines >>>>> of this method. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>>> >>>>>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>>>>> overflows and j <= r->hi() succeeds again (leading to >>>>>> extra iterations and infinite loop in the product). >>>>>> >>>>>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>>>>> stop iterating, if necessary. >>>>>> >>>>>> Also, did a small cleanup: eliminated unused parameter from >>>>>> SwitchRange::print. >>>>>> >>>>>> Testing: failing test case. >>>>>> >>>>>> Reviewed-by: iveresov, ? >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Thu Oct 3 13:57:56 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 00:57:56 +0400 Subject: RFR (S): 8024943: ciReplay: fails to dump replay data during safepointing In-Reply-To: References: <524C7ECF.80004@oracle.com> <524D7F86.4080003@oracle.com> Message-ID: <524DDA54.2070506@oracle.com> Thank you, Chris. Best regards, Vladimir Ivanov On 10/4/13 12:51 AM, Christian Thalinger wrote: > Looks good. > > On Oct 3, 2013, at 7:30 AM, Vladimir Ivanov wrote: > >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8024943/webrev.01/ >> >> Verified that replay data is dumped correctly in the following combinations: >> - thread_in_native >> - thread_in_vm >> - thread_in_vm + Compile_lock >> >> Regarding ciEnv in invalid state (leaving aside the cases when the instance is corrupted), the only case when it is possible is when the VM crashed in ~ciEnv(). Don't know whether fixing it is worth the effort - in both cases we don't get valid replay data file. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/3/13 12:57 AM, John Rose wrote: >>> On Oct 2, 2013, at 1:15 PM, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8024943/webrev.00/ >>>> 15 lines changed: 11 ins; 0 del; 4 mod >>>> >>>> In some situations VM fails to dump compiler replay file (produces empty replay_pid%p.log). The reason is that ciEnv::dump_replay_data tries to do thread state transition to VM unconditionally and acquire Compile_lock. It doesn't always work in context of VM error reporter. >>>> >>>> The fix is to provide new method specifically for VM error reporter (ciEnv::dump_replay_data_unsafe) which doesn't perform aforementioned actions. >>>> >>>> Testing: manual (checked that a valid dump is produced for a crash during safepointing). >>> >>> Is is possible that you've pushed a bug further into the CI code? I would like you to take a look at this (if you haven't already) and either make code adjustments or describe current assumptions in comments, for the next maintainer. >>> >>> What I mean about "pushed a bug" is that the CI is (generally speaking) sensitive to the thread state. (Note the GUARDED_VM_ENTRY macros everywhere.) The dump_replay_data function calls a bunch of dump_replay_data subroutines on lots of little data structures in the CI. Are any of them also sensitive to thread state? If so, perhaps you want to have your >>> >>> Also, the ciEnv::current() call returns something to the error reporter, and if that something is non-null, it is assumed to be (up to high probability, of course) a valid ciEnv structure. Are there any places where the ciEnv guy is in an inconsistent state but still published by ciEnv::current()? Probably not, but it might be worth a comment noting the appropriate conditions. My specific worry is that the call to remove_symbols in ~ciEnv might leave a space where the dumper would not see valid state. >>> >>> This crash dumper stuff cannot be nailed down 100%, of course, but this might be a good moment to make sure we've at least stomped on it a bit. >>> >>> Reviewed, pending resolution of the above. >>> >>> Thanks, >>> ? John >>> > From vladimir.x.ivanov at oracle.com Thu Oct 3 13:58:20 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 00:58:20 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DD507.60408@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> <524DD507.60408@oracle.com> Message-ID: <524DDA6C.2060507@oracle.com> Thank you, Vladimir. Best regards, Vladimir Ivanov On 10/4/13 12:35 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/3/13 11:35 AM, Vladimir Ivanov wrote: >> Thanks for catching that. >> >> How about that? >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 >> >> Best regards, >> Vladimir Ivanov >> >> On 10/3/13 10:24 PM, Vladimir Kozlov wrote: >>> You need to add cast (int)(j - lowval) since argument type is int. Some >>> C++ compiler will complain if no cast. >>> >>> Thanks, >>> Vladimir K >>> >>> On 10/3/13 11:04 AM, Vladimir Ivanov wrote: >>>> Vladimir, >>>> >>>> I like the idea to convert j to int64. It looks much cleaner now. >>>> >>>> Here's updated webrev: >>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >>>>> I don't think it is right. You need to have check before the loop's >>>>> body >>>>> execution. >>>>> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >>>>> I think we should use int64 type for these expressions as in other >>>>> lines >>>>> of this method. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>>> >>>>>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>>>>> overflows and j <= r->hi() succeeds again (leading to >>>>>> extra iterations and infinite loop in the product). >>>>>> >>>>>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>>>>> stop iterating, if necessary. >>>>>> >>>>>> Also, did a small cleanup: eliminated unused parameter from >>>>>> SwitchRange::print. >>>>>> >>>>>> Testing: failing test case. >>>>>> >>>>>> Reviewed-by: iveresov, ? >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov From christian.thalinger at oracle.com Thu Oct 3 14:20:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 14:20:20 -0700 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <524D6A32.5080003@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> <524BEBC2.4030202@oracle.com> <524C4EA8.1020109@oracle.com> <524D6A32.5080003@oracle.com> Message-ID: <10357B70-D0DD-4057-99B3-620883784430@oracle.com> src/share/vm/code/codeBlob.cpp: + // The parameter 'true' indicates a critical memory allocation. + // This means that CodeCacheMinimumFreeSpace is used, if necessary + blob = new (size, true) AdapterBlob(size, cb); For things like this it is helpful to define a const with a meaningful name, e.g.: const bool is_critical = true; +bool AbstractCompiler::should_perform_shutdown() { + MutexLocker only_one(CompileThread_lock); Maybe add a comment similar to what you explained here why the lock is there. src/share/vm/compiler/compileBroker.cpp: + lock()->wait(!Mutex::_no_safepoint_check_flag, 5*1000); We need a comment here why it is 5. + // Switch back to VM state to to compiler initialization Typo: "to to" + if ((comp->is_c1()) && (thread->get_buffer_blob() == NULL)) { We don't need parenthesis around comp->is_c1() check. Otherwise this looks good. On Oct 3, 2013, at 5:59 AM, Albert Noll wrote: > Hi Vladimir, > > thanks for looking at the patch. See comments inline. > Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.04/ > > On 02.10.2013 18:49, Vladimir Kozlov wrote: >> Albert, >> >> In disable_compilation_forever() the comment does not correspond to code. >> > I removed the comment. >> In should_perform_shutdown() the _compiler_state could be changed before other threads reach "if (comp->is_state_failed())" check in init_compiler_runtime(). > True. I added a function should_exit(), which returns true if the state if failed, or shutting down. >> Yes, decrementing with lock is fine, you are right. >> >> The message should say why we do shutdown (no space to initialize compiler runtime): >> warning("Shutting down compiler >> > The warning messages are now: > - "Shutting down compiler %s (no space to run compiler)" or > - "Initialization of %s thread failed (no space to run compiler thread)" > if a C1 compiler thread fails to allocate memory. >> Please, explain what references: >> >> + // We could delete compiler runtimes also. However, >> + // there are references to the compiler runtime(s) >> + // (e.g., by nmethods) which then fail. This can be >> > Done. >> It would be nice to have regression test for this. > I added a regression test, which checks that compiler threads exit, if there is not sufficient free code cache > to init all threads. Testing a failing initialization of C2 is tricky, since a C2 initialization failure depends on the > scheduling of the compiler threads. > > Thanks again, > Albert >> >> Thanks, >> Vladimir >> >> On 10/2/13 2:47 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks again for the feedback. I tested the patch as you proposed, i.e., make sure that >>> the patch works if the C1 and/or C2 compiler fails to initialize. I tested with up to 256 compiler >>> threads. >>> >>> To make sure that all compiler threads exit, I had to do additional modifications in CompileQueue::get() >>> and the caller of this method. With these changes, one can also exit compiler threads if -XX:-UseCodeCacheFlushing >>> is set, which is also contained in this webrev. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ >>> >>> See more comments inline: >>> >>> >>> On 01.10.2013 18:17, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> In general it looks good. Please, test it extensively with Tiered with codecache size enough to initialize one >>>> compiler but not an other to verify your code. >>>> >>> Done. >>>> I think you need to swap lock and decrement otherwise it will deadlock: >>>> >>>> +bool AbstractCompiler::should_perform_shutdown() { >>>> + MutexLocker only_one(CompileThread_lock); >>>> + _num_compiler_threads--; >>>> >>> I simplified this function. In fact it is fine if the last thread (i.e., if _num_compiler_threads == 0) >>> does the shutdown. The while() statement is really not necessary. However, we have to decrement >>> _num_compiler_threads when we hold the lock. Otherwise we are not guaranteed to reach 0 >>> (-- is not atomic). >>> >>>> comp->set_shut_down(); and delete _compilers[0]; should be done by one thread I think. >>> Done. >>> >>>> >>>> Small note, you accidentally removed nl in c2compiler.cpp: >>>> >>>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. >>>> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. >>>> >>>> >>> Fixed. >>> >>> Thanks again, >>> Albert >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/1/13 12:27 AM, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks again for looking at the patch. See comments inline: >>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>>>> >>>>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> There is small window between check and set_state where state can became initialized or still be uninitialized: >>>>>> + if (!is_initialized()) { >>>>>> + set_state(failed); >>>>>> >>>>>> so you may hit assert in set_state(). >>>>>> >>>>>> I think you need to call set_state(failed) only when C1 runtime is initialized after lock: >>>>>> >>>>>> if (should_perform_init()) { >>>>>> if (buffer_blob == NULL) { >>>>>> set_state(failed); >>>>>> } else { >>>>>> init_c1_runtime(); >>>>>> set_state(initialized); >>>>>> } >>>>>> } >>>>>> >>>>> You are right. I adapted the patch according to your suggestion. >>>>> >>>>>> In this case it will match behavior for C2 which means that you need to shutdown compilation since you was not able to >>>>>> initialize compilation runtime. It will require more code to do proper shutdown not just exiting thread (free >>>>>> compilation queues, resetting flags). An it will be more complicated for Tiered case (I think we can use simple >>>>>> approach to shutdown all compilations even if only one Compiler is not initialized since it is rare case). >>>>>> >>>>> I added code to shut-down compilation. If compiler runtime initialization fails, a flag is set which disables >>>>> compilation forever. In the current >>>>> version, all compilers are disabled if C1 and/or C2 runtime initialization fails (also in case of tiered compilation). I >>>>> think this solution is fine for >>>>> now, since a compiler runtime initialization failure should not happen in practice. If it ever turns out to be a >>>>> problem, i.e., it is required that we >>>>> we use one compiler if the other compiler failed to initialize, I suggest we fix this in another bug. The current bug >>>>> appears only due to an artificial >>>>> setting of the code cache size. >>>>> >>>>> Compiler shut-down is performed by one thread. This thread waits until all compiler threads have exited to compiler >>>>> loop. The thread then >>>>> deletes all tasks from the compile queue, deletes the compiler objects, and sets the objects to NULL. >>>>> >>>>> Please let me know if you think this solution is fine, or if there are other things that need to be considered. >>>>> The current version passed jprt. >>>>> >>>>> Many thanks again, >>>>> Albert >>>>> >>>>>> If C1 runtime was initialized but we was not able to allocate buffer for some threads your current code in >>>>>> compileBroker.cpp will handle such case. So you don't need to set state to 'failed'. >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> thanks for looking at the patch. >>>>>>> Here is the new webrev: >>>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>>>> >>>>>>> >>>>>>> See comments inline: >>>>>>> >>>>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>>>> Thank you, Albert >>>>>>>> >>>>>>>> I would suggest to do TieredStartAtLevel changes separately, it is not >>>>>>>> related to this bug. >>>>>>>> >>>>>>> Done. >>>>>>>> Second, how we can guard the initialization with a field >>>>>>>> (_compiler_state and original _is_initialized) which is not static? >>>>>>>> >>>>>>>> You don't need separate local do_init in C*_Compiler.cpp since it is >>>>>>>> used only once: >>>>>>>> >>>>>>> Done. >>>>>>>> + if (should_perform_init()) { >>>>>>>> >>>>>>>> abstractCompiler.cpp: >>>>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>>>> check_prelock_state() called from Monitor::lock(): >>>>>>>> >>>>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>>>> || rank() == Mutex::special, "wrong thread state for using >>>>>>>> locks"); >>>>>>>> >>>>>>>> Compiler threads are Java threads, so you should be in VM state when >>>>>>>> lock. How you did not hit this assert? >>>>>>>> >>>>>>> The state transition from native to VM (and ResetNoHandleMark) is now in >>>>>>> compileBroker.cpp:1543. >>>>>>>> >>>>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>>>> >>>>>>>> + // This method returns true for the first compiler thread that >>>>>>>> reaches that methos. >>>>>>>> >>>>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>>>> object created for each compilation): >>>>>>>> >>>>>>>> + // This thread will initialize the compiler object. >>>>>>>> >>>>>>>> Swap lines (and use 'runtime' in the comment): >>>>>>>> >>>>>>>> ! bool is_initialized () { return _compiler_state == >>>>>>>> initialized; } >>>>>>>> ! // Get/set state of compiler objects >>>>>>>> >>>>>>>> >>>>>>>> c2compiler.cpp: >>>>>>>> >>>>>>>> C2Compiler:: is not needed: >>>>>>>> >>>>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>>>> >>>>>>>> >>>>>>> Fixed the issues above. >>>>>>>> Should we exit Compiler thread which failed local buffer allocation >>>>>>>> instead parking? Why keep resources allocated for it? >>>>>>>> >>>>>>> You are right, there is no reason the keep these threads around. >>>>>>> Compiler threads wo are not initialized correctly >>>>>>> now exit the VM. >>>>>>> >>>>>>> The patch is currently in west queue. >>>>>>> >>>>>>> Many thanks again, >>>>>>> Albert >>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I have a review for this patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem: C1/C2 compiler initialization can fail if there is not enough >>>>>>>>> memory in the code cache to generate all stubs. >>>>>>>>> This problem occurs only with a small code cache size. >>>>>>>>> >>>>>>>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>>>> was not initialized correctly. >>>>>>>>> >>>>>>>>> Testing: jprt, test case, benchmarks >>>>>>>>> >>>>>>>>> This patch also contains a refactored version of compiler object/thread >>>>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>>>> initialized prior entering the main compiler loop. In the old version, >>>>>>>>> the check if the compiler/thread is initialized was >>>>>>>>> done in the main compiler loop (and hence before every compilation). >>>>>>>>> >>>>>>>>> To continue execution with a limited code cache size, the code types >>>>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>>>> be 'critical' allocations in the code cache, i.e., they must use space >>>>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>>>> >>>>>>>>> In addition I removed some unued code. >>>>>>>>> >>>>>>>>> Many thanks in advance for reviewing. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/6494b0bd/attachment-0001.html From vladimir.x.ivanov at oracle.com Thu Oct 3 14:30:25 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 01:30:25 +0400 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Message-ID: <524DE1F1.1020300@oracle.com> http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 2 lines changed: 0 ins; 0 del; 2 mod make_log_name function does the following expansion: %p => pid{pid}. Fix VM log file name, removing unnecessary "pid" from the pattern. FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile & ErrorFile. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8025905 From vladimir.kozlov at oracle.com Thu Oct 3 14:31:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 14:31:35 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> Message-ID: <524DE237.9020409@oracle.com> Christian, Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars outside loop since they are invariants. Also both branches have to check (j->method() == callee_method). It could be checked first: if (j->method() == callee_method) { if (callee_is_compiled_lambda_form) { // Since compiled lambda forms are heavily reused we allow recursive inlining. // If it is truly a recursion (using the same "receiver") we limit inlining // otherwise we can easily blow the compiler stack. Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); if (caller_argument0 == callee_argument0) { inline_level++; } } else { inline_level++; } } Thanks, Vladimir On 10/3/13 1:41 PM, Christian Thalinger wrote: > > On Oct 3, 2013, at 11:28 AM, Roland Westrelin wrote: > >>>> You should probably use: >>>> caller_argument0->uncast() == callee_argument0->uncast() >>> >>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? >> >> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. > > Fair enough. I've added the uncast() calls: > > http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ > >> >> Roland. > From vladimir.kozlov at oracle.com Thu Oct 3 14:35:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 14:35:48 -0700 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) In-Reply-To: <524DE1F1.1020300@oracle.com> References: <524DE1F1.1020300@oracle.com> Message-ID: <524DE334.7000006@oracle.com> Good. Vladimir On 10/3/13 2:30 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 > 2 lines changed: 0 ins; 0 del; 2 mod > > make_log_name function does the following expansion: %p => pid{pid}. > Fix VM log file name, removing unnecessary "pid" from the pattern. > > FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile & > ErrorFile. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8025905 From azeem.jiva at oracle.com Thu Oct 3 14:42:18 2013 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 3 Oct 2013 14:42:18 -0700 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) In-Reply-To: <524DE1F1.1020300@oracle.com> References: <524DE1F1.1020300@oracle.com> Message-ID: <78563D77-A1C5-44DB-97C6-E3C01ECEEFFE@oracle.com> Did you test this on different OSes? Just to make sure that %p does return 'pid#' rather than just '#'. Windows would be a good one to test at the minimum. Otherwise it's fine (not a real reviewer). -- Azeem Jiva @javawithjiva On Oct 3, 2013, at 2:30 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 > 2 lines changed: 0 ins; 0 del; 2 mod > > make_log_name function does the following expansion: %p => pid{pid}. > Fix VM log file name, removing unnecessary "pid" from the pattern. > > FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile & ErrorFile. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8025905 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/1b0769a9/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/1b0769a9/signature.asc From christian.thalinger at oracle.com Thu Oct 3 14:47:12 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 14:47:12 -0700 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) In-Reply-To: <524DE1F1.1020300@oracle.com> References: <524DE1F1.1020300@oracle.com> Message-ID: Looks good. On Oct 3, 2013, at 2:30 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 > 2 lines changed: 0 ins; 0 del; 2 mod > > make_log_name function does the following expansion: %p => pid{pid}. > Fix VM log file name, removing unnecessary "pid" from the pattern. > > FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile & ErrorFile. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8025905 From vladimir.x.ivanov at oracle.com Thu Oct 3 14:48:14 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 01:48:14 +0400 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) In-Reply-To: <78563D77-A1C5-44DB-97C6-E3C01ECEEFFE@oracle.com> References: <524DE1F1.1020300@oracle.com> <78563D77-A1C5-44DB-97C6-E3C01ECEEFFE@oracle.com> Message-ID: <524DE61E.8090903@oracle.com> Azeem, No, I haven't tested it on Windows. Expansion takes place in make_log_name_internal (ostream.cpp): if (pid_pos >= 0) { jio_snprintf(pid_text, sizeof(pid_text), "pid%u", pid); buffer_length += strlen(pid_text); } So, the behavior is consistent across supported platforms. Best regards, Vladimir Ivanov On 10/4/13 1:42 AM, Azeem Jiva wrote: > Did you test this on different OSes? Just to make sure that %p does > return 'pid#' rather than just '#'. Windows would be a good one to test > at the minimum. Otherwise it's fine (not a real reviewer). > > > -- > Azeem Jiva > @javawithjiva > > On Oct 3, 2013, at 2:30 PM, Vladimir Ivanov > > wrote: > >> http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 >> 2 lines changed: 0 ins; 0 del; 2 mod >> >> make_log_name function does the following expansion: %p => pid{pid}. >> Fix VM log file name, removing unnecessary "pid" from the pattern. >> >> FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile >> & ErrorFile. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8025905 > From vladimir.x.ivanov at oracle.com Thu Oct 3 14:48:47 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 01:48:47 +0400 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) In-Reply-To: References: <524DE1F1.1020300@oracle.com> Message-ID: <524DE63F.3010706@oracle.com> Thank you, Chris. Best regards, Vladimir Ivanov On 10/4/13 1:47 AM, Christian Thalinger wrote: > Looks good. > > On Oct 3, 2013, at 2:30 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 >> 2 lines changed: 0 ins; 0 del; 2 mod >> >> make_log_name function does the following expansion: %p => pid{pid}. >> Fix VM log file name, removing unnecessary "pid" from the pattern. >> >> FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile & ErrorFile. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8025905 > From christian.thalinger at oracle.com Thu Oct 3 14:56:01 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 14:56:01 -0700 Subject: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8 In-Reply-To: <3C5298FB-3149-4FED-920F-4254D07C3956@oracle.com> References: <19F72018-5EB4-4AAA-AC66-E18F0F9ECB13@me.com> <35668DC3-A121-4DCC-8A74-06CADEE6B8F9@oracle.com> <3C5298FB-3149-4FED-920F-4254D07C3956@oracle.com> Message-ID: On Oct 2, 2013, at 2:31 PM, John Rose wrote: > On Oct 2, 2013, at 12:14 PM, Christian Thalinger wrote: > >> src/share/classes/java/lang/invoke/MethodHandles.java: >> >> + * lookup expression >> >> Apparently the name attribute is obsolete for in HTML5: >> >> http://dev.w3.org/html5/markup/a.html >> >> I think they want you to use . >> >> + *

>> + * >> + * Discussion of private access: >> >> Same here. >> >> + *

Security manager interactions

>> >> And here. > > Wow; I don't know where HTML5 fits in the javadoc story. That might be nice to upgrade, but I'm not gonna go first: Sure :-) It was only a note. > -------- > fgrep ' Hi Vladimir, > > thanks for looking at the patch. See comments inline. > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8023014/webrev.04/ > > > On 02.10.2013 18:49, Vladimir Kozlov wrote: >> Albert, >> >> In disable_compilation_forever() the comment does not correspond to code. >> > I removed the comment. >> In should_perform_shutdown() the _compiler_state could be changed >> before other threads reach "if (comp->is_state_failed())" check in >> init_compiler_runtime(). > True. I added a function should_exit(), which returns true if the state > if failed, or shutting down. >> Yes, decrementing with lock is fine, you are right. >> >> The message should say why we do shutdown (no space to initialize >> compiler runtime): >> warning("Shutting down compiler >> > The warning messages are now: > - "Shutting down compiler %s (no space to run compiler)" or > - "Initialization of %s thread failed (no space to run compiler thread)" > if a C1 compiler thread fails to allocate memory. >> Please, explain what references: >> >> + // We could delete compiler runtimes also. However, >> + // there are references to the compiler runtime(s) >> + // (e.g., by nmethods) which then fail. This can be >> > Done. >> It would be nice to have regression test for this. > I added a regression test, which checks that compiler threads exit, if > there is not sufficient free code cache > to init all threads. Testing a failing initialization of C2 is tricky, > since a C2 initialization failure depends on the > scheduling of the compiler threads. > > Thanks again, > Albert >> >> Thanks, >> Vladimir >> >> On 10/2/13 2:47 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks again for the feedback. I tested the patch as you proposed, >>> i.e., make sure that >>> the patch works if the C1 and/or C2 compiler fails to initialize. I >>> tested with up to 256 compiler >>> threads. >>> >>> To make sure that all compiler threads exit, I had to do additional >>> modifications in CompileQueue::get() >>> and the caller of this method. With these changes, one can also exit >>> compiler threads if -XX:-UseCodeCacheFlushing >>> is set, which is also contained in this webrev. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ >>> >>> >>> See more comments inline: >>> >>> >>> On 01.10.2013 18:17, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> In general it looks good. Please, test it extensively with Tiered >>>> with codecache size enough to initialize one >>>> compiler but not an other to verify your code. >>>> >>> Done. >>>> I think you need to swap lock and decrement otherwise it will deadlock: >>>> >>>> +bool AbstractCompiler::should_perform_shutdown() { >>>> + MutexLocker only_one(CompileThread_lock); >>>> + _num_compiler_threads--; >>>> >>> I simplified this function. In fact it is fine if the last thread >>> (i.e., if _num_compiler_threads == 0) >>> does the shutdown. The while() statement is really not necessary. >>> However, we have to decrement >>> _num_compiler_threads when we hold the lock. Otherwise we are not >>> guaranteed to reach 0 >>> (-- is not atomic). >>> >>>> comp->set_shut_down(); and delete _compilers[0]; should be done by >>>> one thread I think. >>> Done. >>> >>>> >>>> Small note, you accidentally removed nl in c2compiler.cpp: >>>> >>>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>> rights reserved. >>>> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>> rights reserved. >>>> >>>> >>> Fixed. >>> >>> Thanks again, >>> Albert >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/1/13 12:27 AM, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks again for looking at the patch. See comments inline: >>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>>>> >>>>> >>>>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> There is small window between check and set_state where state can >>>>>> became initialized or still be uninitialized: >>>>>> + if (!is_initialized()) { >>>>>> + set_state(failed); >>>>>> >>>>>> so you may hit assert in set_state(). >>>>>> >>>>>> I think you need to call set_state(failed) only when C1 runtime is >>>>>> initialized after lock: >>>>>> >>>>>> if (should_perform_init()) { >>>>>> if (buffer_blob == NULL) { >>>>>> set_state(failed); >>>>>> } else { >>>>>> init_c1_runtime(); >>>>>> set_state(initialized); >>>>>> } >>>>>> } >>>>>> >>>>> You are right. I adapted the patch according to your suggestion. >>>>> >>>>>> In this case it will match behavior for C2 which means that you >>>>>> need to shutdown compilation since you was not able to >>>>>> initialize compilation runtime. It will require more code to do >>>>>> proper shutdown not just exiting thread (free >>>>>> compilation queues, resetting flags). An it will be more >>>>>> complicated for Tiered case (I think we can use simple >>>>>> approach to shutdown all compilations even if only one Compiler is >>>>>> not initialized since it is rare case). >>>>>> >>>>> I added code to shut-down compilation. If compiler runtime >>>>> initialization fails, a flag is set which disables >>>>> compilation forever. In the current >>>>> version, all compilers are disabled if C1 and/or C2 runtime >>>>> initialization fails (also in case of tiered compilation). I >>>>> think this solution is fine for >>>>> now, since a compiler runtime initialization failure should not >>>>> happen in practice. If it ever turns out to be a >>>>> problem, i.e., it is required that we >>>>> we use one compiler if the other compiler failed to initialize, I >>>>> suggest we fix this in another bug. The current bug >>>>> appears only due to an artificial >>>>> setting of the code cache size. >>>>> >>>>> Compiler shut-down is performed by one thread. This thread waits >>>>> until all compiler threads have exited to compiler >>>>> loop. The thread then >>>>> deletes all tasks from the compile queue, deletes the compiler >>>>> objects, and sets the objects to NULL. >>>>> >>>>> Please let me know if you think this solution is fine, or if there >>>>> are other things that need to be considered. >>>>> The current version passed jprt. >>>>> >>>>> Many thanks again, >>>>> Albert >>>>> >>>>>> If C1 runtime was initialized but we was not able to allocate >>>>>> buffer for some threads your current code in >>>>>> compileBroker.cpp will handle such case. So you don't need to set >>>>>> state to 'failed'. >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> thanks for looking at the patch. >>>>>>> Here is the new webrev: >>>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>>>> >>>>>>> >>>>>>> See comments inline: >>>>>>> >>>>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>>>> Thank you, Albert >>>>>>>> >>>>>>>> I would suggest to do TieredStartAtLevel changes separately, it >>>>>>>> is not >>>>>>>> related to this bug. >>>>>>>> >>>>>>> Done. >>>>>>>> Second, how we can guard the initialization with a field >>>>>>>> (_compiler_state and original _is_initialized) which is not static? >>>>>>>> >>>>>>>> You don't need separate local do_init in C*_Compiler.cpp since >>>>>>>> it is >>>>>>>> used only once: >>>>>>>> >>>>>>> Done. >>>>>>>> + if (should_perform_init()) { >>>>>>>> >>>>>>>> abstractCompiler.cpp: >>>>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>>>> check_prelock_state() called from Monitor::lock(): >>>>>>>> >>>>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>>>> || rank() == Mutex::special, "wrong thread state for using >>>>>>>> locks"); >>>>>>>> >>>>>>>> Compiler threads are Java threads, so you should be in VM state >>>>>>>> when >>>>>>>> lock. How you did not hit this assert? >>>>>>>> >>>>>>> The state transition from native to VM (and ResetNoHandleMark) is >>>>>>> now in >>>>>>> compileBroker.cpp:1543. >>>>>>>> >>>>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>>>> >>>>>>>> + // This method returns true for the first compiler thread that >>>>>>>> reaches that methos. >>>>>>>> >>>>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>>>> object created for each compilation): >>>>>>>> >>>>>>>> + // This thread will initialize the compiler object. >>>>>>>> >>>>>>>> Swap lines (and use 'runtime' in the comment): >>>>>>>> >>>>>>>> ! bool is_initialized () { return _compiler_state == >>>>>>>> initialized; } >>>>>>>> ! // Get/set state of compiler objects >>>>>>>> >>>>>>>> >>>>>>>> c2compiler.cpp: >>>>>>>> >>>>>>>> C2Compiler:: is not needed: >>>>>>>> >>>>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>>>> >>>>>>>> >>>>>>> Fixed the issues above. >>>>>>>> Should we exit Compiler thread which failed local buffer allocation >>>>>>>> instead parking? Why keep resources allocated for it? >>>>>>>> >>>>>>> You are right, there is no reason the keep these threads around. >>>>>>> Compiler threads wo are not initialized correctly >>>>>>> now exit the VM. >>>>>>> >>>>>>> The patch is currently in west queue. >>>>>>> >>>>>>> Many thanks again, >>>>>>> Albert >>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I have a review for this patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem: C1/C2 compiler initialization can fail if there is not >>>>>>>>> enough >>>>>>>>> memory in the code cache to generate all stubs. >>>>>>>>> This problem occurs only with a small code cache size. >>>>>>>>> >>>>>>>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>>>> was not initialized correctly. >>>>>>>>> >>>>>>>>> Testing: jprt, test case, benchmarks >>>>>>>>> >>>>>>>>> This patch also contains a refactored version of compiler >>>>>>>>> object/thread >>>>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>>>> initialized prior entering the main compiler loop. In the old >>>>>>>>> version, >>>>>>>>> the check if the compiler/thread is initialized was >>>>>>>>> done in the main compiler loop (and hence before every >>>>>>>>> compilation). >>>>>>>>> >>>>>>>>> To continue execution with a limited code cache size, the code >>>>>>>>> types >>>>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>>>> be 'critical' allocations in the code cache, i.e., they must >>>>>>>>> use space >>>>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>>>> >>>>>>>>> In addition I removed some unued code. >>>>>>>>> >>>>>>>>> Many thanks in advance for reviewing. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>> >>>>> >>> > From christian.thalinger at oracle.com Thu Oct 3 15:11:10 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 15:11:10 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <524DE237.9020409@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> Message-ID: <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov wrote: > Christian, > > Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars outside loop since they are invariants. Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust compilers. > > Also both branches have to check (j->method() == callee_method). It could be checked first: > > if (j->method() == callee_method) { > if (callee_is_compiled_lambda_form) { > // Since compiled lambda forms are heavily reused we allow recursive inlining. > // If it is truly a recursion (using the same "receiver") we limit inlining > // otherwise we can easily blow the compiler stack. > Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); > if (caller_argument0 == callee_argument0) { > inline_level++; > } > } else { > inline_level++; > } > } Good point. http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ > > Thanks, > Vladimir > > On 10/3/13 1:41 PM, Christian Thalinger wrote: >> >> On Oct 3, 2013, at 11:28 AM, Roland Westrelin wrote: >> >>>>> You should probably use: >>>>> caller_argument0->uncast() == callee_argument0->uncast() >>>> >>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? >>> >>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. >> >> Fair enough. I've added the uncast() calls: >> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ >> >>> >>> Roland. >> From vladimir.x.ivanov at oracle.com Thu Oct 3 15:17:02 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 02:17:02 +0400 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) In-Reply-To: <524DE334.7000006@oracle.com> References: <524DE1F1.1020300@oracle.com> <524DE334.7000006@oracle.com> Message-ID: <524DECDE.9060903@oracle.com> Thank you, Vladimir. Best regards, Vladimir Ivanov On 10/4/13 1:35 AM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/3/13 2:30 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 >> 2 lines changed: 0 ins; 0 del; 2 mod >> >> make_log_name function does the following expansion: %p => pid{pid}. >> Fix VM log file name, removing unnecessary "pid" from the pattern. >> >> FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile & >> ErrorFile. >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8025905 From azeem.jiva at oracle.com Thu Oct 3 15:21:07 2013 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 3 Oct 2013 15:21:07 -0700 Subject: RFR (XXS): 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) In-Reply-To: <524DE61E.8090903@oracle.com> References: <524DE1F1.1020300@oracle.com> <78563D77-A1C5-44DB-97C6-E3C01ECEEFFE@oracle.com> <524DE61E.8090903@oracle.com> Message-ID: Ahh then never mind. Looks good. -- Azeem Jiva @javawithjiva On Oct 3, 2013, at 2:48 PM, Vladimir Ivanov wrote: > Azeem, > > No, I haven't tested it on Windows. > > Expansion takes place in make_log_name_internal (ostream.cpp): > if (pid_pos >= 0) { > jio_snprintf(pid_text, sizeof(pid_text), "pid%u", pid); > buffer_length += strlen(pid_text); > } > > So, the behavior is consistent across supported platforms. > > Best regards, > Vladimir Ivanov > > On 10/4/13 1:42 AM, Azeem Jiva wrote: >> Did you test this on different OSes? Just to make sure that %p does >> return 'pid#' rather than just '#'. Windows would be a good one to test >> at the minimum. Otherwise it's fine (not a real reviewer). >> >> >> -- >> Azeem Jiva >> @javawithjiva >> >> On Oct 3, 2013, at 2:30 PM, Vladimir Ivanov >> > wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8025849/webrev.00 >>> 2 lines changed: 0 ins; 0 del; 2 mod >>> >>> make_log_name function does the following expansion: %p => pid{pid}. >>> Fix VM log file name, removing unnecessary "pid" from the pattern. >>> >>> FYI, I filed JDK-8025905 to track discrepancy between "%p" in LogFile >>> & ErrorFile. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8025905 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/d43830b6/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/d43830b6/signature-0001.asc From vladimir.kozlov at oracle.com Thu Oct 3 15:29:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 15:29:21 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> Message-ID: <524DEFC1.4090306@oracle.com> On 10/3/13 3:11 PM, Christian Thalinger wrote: > > On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov wrote: > >> Christian, >> >> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars outside loop since they are invariants. > > Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust compilers. I don't trust compilers BECAUSE I am compiler guy and I know their problems :) If calls are not inlined (virtual or other reasons) they will not be moved from the loop. And you should know already that the best performance improvement come from changing sources and not from compilers :) I insist to move at least callee_argument0 outside the loop. Vladimir >> >> Also both branches have to check (j->method() == callee_method). It could be checked first: >> >> if (j->method() == callee_method) { >> if (callee_is_compiled_lambda_form) { >> // Since compiled lambda forms are heavily reused we allow recursive inlining. >> // If it is truly a recursion (using the same "receiver") we limit inlining >> // otherwise we can easily blow the compiler stack. >> Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); >> if (caller_argument0 == callee_argument0) { >> inline_level++; >> } >> } else { >> inline_level++; >> } >> } > > Good point. > > http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ > >> >> Thanks, >> Vladimir >> >> On 10/3/13 1:41 PM, Christian Thalinger wrote: >>> >>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin wrote: >>> >>>>>> You should probably use: >>>>>> caller_argument0->uncast() == callee_argument0->uncast() >>>>> >>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? >>>> >>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. >>> >>> Fair enough. I've added the uncast() calls: >>> >>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ >>> >>>> >>>> Roland. >>> > From vladimir.kozlov at oracle.com Thu Oct 3 16:15:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 16:15:47 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: References: Message-ID: <524DFAA3.1070303@oracle.com> Christian, Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? Thanks, Vladimir On 10/2/13 8:17 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8025566 > http://cr.openjdk.java.net/~twisti/8025566 > > 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method > Reviewed-by: > > The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. > > I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. > From christian.thalinger at oracle.com Thu Oct 3 16:50:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 16:50:14 -0700 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: References: Message-ID: Some general comments: Don't use T1, T2, ? to name the tiers because SPARC processors are named like this. It's confusing. Use tier 1, tier 2, ? instead. The compilation policies actually talk about tier levels... I was hoping that we can have a more loose definition of the code heaps. So we can easily add more. What this patch does is a good start but all the hardcoded values and fields need to go at a later point in time, in my opinion. src/share/vm/code/codeBlob.hpp: +// CodeBlob Types +// Used in the CodeCache to assign CodeBlobs to different CodeHeaps +enum CodeBlobType { + btMethodNoProfile = 0, // T1 and T4 methods (including native methods) + btMethodProfile = 1, // T2 and T3 methods with profile information + btNonMethod = 2 // Non-methods like Buffers, Adapters and Runtime Stubs +}; The bt prefix is already overloaded (e.g. BasicType). Generally speaking, I never liked the fact that enums don't have their name as scope. Maybe we can agree on doing something like this: struct CodeBlobType { enum Enum { NonMethod = 2 }; }; void foo() { int a = CodeBlobType::NonMethod; int b = (CodeBlobType::Enum) 1; } Or we move to C++11 :-) http://www.stroustrup.com/C++11FAQ.html#enum src/share/vm/code/codeCache.cpp: +#define FOR_ALL_HEAPS(index) for (int index = 0; index < _heaps->length(); ++index) I'm one of the people who started to hate macros (for various reasons). Although I see the point in defining these I'd rather go without them. Is there a way we can use STL vectors with our allocators? Or we could write our own iterator class which iterates either over GrowableArrays in general or the code heaps in particular. src/share/vm/memory/heap.hpp: + const char* getName() const { return _name; } This should either be get_name() or name(). Let's start the discussion and I'll do another review round later. On Oct 2, 2013, at 7:06 AM, Tobias Hartmann wrote: > Hi, > > please review the following change. > > bug: https://bugs.openjdk.java.net/browse/JDK-8015774 > webrev: http://cr.openjdk.java.net/~anoll/8015774/webrev.00/ > > This change implements support for multiple code heaps in the code cache. The interface of the code cache was changed accordingly and references from other components of the VM were adapted. This includes the indirect references from: > - the Serviceability Agent: vmStructs and the Java code cache interface (sun.jvm.hotspot.code.CodeCache) > - the dtrace ustack helper script (jhelper.d) > - the pstack support library libjvm_db.c > > Currently the code cache contains the following three code heaps each of which contains CodeBlobs of a specific type: > - Non-Profiled methods: nmethods that are not profiled, i.e., those compiled at tier 1 or 4 and native methods > - Profiled methods: nmethods that are profiled, i.e., those compiled at tier 2 or 3 > - Non-methods: Non-methods like Buffers, Adapters and Runtime Stubs > > By default, 2/3 of the ReservedCodeCacheSize is used for the non-profiled heap and 1/3 is used for the profiled heap. Experiments with a small code cache size have shown that this configuration performs best (see [1]). Sizes can be configured using the NonProfiledCodeHeapSize and ProfiledCodeHeapSize parameters. By now the non-method heap has a fixed size of 8mb. More tests have to be performed to determine reasonable default values for different build and runtime configurations. It would be also possible to add an additional heap for the CodeBlobs needed during VM startup (adapters, stubs, interpreter, ...) and use the non-method heap for non-method blobs allocated during runtime. > > The main benefit of this allocation is that functions operating on nmethods can now be optimized to only iterate over CodeBlobs on the nmethod heaps, avoiding a full scan of the code cache including the non-methods. Performance evaluation shows that this results in a great reduction of the sweeping time. Further it is now possible to extend the sweeper to selectively sweep nmethods of different compilation levels. Because it is more expensive to recompile a highly optimized method, it makes sense to first sweep those compiled at a lower level. Possible future optimizations may also include multithreaded sweeping and separation of nmethod code and metadata. > > The code was tested using Nashorn + Octane, DaCapo, SPECJvm2008 and jprt. > > Benchmark results: > - [2] shows the score of the old and new version running Nashorn with the Octane benchmark at different code cache sizes (10 runs each, sizes < 32mb crash with the old version). An performance improvement of around 15% is reached. > - [3] shows the sweep time of the NMethodSweeper during runs of the Octane benchmark with different code cache sizes (10 runs each). The time is greatly reduced with the new version. > - [4] shows the time ratio (TOld / TNew - 1) of the DaCapo benchmarks with a code cache size of 64mb (30 runs with 20 warmups each). With the time differences being smaller than the confidence intervals it is not possible determine a difference between the two versions. > - Multiple runs of the SPECJvm2008 benchmark with different code cache sizes did not show a difference between the two versions. This is probably due to the fact that not much code is compiled at runtime compared to Nashorn with the Octane benchmark. > > The error bars at each data point show the 95% confidence interval. > > [1] https://bugs.openjdk.java.net/secure/attachment/16372/OctaneRatio.png > [2] https://bugs.openjdk.java.net/secure/attachment/16374/OctaneCCSizes_new.png > [3] https://bugs.openjdk.java.net/secure/attachment/16373/OctaneSweepTime_new.png > [4] https://bugs.openjdk.java.net/secure/attachment/16371/DaCapoCCSizes_64.png > > Thanks and best regards, > > Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/a2e16be4/attachment.html From christian.thalinger at oracle.com Thu Oct 3 17:39:04 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 17:39:04 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <524DEFC1.4090306@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> Message-ID: <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> On Oct 3, 2013, at 3:29 PM, Vladimir Kozlov wrote: > On 10/3/13 3:11 PM, Christian Thalinger wrote: >> >> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov wrote: >> >>> Christian, >>> >>> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars outside loop since they are invariants. >> >> Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust compilers. > > I don't trust compilers BECAUSE I am compiler guy and I know their problems :) > If calls are not inlined (virtual or other reasons) they will not be moved from the loop. > > And you should know already that the best performance improvement come from changing sources and not from compilers :) > > I insist to move at least callee_argument0 outside the loop. The code was easier to understand before but your wish is my command: http://cr.openjdk.java.net/~twisti/8011138/webrev.03/ > > Vladimir > >>> >>> Also both branches have to check (j->method() == callee_method). It could be checked first: >>> >>> if (j->method() == callee_method) { >>> if (callee_is_compiled_lambda_form) { >>> // Since compiled lambda forms are heavily reused we allow recursive inlining. >>> // If it is truly a recursion (using the same "receiver") we limit inlining >>> // otherwise we can easily blow the compiler stack. >>> Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); >>> if (caller_argument0 == callee_argument0) { >>> inline_level++; >>> } >>> } else { >>> inline_level++; >>> } >>> } >> >> Good point. >> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/3/13 1:41 PM, Christian Thalinger wrote: >>>> >>>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin wrote: >>>> >>>>>>> You should probably use: >>>>>>> caller_argument0->uncast() == callee_argument0->uncast() >>>>>> >>>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? >>>>> >>>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. >>>> >>>> Fair enough. I've added the uncast() calls: >>>> >>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ >>>> >>>>> >>>>> Roland. >>>> >> From vitalyd at gmail.com Thu Oct 3 17:44:41 2013 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 3 Oct 2013 20:44:41 -0400 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> Message-ID: Chris, you can move is_compiled_lambda_form() a block higher and use it there as well :). Sent from my phone On Oct 3, 2013 8:39 PM, "Christian Thalinger" < christian.thalinger at oracle.com> wrote: On Oct 3, 2013, at 3:29 PM, Vladimir Kozlov wrote: > On 10/3/13 3:11 PM, Christian Thalinger wrote: >> >> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov wrote: >> >>> Christian, >>> >>> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars outside loop since they are invariants. >> >> Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust compilers. > > I don't trust compilers BECAUSE I am compiler guy and I know their problems :) > If calls are not inlined (virtual or other reasons) they will not be moved from the loop. > > And you should know already that the best performance improvement come from changing sources and not from compilers :) > > I insist to move at least callee_argument0 outside the loop. The code was easier to understand before but your wish is my command: http://cr.openjdk.java.net/~twisti/8011138/webrev.03/ > > Vladimir > >>> >>> Also both branches have to check (j->method() == callee_method). It could be checked first: >>> >>> if (j->method() == callee_method) { >>> if (callee_is_compiled_lambda_form) { >>> // Since compiled lambda forms are heavily reused we allow recursive inlining. >>> // If it is truly a recursion (using the same "receiver") we limit inlining >>> // otherwise we can easily blow the compiler stack. >>> Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); >>> if (caller_argument0 == callee_argument0) { >>> inline_level++; >>> } >>> } else { >>> inline_level++; >>> } >>> } >> >> Good point. >> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/3/13 1:41 PM, Christian Thalinger wrote: >>>> >>>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin < roland.westrelin at oracle.com> wrote: >>>> >>>>>>> You should probably use: >>>>>>> caller_argument0->uncast() == callee_argument0->uncast() >>>>>> >>>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? >>>>> >>>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. >>>> >>>> Fair enough. I've added the uncast() calls: >>>> >>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ >>>> >>>>> >>>>> Roland. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/08ce22c9/attachment.html From vladimir.kozlov at oracle.com Thu Oct 3 17:56:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 17:56:06 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> Message-ID: <524E1226.4080201@oracle.com> Now it is good :) Thanks, Vladimir On 10/3/13 5:39 PM, Christian Thalinger wrote: > > On Oct 3, 2013, at 3:29 PM, Vladimir Kozlov wrote: > >> On 10/3/13 3:11 PM, Christian Thalinger wrote: >>> >>> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov wrote: >>> >>>> Christian, >>>> >>>> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars outside loop since they are invariants. >>> >>> Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust compilers. >> >> I don't trust compilers BECAUSE I am compiler guy and I know their problems :) >> If calls are not inlined (virtual or other reasons) they will not be moved from the loop. >> >> And you should know already that the best performance improvement come from changing sources and not from compilers :) >> >> I insist to move at least callee_argument0 outside the loop. > > The code was easier to understand before but your wish is my command: > > http://cr.openjdk.java.net/~twisti/8011138/webrev.03/ > >> >> Vladimir >> >>>> >>>> Also both branches have to check (j->method() == callee_method). It could be checked first: >>>> >>>> if (j->method() == callee_method) { >>>> if (callee_is_compiled_lambda_form) { >>>> // Since compiled lambda forms are heavily reused we allow recursive inlining. >>>> // If it is truly a recursion (using the same "receiver") we limit inlining >>>> // otherwise we can easily blow the compiler stack. >>>> Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); >>>> if (caller_argument0 == callee_argument0) { >>>> inline_level++; >>>> } >>>> } else { >>>> inline_level++; >>>> } >>>> } >>> >>> Good point. >>> >>> http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/3/13 1:41 PM, Christian Thalinger wrote: >>>>> >>>>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin wrote: >>>>> >>>>>>>> You should probably use: >>>>>>>> caller_argument0->uncast() == callee_argument0->uncast() >>>>>>> >>>>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? >>>>>> >>>>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. >>>>> >>>>> Fair enough. I've added the uncast() calls: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ >>>>> >>>>>> >>>>>> Roland. >>>>> >>> > From christian.thalinger at oracle.com Thu Oct 3 18:34:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 18:34:09 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: <524DFAA3.1070303@oracle.com> References: <524DFAA3.1070303@oracle.com> Message-ID: <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> On Oct 3, 2013, at 4:15 PM, Vladimir Kozlov wrote: > Christian, > > Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? You are right. Since we cannot reproduce this bug it's a guessing game. Your comment made me go back and look again. The reported error happened with a tier 2 compile and there is a different code path in LIRGenerator::increment_event_counter_impl() for CompLevel_limited_profile compiles: if (level == CompLevel_limited_profile) { address counters_adr = method->ensure_method_counters(); counter_holder = new_pointer_register(); __ move(LIR_OprFact::intptrConst(counters_adr), counter_holder); Method::ensure_method_counters() tries to build a MethodCounters data structure if it's null but: counter = Method::build_method_counters(mh(), CHECK_AND_CLEAR_NULL); it clears the exception and returns null! I really want C++ exceptions in the compiler? > > Thanks, > Vladimir > > On 10/2/13 8:17 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8025566 >> http://cr.openjdk.java.net/~twisti/8025566 >> >> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >> Reviewed-by: >> >> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >> >> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >> From christian.thalinger at oracle.com Thu Oct 3 18:37:37 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 3 Oct 2013 18:37:37 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> Message-ID: <5C1077BC-A751-4F76-A8B5-3A787D8FA03E@oracle.com> On Oct 3, 2013, at 5:44 PM, Vitaly Davidovich wrote: > Chris, you can move is_compiled_lambda_form() a block higher and use it there as well :). > Holy! What is it with you guys? ;-) Done. http://cr.openjdk.java.net/~twisti/8011138/webrev.04/ > Sent from my phone > > On Oct 3, 2013 8:39 PM, "Christian Thalinger" wrote: > > On Oct 3, 2013, at 3:29 PM, Vladimir Kozlov wrote: > > > On 10/3/13 3:11 PM, Christian Thalinger wrote: > >> > >> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov wrote: > >> > >>> Christian, > >>> > >>> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars outside loop since they are invariants. > >> > >> Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust compilers. > > > > I don't trust compilers BECAUSE I am compiler guy and I know their problems :) > > If calls are not inlined (virtual or other reasons) they will not be moved from the loop. > > > > And you should know already that the best performance improvement come from changing sources and not from compilers :) > > > > I insist to move at least callee_argument0 outside the loop. > > The code was easier to understand before but your wish is my command: > > http://cr.openjdk.java.net/~twisti/8011138/webrev.03/ > > > > > Vladimir > > > >>> > >>> Also both branches have to check (j->method() == callee_method). It could be checked first: > >>> > >>> if (j->method() == callee_method) { > >>> if (callee_is_compiled_lambda_form) { > >>> // Since compiled lambda forms are heavily reused we allow recursive inlining. > >>> // If it is truly a recursion (using the same "receiver") we limit inlining > >>> // otherwise we can easily blow the compiler stack. > >>> Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); > >>> if (caller_argument0 == callee_argument0) { > >>> inline_level++; > >>> } > >>> } else { > >>> inline_level++; > >>> } > >>> } > >> > >> Good point. > >> > >> http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ > >> > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 10/3/13 1:41 PM, Christian Thalinger wrote: > >>>> > >>>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin wrote: > >>>> > >>>>>>> You should probably use: > >>>>>>> caller_argument0->uncast() == callee_argument0->uncast() > >>>>>> > >>>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be the same, right? > >>>>> > >>>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. > >>>> > >>>> Fair enough. I've added the uncast() calls: > >>>> > >>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ > >>>> > >>>>> > >>>>> Roland. > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131003/ef4ed0fd/attachment-0001.html From vladimir.kozlov at oracle.com Thu Oct 3 19:01:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 03 Oct 2013 19:01:44 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> References: <524DFAA3.1070303@oracle.com> <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> Message-ID: <524E2188.6030103@oracle.com> On 10/3/13 6:34 PM, Christian Thalinger wrote: > > On Oct 3, 2013, at 4:15 PM, Vladimir Kozlov wrote: > >> Christian, >> >> Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? > > You are right. Since we cannot reproduce this bug it's a guessing game. > > Your comment made me go back and look again. The reported error happened with a tier 2 compile and there is a different code path in LIRGenerator::increment_event_counter_impl() for CompLevel_limited_profile compiles: > > if (level == CompLevel_limited_profile) { > address counters_adr = method->ensure_method_counters(); > counter_holder = new_pointer_register(); > __ move(LIR_OprFact::intptrConst(counters_adr), counter_holder); > > Method::ensure_method_counters() tries to build a MethodCounters data structure if it's null but: > > counter = Method::build_method_counters(mh(), CHECK_AND_CLEAR_NULL); > > it clears the exception and returns null! Right. This is it! And the only place where result is checked for null callers of get_method_counters(). All other places which call build_method_counters() do not check. Vladimir > > I really want C++ exceptions in the compiler? > >> >> Thanks, >> Vladimir >> >> On 10/2/13 8:17 PM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8025566 >>> http://cr.openjdk.java.net/~twisti/8025566 >>> >>> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >>> Reviewed-by: >>> >>> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >>> >>> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >>> > From roland.westrelin at oracle.com Fri Oct 4 01:26:54 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 4 Oct 2013 10:26:54 +0200 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <5C1077BC-A751-4F76-A8B5-3A787D8FA03E@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> <5C1077BC-A751-4F76-A8B5-3A787D8FA03E@oracle.com> Message-ID: <988DC321-E11B-4F8F-94E2-9EB92BE7567E@oracle.com> > http://cr.openjdk.java.net/~twisti/8011138/webrev.04/ That looks good to me. Roland. From roland.westrelin at oracle.com Fri Oct 4 01:28:19 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 4 Oct 2013 10:28:19 +0200 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DB8EF.7030908@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> Message-ID: <63FA819D-2D58-414B-94FD-2A8F81B1E0DB@oracle.com> > http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 That looks good to me. Roland. From vladimir.x.ivanov at oracle.com Fri Oct 4 02:10:32 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 13:10:32 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <63FA819D-2D58-414B-94FD-2A8F81B1E0DB@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> <63FA819D-2D58-414B-94FD-2A8F81B1E0DB@oracle.com> Message-ID: <524E8608.9030100@oracle.com> Thank you, Roland. Best regards, Vladimir Ivanov On 10/4/13 12:28 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 > > That looks good to me. > > Roland. > From igor.veresov at oracle.com Fri Oct 4 03:34:43 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 4 Oct 2013 14:34:43 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <524DB8EF.7030908@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> Message-ID: <5F8D8C06-8518-44F0-9FC8-688834CAE0B6@oracle.com> That looks good too. igor On Oct 3, 2013, at 10:35 PM, Vladimir Ivanov wrote: > Thanks for catching that. > > How about that? > http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 > > Best regards, > Vladimir Ivanov > > On 10/3/13 10:24 PM, Vladimir Kozlov wrote: >> You need to add cast (int)(j - lowval) since argument type is int. Some >> C++ compiler will complain if no cast. >> >> Thanks, >> Vladimir K >> >> On 10/3/13 11:04 AM, Vladimir Ivanov wrote: >>> Vladimir, >>> >>> I like the idea to convert j to int64. It looks much cleaner now. >>> >>> Here's updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >>>> I don't think it is right. You need to have check before the loop's body >>>> execution. >>>> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >>>> I think we should use int64 type for these expressions as in other lines >>>> of this method. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>> >>>>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>>>> overflows and j <= r->hi() succeeds again (leading to >>>>> extra iterations and infinite loop in the product). >>>>> >>>>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>>>> stop iterating, if necessary. >>>>> >>>>> Also, did a small cleanup: eliminated unused parameter from >>>>> SwitchRange::print. >>>>> >>>>> Testing: failing test case. >>>>> >>>>> Reviewed-by: iveresov, ? >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From vladimir.x.ivanov at oracle.com Fri Oct 4 04:27:17 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 04 Oct 2013 15:27:17 +0400 Subject: RFR (XS) 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range In-Reply-To: <5F8D8C06-8518-44F0-9FC8-688834CAE0B6@oracle.com> References: <524C6C12.9050200@oracle.com> <524DA1E6.1050903@oracle.com> <524DB1AB.8060406@oracle.com> <524DB675.6090101@oracle.com> <524DB8EF.7030908@oracle.com> <5F8D8C06-8518-44F0-9FC8-688834CAE0B6@oracle.com> Message-ID: <524EA615.6070500@oracle.com> Thank you, Igor. Best regards, Vladimir Ivanov On 10/4/13 2:34 PM, Igor Veresov wrote: > That looks good too. > > igor > > On Oct 3, 2013, at 10:35 PM, Vladimir Ivanov wrote: > >> Thanks for catching that. >> >> How about that? >> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.02 >> >> Best regards, >> Vladimir Ivanov >> >> On 10/3/13 10:24 PM, Vladimir Kozlov wrote: >>> You need to add cast (int)(j - lowval) since argument type is int. Some >>> C++ compiler will complain if no cast. >>> >>> Thanks, >>> Vladimir K >>> >>> On 10/3/13 11:04 AM, Vladimir Ivanov wrote: >>>> Vladimir, >>>> >>>> I like the idea to convert j to int64. It looks much cleaner now. >>>> >>>> Here's updated webrev: >>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.01 >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/3/13 8:57 PM, Vladimir Kozlov wrote: >>>>> I don't think it is right. You need to have check before the loop's body >>>>> execution. >>>>> Also what about case r->lo() == MIN_INT? (j - lowval) will underflow. >>>>> I think we should use int64 type for these expressions as in other lines >>>>> of this method. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/2/13 11:55 AM, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8024774/webrev.00/ >>>>>> 7 lines changed: 4 ins; 0 del; 3 mod >>>>>> >>>>>> If hi->hi() == MAX_INT then, after (j == r->hi() && r == hi), j++ >>>>>> overflows and j <= r->hi() succeeds again (leading to >>>>>> extra iterations and infinite loop in the product). >>>>>> >>>>>> The fix is to check whether upper limit is reached (j >= r->hi()) and >>>>>> stop iterating, if necessary. >>>>>> >>>>>> Also, did a small cleanup: eliminated unused parameter from >>>>>> SwitchRange::print. >>>>>> >>>>>> Testing: failing test case. >>>>>> >>>>>> Reviewed-by: iveresov, ? >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov > From rickard.backman at oracle.com Fri Oct 4 04:35:32 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 4 Oct 2013 13:35:32 +0200 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Message-ID: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> Hi all, I would appreciate some reviews on this change. On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. assert(idx >= 0) failed: index should be set It seems that gcm would put the addExact in a different block then the jump. This change forces the producer of FlagsProjNode to be in the same block as the consumer. Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ Thanks /R From roland.westrelin at oracle.com Fri Oct 4 08:28:46 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 4 Oct 2013 17:28:46 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> Message-ID: Thanks Chris for taking a look at this. On Oct 3, 2013, at 9:38 PM, Christian Thalinger wrote: > src/share/vm/c1/c1_GraphBuilder.cpp: > > + Values* GraphBuilder::args_list_for_profiling(ciMethod* target, int& start, bool may_have_receiver) { > + Values* GraphBuilder::collect_args_for_profiling(Values* args, ciMethod* target, bool may_have_receiver) { > > Both methods take a target as argument but never use it. It's used in a subsequent patch. Thanks for spotting that. I'll remove it. > src/share/vm/c1/c1_Instruction.hpp: > > + bool arg_needs_null_check(int i) const { > + if (i >= 0 && i < (int)sizeof(_nonnull_state) * BitsPerByte) { > > This means that arguments after the 32nd position always need a null check. Can you add a comment to these methods explaining that as we do for Java API methods? Maybe use Doxygen style. Ok. > > + virtual void input_values_do(ValueVisitor* f) { > + if (_recv != NULL) f->visit(&_recv); > + for (int i = 0; i < nb_profiled_args(); i++) f->visit(_obj_args->adr_at(i)); > + } > > Can you use some line breaks and curly braces here too? Ok. > src/share/vm/c1/c1_LIR.hpp: > > + intptr_t _current_klass; // what the profiling currently reports > > Why is the type intptr_t? Can't we use a more specific type here? Hmm, you tag klass pointers: Indeed. > > + static intptr_t with_status(intptr_t k, intptr_t in) { > + return k | (in & status_bits); > + } > > src/share/vm/c1/c1_LIRGenerator.cpp: > > + static ciKlass* sig_next_klass(ciSignature* sig, ciKlass*& first_sig_k, int& j) { > > We should move this method into ciSignature. Or better ciSignatureStream. I thought about it but figured it was too specific to be useful to anything else. Anyway, I can make that change. > > src/share/vm/ci/ciMethodData.hpp: > > + // If the compiler finds a profiled type is known statically for > > "type that is known" Ok. > > src/share/vm/oops/methodData.cpp: > > + SignatureStream ss(inv.signature()); > + int args_count = 0; > + for ( ; !ss.at_return_type(); ss.next()) { > + if (ss.is_object() || ss.is_array()) { > + args_count++; > + if (args_count >= max) { > + break; > + } > + } > + } > > This would be a nice utility method in SignatureStream (sans the >= max part). Maybe reference_parameter_count(). Oh, btw., arrays are treated as objects: > > bool SignatureStream::is_object() const { > return _type == T_OBJECT > || _type == T_ARRAY; > } > > It could be reused here right away: > > + #ifdef ASSERT > + int count = 0; > + for (SignatureStream ss(inv.signature()); !ss.at_return_type(); ss.next()) { > + if (ss.is_object() || ss.is_array()) { > + count++; Ok, I'll see what I can do. > > + Bytecodes::Code bc = m->code_at(bci); > + assert(Bytecodes::is_invoke(m->java_code_at(bci)), "arguments only make sense at call"); > + > + return bc == Bytecodes::_invokedynamic || bc == Bytecodes::_invokehandle; > > Instead of this code you can use Bytecode_invoke and then query inv.is_invokedynamic() || inv.is_invokehandle(). Sure. > > + int MethodData::profile_arguments_flag() { > + return TypeProfile % 10; > + } > > Why 10? That's also something that leaked from a subsequent patch. I intend to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each of arguments, parameters, return value. I welcome other suggestions. I'll remove the % 10. > > + bool MethodData::profile_arguments() { > + return profile_arguments_flag() > 0 && profile_arguments_flag() <= 2; > + } > + > + bool MethodData::profile_arguments_jsr292_only() { > + return profile_arguments_flag() == 1; > + } > + > + bool MethodData::profile_all_arguments() { > + return profile_arguments_flag() == 2; > + } > > I think you should have an enum for all of these constants. Ok. > > src/share/vm/oops/methodData.hpp: > > + void set_int_at_unchecked(int index, int value) { > + data()->set_cell_at(index, (intptr_t) value); > + } > > This method is not used. Well you're much better than I am at spotting unused stuff. I'll remove it. > > + return _args.set_type(i, TypeEntries::with_status((intptr_t)k, current)); > > Maybe you should add another with_status method that takes a Klass* and do the cast there. Ok. > > src/share/vm/runtime/globals.hpp: > > + develop(bool, PrintMethodDataStats, false, \ > > Most of these flags are named *Statistics. I'll make the change. > > + product_pd(uintx, TypeProfile, \ > + "Type profiling of arguments at call:" \ > + "0->off ; 1->js292 only; 2->all methods") \ > + product(intx, TypeProfileArgsLimit, 2, \ > + "max number of call arguments to consider for type profiling") \ > + \ > > Empty line missing between. I'll add the missing like. > > On Oct 2, 2013, at 10:02 AM, Roland Westrelin wrote: > >> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. >> >> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >> >> The output of -XX:+PrintMethodData is: >> >> 6 invokevirtual 2 >> 0 bci: 6 VirtualCallData count(0) entries(1) >> 'TestProfiling'(4746 1.00) >> argument types 0: stack(1) 'TestProfiling$C' >> 1: stack(2) unknown (null seen) >> >> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. >> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >> >> Roland. >> >> > From vladimir.kozlov at oracle.com Fri Oct 4 08:54:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Oct 2013 08:54:48 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <5C1077BC-A751-4F76-A8B5-3A787D8FA03E@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> <5C1077BC-A751-4F76-A8B5-3A787D8FA03E@oracle.com> Message-ID: <524EE4C8.7080602@oracle.com> Good. Vladimir On 10/3/13 6:37 PM, Christian Thalinger wrote: > > On Oct 3, 2013, at 5:44 PM, Vitaly Davidovich > wrote: > >> Chris, you can move is_compiled_lambda_form() a block higher and use it there as well :). >> > Holy! What is it with you guys? ;-) > > Done. > > http://cr.openjdk.java.net/~twisti/8011138/webrev.04/ >> >> Sent from my phone >> >> On Oct 3, 2013 8:39 PM, "Christian Thalinger" > >> wrote: >> >> >> On Oct 3, 2013, at 3:29 PM, Vladimir Kozlov > wrote: >> >> > On 10/3/13 3:11 PM, Christian Thalinger wrote: >> >> >> >> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov > wrote: >> >> >> >>> Christian, >> >>> >> >>> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars >> outside loop since they are invariants. >> >> >> >> Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust >> compilers. >> > >> > I don't trust compilers BECAUSE I am compiler guy and I know their problems :) >> > If calls are not inlined (virtual or other reasons) they will not be moved from the loop. >> > >> > And you should know already that the best performance improvement come from changing sources and not from >> compilers :) >> > >> > I insist to move at least callee_argument0 outside the loop. >> >> The code was easier to understand before but your wish is my command: >> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.03/ >> >> > >> > Vladimir >> > >> >>> >> >>> Also both branches have to check (j->method() == callee_method). It could be checked first: >> >>> >> >>> if (j->method() == callee_method) { >> >>> if (callee_is_compiled_lambda_form) { >> >>> // Since compiled lambda forms are heavily reused we allow recursive inlining. >> >>> // If it is truly a recursion (using the same "receiver") we limit inlining >> >>> // otherwise we can easily blow the compiler stack. >> >>> Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); >> >>> if (caller_argument0 == callee_argument0) { >> >>> inline_level++; >> >>> } >> >>> } else { >> >>> inline_level++; >> >>> } >> >>> } >> >> >> >> Good point. >> >> >> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ >> >> >> >>> >> >>> Thanks, >> >>> Vladimir >> >>> >> >>> On 10/3/13 1:41 PM, Christian Thalinger wrote: >> >>>> >> >>>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin > > wrote: >> >>>> >> >>>>>>> You should probably use: >> >>>>>>> caller_argument0->uncast() == callee_argument0->uncast() >> >>>>>> >> >>>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be >> the same, right? >> >>>>> >> >>>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. >> >>>> >> >>>> Fair enough. I've added the uncast() calls: >> >>>> >> >>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ >> >>>> >> >>>>> >> >>>>> Roland. >> >>>> >> >> >> > From christian.thalinger at oracle.com Fri Oct 4 09:54:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 09:54:34 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <988DC321-E11B-4F8F-94E2-9EB92BE7567E@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> <5C1077BC-A751-4F76-A8B5-3A787D8FA03E@oracle.com> <988DC321-E11B-4F8F-94E2-9EB92BE7567E@oracle.com> Message-ID: <70F2E3D3-CA83-46E9-A3C4-CF477C1D5287@oracle.com> Thank you, Roland. On Oct 4, 2013, at 1:26 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~twisti/8011138/webrev.04/ > > That looks good to me. > > Roland. > From christian.thalinger at oracle.com Fri Oct 4 09:54:42 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 09:54:42 -0700 Subject: RFR (S): 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods In-Reply-To: <524EE4C8.7080602@oracle.com> References: <915DE241-DCCD-4D3B-BFC5-DA4AEF991600@oracle.com> <3C150E75-D825-4C2B-A010-177A0F0508F4@oracle.com> <3F370332-55B4-4B5D-B1B3-D1FE1F3DAD52@oracle.com> <1F44EC2B-9383-4798-B2ED-4903689476D0@oracle.com> <6D170CE3-FF3B-4899-A675-FADB6E13039E@oracle.com> <524DE237.9020409@oracle.com> <8646A703-7A02-4E09-A5E7-3633A244AB0E@oracle.com> <524DEFC1.4090306@oracle.com> <90B374C8-BEEA-4DCC-A68A-B0AA5935C19D@oracle.com> <5C1077BC-A751-4F76-A8B5-3A787D8FA03E@oracle.com> <524EE4C8.7080602@oracle.com> Message-ID: <423DCAEB-49E8-44B2-9B65-E8398DD1AD3F@oracle.com> Thank you, Vladimir. On Oct 4, 2013, at 8:54 AM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/3/13 6:37 PM, Christian Thalinger wrote: >> >> On Oct 3, 2013, at 5:44 PM, Vitaly Davidovich > wrote: >> >>> Chris, you can move is_compiled_lambda_form() a block higher and use it there as well :). >>> >> Holy! What is it with you guys? ;-) >> >> Done. >> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.04/ >>> >>> Sent from my phone >>> >>> On Oct 3, 2013 8:39 PM, "Christian Thalinger" > >>> wrote: >>> >>> >>> On Oct 3, 2013, at 3:29 PM, Vladimir Kozlov > wrote: >>> >>> > On 10/3/13 3:11 PM, Christian Thalinger wrote: >>> >> >>> >> On Oct 3, 2013, at 2:31 PM, Vladimir Kozlov > wrote: >>> >> >>> >>> Christian, >>> >>> >>> >>> Put callee_method->is_compiled_lambda_form() and jvms->map()->argument(jvms, 0)->uncast() into local vars >>> outside loop since they are invariants. >>> >> >>> >> Invariants, exactly. That's why the compiler should do it for me. We are compiler people; we should trust >>> compilers. >>> > >>> > I don't trust compilers BECAUSE I am compiler guy and I know their problems :) >>> > If calls are not inlined (virtual or other reasons) they will not be moved from the loop. >>> > >>> > And you should know already that the best performance improvement come from changing sources and not from >>> compilers :) >>> > >>> > I insist to move at least callee_argument0 outside the loop. >>> >>> The code was easier to understand before but your wish is my command: >>> >>> http://cr.openjdk.java.net/~twisti/8011138/webrev.03/ >>> >>> > >>> > Vladimir >>> > >>> >>> >>> >>> Also both branches have to check (j->method() == callee_method). It could be checked first: >>> >>> >>> >>> if (j->method() == callee_method) { >>> >>> if (callee_is_compiled_lambda_form) { >>> >>> // Since compiled lambda forms are heavily reused we allow recursive inlining. >>> >>> // If it is truly a recursion (using the same "receiver") we limit inlining >>> >>> // otherwise we can easily blow the compiler stack. >>> >>> Node* caller_argument0 = j->map()->argument(j, 0)->uncast(); >>> >>> if (caller_argument0 == callee_argument0) { >>> >>> inline_level++; >>> >>> } >>> >>> } else { >>> >>> inline_level++; >>> >>> } >>> >>> } >>> >> >>> >> Good point. >>> >> >>> >> http://cr.openjdk.java.net/~twisti/8011138/webrev.02/ >>> >> >>> >>> >>> >>> Thanks, >>> >>> Vladimir >>> >>> >>> >>> On 10/3/13 1:41 PM, Christian Thalinger wrote: >>> >>>> >>> >>>> On Oct 3, 2013, at 11:28 AM, Roland Westrelin >> > wrote: >>> >>>> >>> >>>>>>> You should probably use: >>> >>>>>>> caller_argument0->uncast() == callee_argument0->uncast() >>> >>>>>> >>> >>>>>> I can but it's probably not necessary. If it's truly a recursive call even the CheckCastPP node should be >>> the same, right? >>> >>>>> >>> >>>>> With 8024070, that will add Cast nodes in many places, I don't think that will necessarily be the case. >>> >>>> >>> >>>> Fair enough. I've added the uncast() calls: >>> >>>> >>> >>>> http://cr.openjdk.java.net/~twisti/8011138/webrev.01/ >>> >>>> >>> >>>>> >>> >>>>> Roland. >>> >>>> >>> >> >>> >> From christian.thalinger at oracle.com Fri Oct 4 11:06:20 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 11:06:20 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> Message-ID: Would it be possible to put all this logic into FlagsProjNode::pinned()? On Oct 4, 2013, at 4:35 AM, Rickard B?ckman wrote: > Hi all, > > I would appreciate some reviews on this change. > > On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. > assert(idx >= 0) failed: index should be set > > It seems that gcm would put the addExact in a different block then the jump. > This change forces the producer of FlagsProjNode to be in the same block as > the consumer. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 > Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ > > Thanks > /R From vladimir.kozlov at oracle.com Fri Oct 4 11:55:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Oct 2013 11:55:37 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> Message-ID: <524F0F29.3070800@oracle.com> Rickard, addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. Vladimir On 10/4/13 4:35 AM, Rickard B?ckman wrote: > Hi all, > > I would appreciate some reviews on this change. > > On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. > assert(idx >= 0) failed: index should be set > > It seems that gcm would put the addExact in a different block then the jump. > This change forces the producer of FlagsProjNode to be in the same block as > the consumer. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 > Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ > > Thanks > /R > From christian.thalinger at oracle.com Fri Oct 4 14:52:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 14:52:02 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: <524E2188.6030103@oracle.com> References: <524DFAA3.1070303@oracle.com> <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> <524E2188.6030103@oracle.com> Message-ID: Here is the (hopefully) correct fix for this problem: http://cr.openjdk.java.net/~twisti/8025566/webrev.01/ I've made ciMethod::ensure_method_counters() call Method::get_method_counters() because they did the same job. For C1 I can provoke the failure situation and C1 bails out of the compilation just fine: 1652 157 2 java.io.FilterInputStream::read (11 bytes) compilation bailout: method counters allocation failed 1652 157 2 java.io.FilterInputStream::read (11 bytes) COMPILE SKIPPED: method counters allocation failed (retry at different tier) For C2 I wasn't able to get to the point where the code in question is executed. I opted for a more conservative way: record a failure but continue the compile. If we'd return straightaway the graph might be in a bad state and we could crash somewhere else. When continuing the compile we can be sure the graph is sane and another failing() check somewhere will bail out for us eventually. On Oct 3, 2013, at 7:01 PM, Vladimir Kozlov wrote: > On 10/3/13 6:34 PM, Christian Thalinger wrote: >> >> On Oct 3, 2013, at 4:15 PM, Vladimir Kozlov wrote: >> >>> Christian, >>> >>> Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? >> >> You are right. Since we cannot reproduce this bug it's a guessing game. >> >> Your comment made me go back and look again. The reported error happened with a tier 2 compile and there is a different code path in LIRGenerator::increment_event_counter_impl() for CompLevel_limited_profile compiles: >> >> if (level == CompLevel_limited_profile) { >> address counters_adr = method->ensure_method_counters(); >> counter_holder = new_pointer_register(); >> __ move(LIR_OprFact::intptrConst(counters_adr), counter_holder); >> >> Method::ensure_method_counters() tries to build a MethodCounters data structure if it's null but: >> >> counter = Method::build_method_counters(mh(), CHECK_AND_CLEAR_NULL); >> >> it clears the exception and returns null! > > Right. This is it! And the only place where result is checked for null callers of get_method_counters(). All other places which call build_method_counters() do not check. > > Vladimir > >> >> I really want C++ exceptions in the compiler? >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/2/13 8:17 PM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8025566 >>>> http://cr.openjdk.java.net/~twisti/8025566 >>>> >>>> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >>>> Reviewed-by: >>>> >>>> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >>>> >>>> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >>>> >> From vladimir.kozlov at oracle.com Fri Oct 4 15:43:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Oct 2013 15:43:47 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: References: <524DFAA3.1070303@oracle.com> <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> <524E2188.6030103@oracle.com> Message-ID: <524F44A3.9030102@oracle.com> On 10/4/13 2:52 PM, Christian Thalinger wrote: > Here is the (hopefully) correct fix for this problem: > > http://cr.openjdk.java.net/~twisti/8025566/webrev.01/ > > I've made ciMethod::ensure_method_counters() call Method::get_method_counters() because they did the same job. > > For C1 I can provoke the failure situation and C1 bails out of the compilation just fine: > > 1652 157 2 java.io.FilterInputStream::read (11 bytes) > compilation bailout: method counters allocation failed > 1652 157 2 java.io.FilterInputStream::read (11 bytes) COMPILE SKIPPED: method counters allocation failed (retry at different tier) > > For C2 I wasn't able to get to the point where the code in question is executed. I opted for a more conservative way: record a failure but continue the compile. If we'd return straightaway the graph might be in a bad state and we could crash somewhere else. When continuing the compile we can be sure the graph is sane and another failing() check somewhere will bail out for us eventually. It is used only when C2 generates profiling code (SAP). I think you should return from increment_and_test_invocation_counter() if counters_adr is NULL - don't generate increment code. The code path after that has failing() check so I agree that you don't need to add new one. There is other place missing NULL check: ciReplay::initialize() Thanks, Vladimir > > On Oct 3, 2013, at 7:01 PM, Vladimir Kozlov wrote: > >> On 10/3/13 6:34 PM, Christian Thalinger wrote: >>> >>> On Oct 3, 2013, at 4:15 PM, Vladimir Kozlov wrote: >>> >>>> Christian, >>>> >>>> Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? >>> >>> You are right. Since we cannot reproduce this bug it's a guessing game. >>> >>> Your comment made me go back and look again. The reported error happened with a tier 2 compile and there is a different code path in LIRGenerator::increment_event_counter_impl() for CompLevel_limited_profile compiles: >>> >>> if (level == CompLevel_limited_profile) { >>> address counters_adr = method->ensure_method_counters(); >>> counter_holder = new_pointer_register(); >>> __ move(LIR_OprFact::intptrConst(counters_adr), counter_holder); >>> >>> Method::ensure_method_counters() tries to build a MethodCounters data structure if it's null but: >>> >>> counter = Method::build_method_counters(mh(), CHECK_AND_CLEAR_NULL); >>> >>> it clears the exception and returns null! >> >> Right. This is it! And the only place where result is checked for null callers of get_method_counters(). All other places which call build_method_counters() do not check. >> >> Vladimir >> >>> >>> I really want C++ exceptions in the compiler? >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/2/13 8:17 PM, Christian Thalinger wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8025566 >>>>> http://cr.openjdk.java.net/~twisti/8025566 >>>>> >>>>> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >>>>> Reviewed-by: >>>>> >>>>> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >>>>> >>>>> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >>>>> >>> > From christian.thalinger at oracle.com Fri Oct 4 17:14:03 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 17:14:03 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: <524F44A3.9030102@oracle.com> References: <524DFAA3.1070303@oracle.com> <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> <524E2188.6030103@oracle.com> <524F44A3.9030102@oracle.com> Message-ID: <00B64DD1-3419-4D03-956D-9F7B59FAB17B@oracle.com> On Oct 4, 2013, at 3:43 PM, Vladimir Kozlov wrote: > On 10/4/13 2:52 PM, Christian Thalinger wrote: >> Here is the (hopefully) correct fix for this problem: >> >> http://cr.openjdk.java.net/~twisti/8025566/webrev.01/ >> >> I've made ciMethod::ensure_method_counters() call Method::get_method_counters() because they did the same job. >> >> For C1 I can provoke the failure situation and C1 bails out of the compilation just fine: >> >> 1652 157 2 java.io.FilterInputStream::read (11 bytes) >> compilation bailout: method counters allocation failed >> 1652 157 2 java.io.FilterInputStream::read (11 bytes) COMPILE SKIPPED: method counters allocation failed (retry at different tier) >> >> For C2 I wasn't able to get to the point where the code in question is executed. I opted for a more conservative way: record a failure but continue the compile. If we'd return straightaway the graph might be in a bad state and we could crash somewhere else. When continuing the compile we can be sure the graph is sane and another failing() check somewhere will bail out for us eventually. > > It is used only when C2 generates profiling code (SAP). Ahh! That explains why I couldn't trigger it. > I think you should return from increment_and_test_invocation_counter() if counters_adr is NULL - don't generate increment code. Ok. > The code path after that has failing() check so I agree that you don't need to add new one. > > There is other place missing NULL check: ciReplay::initialize() Thanks for catching that. I used Method::get_method_counters() there as well and a guarantee because if we cannot allocate the method counters it doesn't make sense to continue. http://cr.openjdk.java.net/~twisti/8025566/webrev.02/ > > Thanks, > Vladimir > >> >> On Oct 3, 2013, at 7:01 PM, Vladimir Kozlov wrote: >> >>> On 10/3/13 6:34 PM, Christian Thalinger wrote: >>>> >>>> On Oct 3, 2013, at 4:15 PM, Vladimir Kozlov wrote: >>>> >>>>> Christian, >>>>> >>>>> Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? >>>> >>>> You are right. Since we cannot reproduce this bug it's a guessing game. >>>> >>>> Your comment made me go back and look again. The reported error happened with a tier 2 compile and there is a different code path in LIRGenerator::increment_event_counter_impl() for CompLevel_limited_profile compiles: >>>> >>>> if (level == CompLevel_limited_profile) { >>>> address counters_adr = method->ensure_method_counters(); >>>> counter_holder = new_pointer_register(); >>>> __ move(LIR_OprFact::intptrConst(counters_adr), counter_holder); >>>> >>>> Method::ensure_method_counters() tries to build a MethodCounters data structure if it's null but: >>>> >>>> counter = Method::build_method_counters(mh(), CHECK_AND_CLEAR_NULL); >>>> >>>> it clears the exception and returns null! >>> >>> Right. This is it! And the only place where result is checked for null callers of get_method_counters(). All other places which call build_method_counters() do not check. >>> >>> Vladimir >>> >>>> >>>> I really want C++ exceptions in the compiler? >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/2/13 8:17 PM, Christian Thalinger wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8025566 >>>>>> http://cr.openjdk.java.net/~twisti/8025566 >>>>>> >>>>>> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >>>>>> Reviewed-by: >>>>>> >>>>>> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >>>>>> >>>>>> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >>>>>> >>>> >> From vladimir.kozlov at oracle.com Fri Oct 4 17:59:51 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Oct 2013 17:59:51 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> Message-ID: <524F6487.8030606@oracle.com> Roland, I need more time to go through methoddate.?pp changes. Here some preliminary comments. I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could be set by other thread during small window. But it is still not atomic. It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not change, may be split in 2 field). Or may be use atomic cmpxchg. Then we would not worry about concurrent updates from different threads. c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: + if (do_update) { + #ifndef ASSERT + __ jmpb(next); + #else + __ jmp(next); + #endif + } + } else { + #ifdef ASSERT + __ testptr(tmp, tmp); + __ jccb(Assembler::notZero, update); + __ stop("unexpect null obj"); + #endif + } for example: + if (do_update) { + #ifndef ASSERT + __ jmpb(next); + } + #else + __ jmp(next); + } + } else { + __ testptr(tmp, tmp); + __ jccb(Assembler::notZero, update); + __ stop("unexpect null obj"); + #endif + } Indention in c1_LIRGenerator.cpp in sig_next_klass(): + if (first_sig_k != NULL) { + sig_k = first_sig_k; + first_sig_k = NULL; java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. TypeProfileLeveL? Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. Thanks, Vladimir On 10/2/13 10:02 AM, Roland Westrelin wrote: > Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. > > http://cr.openjdk.java.net/~roland/8023657/webrev.01/ > > The output of -XX:+PrintMethodData is: > > 6 invokevirtual 2 > 0 bci: 6 VirtualCallData count(0) entries(1) > 'TestProfiling'(4746 1.00) > argument types 0: stack(1) 'TestProfiling$C' > 1: stack(2) unknown (null seen) > > Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. > Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. > Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. > > Roland. > > From vladimir.kozlov at oracle.com Fri Oct 4 18:03:27 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Oct 2013 18:03:27 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: <00B64DD1-3419-4D03-956D-9F7B59FAB17B@oracle.com> References: <524DFAA3.1070303@oracle.com> <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> <524E2188.6030103@oracle.com> <524F44A3.9030102@oracle.com> <00B64DD1-3419-4D03-956D-9F7B59FAB17B@oracle.com> Message-ID: <524F655F.1000808@oracle.com> I think it is good. Thanks, Vladimir On 10/4/13 5:14 PM, Christian Thalinger wrote: > > On Oct 4, 2013, at 3:43 PM, Vladimir Kozlov wrote: > >> On 10/4/13 2:52 PM, Christian Thalinger wrote: >>> Here is the (hopefully) correct fix for this problem: >>> >>> http://cr.openjdk.java.net/~twisti/8025566/webrev.01/ >>> >>> I've made ciMethod::ensure_method_counters() call Method::get_method_counters() because they did the same job. >>> >>> For C1 I can provoke the failure situation and C1 bails out of the compilation just fine: >>> >>> 1652 157 2 java.io.FilterInputStream::read (11 bytes) >>> compilation bailout: method counters allocation failed >>> 1652 157 2 java.io.FilterInputStream::read (11 bytes) COMPILE SKIPPED: method counters allocation failed (retry at different tier) >>> >>> For C2 I wasn't able to get to the point where the code in question is executed. I opted for a more conservative way: record a failure but continue the compile. If we'd return straightaway the graph might be in a bad state and we could crash somewhere else. When continuing the compile we can be sure the graph is sane and another failing() check somewhere will bail out for us eventually. >> >> It is used only when C2 generates profiling code (SAP). > > Ahh! That explains why I couldn't trigger it. > >> I think you should return from increment_and_test_invocation_counter() if counters_adr is NULL - don't generate increment code. > > Ok. > >> The code path after that has failing() check so I agree that you don't need to add new one. >> >> There is other place missing NULL check: ciReplay::initialize() > > Thanks for catching that. I used Method::get_method_counters() there as well and a guarantee because if we cannot allocate the method counters it doesn't make sense to continue. > > http://cr.openjdk.java.net/~twisti/8025566/webrev.02/ > >> >> Thanks, >> Vladimir >> >>> >>> On Oct 3, 2013, at 7:01 PM, Vladimir Kozlov wrote: >>> >>>> On 10/3/13 6:34 PM, Christian Thalinger wrote: >>>>> >>>>> On Oct 3, 2013, at 4:15 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Christian, >>>>>> >>>>>> Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? >>>>> >>>>> You are right. Since we cannot reproduce this bug it's a guessing game. >>>>> >>>>> Your comment made me go back and look again. The reported error happened with a tier 2 compile and there is a different code path in LIRGenerator::increment_event_counter_impl() for CompLevel_limited_profile compiles: >>>>> >>>>> if (level == CompLevel_limited_profile) { >>>>> address counters_adr = method->ensure_method_counters(); >>>>> counter_holder = new_pointer_register(); >>>>> __ move(LIR_OprFact::intptrConst(counters_adr), counter_holder); >>>>> >>>>> Method::ensure_method_counters() tries to build a MethodCounters data structure if it's null but: >>>>> >>>>> counter = Method::build_method_counters(mh(), CHECK_AND_CLEAR_NULL); >>>>> >>>>> it clears the exception and returns null! >>>> >>>> Right. This is it! And the only place where result is checked for null callers of get_method_counters(). All other places which call build_method_counters() do not check. >>>> >>>> Vladimir >>>> >>>>> >>>>> I really want C++ exceptions in the compiler? >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/2/13 8:17 PM, Christian Thalinger wrote: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025566 >>>>>>> http://cr.openjdk.java.net/~twisti/8025566 >>>>>>> >>>>>>> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >>>>>>> Reviewed-by: >>>>>>> >>>>>>> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >>>>>>> >>>>>>> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >>>>>>> >>>>> >>> > From christian.thalinger at oracle.com Fri Oct 4 18:54:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 4 Oct 2013 18:54:59 -0700 Subject: RFR (XS): 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method In-Reply-To: <524F655F.1000808@oracle.com> References: <524DFAA3.1070303@oracle.com> <0FC21397-D08E-4BD2-95BE-6B2C27E64909@oracle.com> <524E2188.6030103@oracle.com> <524F44A3.9030102@oracle.com> <00B64DD1-3419-4D03-956D-9F7B59FAB17B@oracle.com> <524F655F.1000808@oracle.com> Message-ID: Yeah, I think so too. Thank you, Vladimir. On Oct 4, 2013, at 6:03 PM, Vladimir Kozlov wrote: > I think it is good. > > Thanks, > Vladimir > > On 10/4/13 5:14 PM, Christian Thalinger wrote: >> >> On Oct 4, 2013, at 3:43 PM, Vladimir Kozlov wrote: >> >>> On 10/4/13 2:52 PM, Christian Thalinger wrote: >>>> Here is the (hopefully) correct fix for this problem: >>>> >>>> http://cr.openjdk.java.net/~twisti/8025566/webrev.01/ >>>> >>>> I've made ciMethod::ensure_method_counters() call Method::get_method_counters() because they did the same job. >>>> >>>> For C1 I can provoke the failure situation and C1 bails out of the compilation just fine: >>>> >>>> 1652 157 2 java.io.FilterInputStream::read (11 bytes) >>>> compilation bailout: method counters allocation failed >>>> 1652 157 2 java.io.FilterInputStream::read (11 bytes) COMPILE SKIPPED: method counters allocation failed (retry at different tier) >>>> >>>> For C2 I wasn't able to get to the point where the code in question is executed. I opted for a more conservative way: record a failure but continue the compile. If we'd return straightaway the graph might be in a bad state and we could crash somewhere else. When continuing the compile we can be sure the graph is sane and another failing() check somewhere will bail out for us eventually. >>> >>> It is used only when C2 generates profiling code (SAP). >> >> Ahh! That explains why I couldn't trigger it. >> >>> I think you should return from increment_and_test_invocation_counter() if counters_adr is NULL - don't generate increment code. >> >> Ok. >> >>> The code path after that has failing() check so I agree that you don't need to add new one. >>> >>> There is other place missing NULL check: ciReplay::initialize() >> >> Thanks for catching that. I used Method::get_method_counters() there as well and a guarantee because if we cannot allocate the method counters it doesn't make sense to continue. >> >> http://cr.openjdk.java.net/~twisti/8025566/webrev.02/ >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> On Oct 3, 2013, at 7:01 PM, Vladimir Kozlov wrote: >>>> >>>>> On 10/3/13 6:34 PM, Christian Thalinger wrote: >>>>>> >>>>>> On Oct 3, 2013, at 4:15 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Christian, >>>>>>> >>>>>>> Can you explain how _metadata pointer could be NULL if it was just created and there is check h_m()->method_data() != NULL? >>>>>> >>>>>> You are right. Since we cannot reproduce this bug it's a guessing game. >>>>>> >>>>>> Your comment made me go back and look again. The reported error happened with a tier 2 compile and there is a different code path in LIRGenerator::increment_event_counter_impl() for CompLevel_limited_profile compiles: >>>>>> >>>>>> if (level == CompLevel_limited_profile) { >>>>>> address counters_adr = method->ensure_method_counters(); >>>>>> counter_holder = new_pointer_register(); >>>>>> __ move(LIR_OprFact::intptrConst(counters_adr), counter_holder); >>>>>> >>>>>> Method::ensure_method_counters() tries to build a MethodCounters data structure if it's null but: >>>>>> >>>>>> counter = Method::build_method_counters(mh(), CHECK_AND_CLEAR_NULL); >>>>>> >>>>>> it clears the exception and returns null! >>>>> >>>>> Right. This is it! And the only place where result is checked for null callers of get_method_counters(). All other places which call build_method_counters() do not check. >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> I really want C++ exceptions in the compiler? >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/2/13 8:17 PM, Christian Thalinger wrote: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8025566 >>>>>>>> http://cr.openjdk.java.net/~twisti/8025566 >>>>>>>> >>>>>>>> 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> The problem is in ciMethod::ensure_method_data(). The call to ciMethodData::load_data() can fail when the backing metadata pointer is null and return with a still empty method data. So we have to check here for non-emptiness. >>>>>>>> >>>>>>>> I also removed ciMethodData::set_mature(). This method was only used with the old JSR 292 implementation. >>>>>>>> >>>>>> >>>> >> From niclas.adlertz at oracle.com Fri Oct 4 18:57:29 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Sat, 05 Oct 2013 01:57:29 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8025656: compiler/8013496/Test8013496.sh fails on assert Message-ID: <20131005015731.DC68562DA8@hg.openjdk.java.net> Changeset: 1e814e391ee8 Author: anoll Date: 2013-10-04 09:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1e814e391ee8 8025656: compiler/8013496/Test8013496.sh fails on assert Summary: Ensure the thread is in correct state; rewrote test in Java Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp - test/compiler/8013496/Test8013496.sh + test/compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java From vladimir.kozlov at oracle.com Fri Oct 4 21:30:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 04 Oct 2013 21:30:14 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <524F6487.8030606@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> Message-ID: <524F95D6.9090200@oracle.com> On 10/4/13 5:59 PM, Vladimir Kozlov wrote: > Roland, > > I need more time to go through methoddate.?pp changes. > Here some preliminary comments. > > I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could > be set by other thread during small window. But it is still not atomic. We can't use orptr for klass record because other thread may store an other klass. As result we will get garbage value. So need to use mov. How expensive will be cmpxchg? I am just worried that we can't trust this type info due to concurrency. Vladimir > It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not > change, may be split in 2 field). Or may be use atomic cmpxchg. > Then we would not worry about concurrent updates from different threads. > > c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: > > + if (do_update) { > + #ifndef ASSERT > + __ jmpb(next); > + #else > + __ jmp(next); > + #endif > + } > + } else { > + #ifdef ASSERT > + __ testptr(tmp, tmp); > + __ jccb(Assembler::notZero, update); > + __ stop("unexpect null obj"); > + #endif > + } > > for example: > > + if (do_update) { > + #ifndef ASSERT > + __ jmpb(next); > + } > + #else > + __ jmp(next); > + } > + } else { > + __ testptr(tmp, tmp); > + __ jccb(Assembler::notZero, update); > + __ stop("unexpect null obj"); > + #endif > + } > > Indention in c1_LIRGenerator.cpp in sig_next_klass(): > > + if (first_sig_k != NULL) { > + sig_k = first_sig_k; > + first_sig_k = NULL; > > > java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more > statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). > > TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. > TypeProfileLeveL? > > Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. > > Thanks, > Vladimir > > On 10/2/13 10:02 AM, Roland Westrelin wrote: >> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes >> tiered support on 32bit and 64bit x86. >> >> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >> >> The output of -XX:+PrintMethodData is: >> >> 6 invokevirtual 2 >> 0 bci: 6 VirtualCallData count(0) entries(1) >> 'TestProfiling'(4746 1.00) >> argument types 0: stack(1) 'TestProfiling$C' >> 1: stack(2) unknown (null seen) >> >> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda >> form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to >> use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 >> etc. >> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >> >> Roland. >> >> From christian.thalinger at oracle.com Fri Oct 4 22:48:37 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 05 Oct 2013 05:48:37 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131005054844.E23DD62DB2@hg.openjdk.java.net> Changeset: 0c4c40f5c399 Author: twisti Date: 2013-10-04 10:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0c4c40f5c399 8011138: C2: stack overflow in compiler thread because of recursive inlining of lambda form methods Reviewed-by: kvn, roland ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: 5f1241525a01 Author: twisti Date: 2013-10-04 19:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5f1241525a01 Merge From roland.westrelin at oracle.com Sat Oct 5 02:58:51 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sat, 5 Oct 2013 11:58:51 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <524F95D6.9090200@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <524F95D6.9090200@oracle.com> Message-ID: <6501BAF7-D1C6-4777-BE47-F77047853B12@oracle.com> On Oct 5, 2013, at 6:30 AM, Vladimir Kozlov wrote: > > > On 10/4/13 5:59 PM, Vladimir Kozlov wrote: >> Roland, >> >> I need more time to go through methoddate.?pp changes. >> Here some preliminary comments. >> >> I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could >> be set by other thread during small window. But it is still not atomic. > > We can't use orptr for klass record because other thread may store an other klass. As result we will get garbage value. So need to use mov. How expensive will be cmpxchg? I am just worried that we can't trust this type info due to concurrency. Why is it such concern in the case? Other profiling may also miss events due to concurrency (counter not updated, lost receiver at a call/type check). In the new code, we set the null bit only once, the recorded class only once, the unknown bit only once. It's true we can miss one of those events, but most likely the event will occur again and it can't be lost more than twice, I would say (because each of the events is recorded only once). So only a very rare event can be lost for good. We start profiling after several invocations of the method, so in practice we already risk loosing rare events. And in any case, we risk making a wrong assumption at compile time that we can recover from but not generate erroneous code. To me, concurrency when counters are incremented must be much more of an issue. We risk repeatedly loosing events and end up with wrong relative frequencies. Roland. > > Vladimir > >> It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not >> change, may be split in 2 field). Or may be use atomic cmpxchg. >> Then we would not worry about concurrent updates from different threads. >> >> c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: >> >> + if (do_update) { >> + #ifndef ASSERT >> + __ jmpb(next); >> + #else >> + __ jmp(next); >> + #endif >> + } >> + } else { >> + #ifdef ASSERT >> + __ testptr(tmp, tmp); >> + __ jccb(Assembler::notZero, update); >> + __ stop("unexpect null obj"); >> + #endif >> + } >> >> for example: >> >> + if (do_update) { >> + #ifndef ASSERT >> + __ jmpb(next); >> + } >> + #else >> + __ jmp(next); >> + } >> + } else { >> + __ testptr(tmp, tmp); >> + __ jccb(Assembler::notZero, update); >> + __ stop("unexpect null obj"); >> + #endif >> + } >> >> Indention in c1_LIRGenerator.cpp in sig_next_klass(): >> >> + if (first_sig_k != NULL) { >> + sig_k = first_sig_k; >> + first_sig_k = NULL; >> >> >> java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more >> statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). >> >> TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. >> TypeProfileLeveL? >> >> Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. >> >> Thanks, >> Vladimir >> >> On 10/2/13 10:02 AM, Roland Westrelin wrote: >>> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes >>> tiered support on 32bit and 64bit x86. >>> >>> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >>> >>> The output of -XX:+PrintMethodData is: >>> >>> 6 invokevirtual 2 >>> 0 bci: 6 VirtualCallData count(0) entries(1) >>> 'TestProfiling'(4746 1.00) >>> argument types 0: stack(1) 'TestProfiling$C' >>> 1: stack(2) unknown (null seen) >>> >>> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda >>> form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >>> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to >>> use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 >>> etc. >>> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >>> >>> Roland. >>> >>> From rickard.backman at oracle.com Sun Oct 6 22:13:07 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Mon, 7 Oct 2013 07:13:07 +0200 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <524F0F29.3070800@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> Message-ID: Vladimir, both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 uses of addExact this seems to be problematic. The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. Thank you /R On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: > Rickard, > > addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. > > FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. > > Vladimir > > On 10/4/13 4:35 AM, Rickard B?ckman wrote: >> Hi all, >> >> I would appreciate some reviews on this change. >> >> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >> assert(idx >= 0) failed: index should be set >> >> It seems that gcm would put the addExact in a different block then the jump. >> This change forces the producer of FlagsProjNode to be in the same block as >> the consumer. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >> >> Thanks >> /R >> From vladimir.x.ivanov at oracle.com Mon Oct 7 05:59:54 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Mon, 07 Oct 2013 12:59:54 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 4 new changesets Message-ID: <20131007130006.DF1B862DFF@hg.openjdk.java.net> Changeset: bf8a21c3ab3b Author: vlivanov Date: 2013-10-07 14:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf8a21c3ab3b 8025849: Redundant "pid" in VM log file name (e.g. hotspot_pidpid12345.log) Reviewed-by: twisti, azeemj ! src/share/vm/utilities/ostream.cpp Changeset: 5cc2d82aa82a Author: vlivanov Date: 2013-10-07 14:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5cc2d82aa82a 8024943: ciReplay: fails to dump replay data during safepointing Reviewed-by: kvn, twisti ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/utilities/vmError.cpp Changeset: f478c98e8114 Author: vlivanov Date: 2013-10-07 14:12 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f478c98e8114 8024774: assert(_con < t->is_tuple()->cnt()) failed: ProjNode::_con must be in range Reviewed-by: iveresov, roland, kvn, twisti ! src/share/vm/opto/parse2.cpp Changeset: 5741fc86a2ee Author: vlivanov Date: 2013-10-07 14:13 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5741fc86a2ee 8025845: Default methods are unnecessarily marked w/ force_inline directive in some situations Reviewed-by: acorn, kvn ! src/share/vm/classfile/defaultMethods.cpp From niclas.adlertz at oracle.com Mon Oct 7 07:00:12 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Mon, 07 Oct 2013 16:00:12 +0200 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Message-ID: <5252BE6C.5070705@oracle.com> Hi all, The uninitialized pointer 'Reachblock' can be replaced with NULL at the call since the node we are re-materializing will not have any live range input (because of contains_no_live_range_input(def)). WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8013830/webrev00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8013830 Kind Regards, Niclas Adlertz From roland.westrelin at oracle.com Mon Oct 7 07:46:04 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 7 Oct 2013 16:46:04 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <524F6487.8030606@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> Message-ID: <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> Vladimir, Thanks for your comments. > I need more time to go through methoddate.?pp changes. Sure. Here is a new webrev that addresses Christian's comments and yours below. http://cr.openjdk.java.net/~roland/8023657/webrev.02/ > Here some preliminary comments. > > I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could be set by other thread during small window. But it is still not atomic. > It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not change, may be split in 2 field). Or may be use atomic cmpxchg. In one of the follow up changes I will do profiling of the type of return values. For them there's not need of keeping track of the stack slot so we can't assume that there's an extra entry in the MDO for each type. Roland. > Then we would not worry about concurrent updates from different threads. > > c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: > > + if (do_update) { > + #ifndef ASSERT > + __ jmpb(next); > + #else > + __ jmp(next); > + #endif > + } > + } else { > + #ifdef ASSERT > + __ testptr(tmp, tmp); > + __ jccb(Assembler::notZero, update); > + __ stop("unexpect null obj"); > + #endif > + } > > for example: > > + if (do_update) { > + #ifndef ASSERT > + __ jmpb(next); > + } > + #else > + __ jmp(next); > + } > + } else { > + __ testptr(tmp, tmp); > + __ jccb(Assembler::notZero, update); > + __ stop("unexpect null obj"); > + #endif > + } > > Indention in c1_LIRGenerator.cpp in sig_next_klass(): > > + if (first_sig_k != NULL) { > + sig_k = first_sig_k; > + first_sig_k = NULL; > > > java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). > > TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. TypeProfileLeveL? > > Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. > > Thanks, > Vladimir > > On 10/2/13 10:02 AM, Roland Westrelin wrote: >> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. >> >> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >> >> The output of -XX:+PrintMethodData is: >> >> 6 invokevirtual 2 >> 0 bci: 6 VirtualCallData count(0) entries(1) >> 'TestProfiling'(4746 1.00) >> argument types 0: stack(1) 'TestProfiling$C' >> 1: stack(2) unknown (null seen) >> >> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. >> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >> >> Roland. >> >> From morris.meyer at oracle.com Mon Oct 7 08:51:26 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Mon, 07 Oct 2013 11:51:26 -0400 Subject: RFR(S): 8008242: VerifyOops fails on SPARC Message-ID: <5252D87E.5060605@oracle.com> Folks, Could I get a review of this P2 issue on SPARC? I had to fix some branch relocation issues first, before relaxing the oop verify in c1_LIRAssembler_sparc::type_profile_helper() and mem2reg(). This has been tested through JPRT. Thanks. --mm JBS - https://bugs.openjdk.java.net/browse/JDK-8008242 WEBREV - http://cr.openjdk.java.net/~morris/8008242.01/ From roland.westrelin at oracle.com Mon Oct 7 09:11:27 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 7 Oct 2013 18:11:27 +0200 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <5252D87E.5060605@oracle.com> References: <5252D87E.5060605@oracle.com> Message-ID: <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> Hi Morris, > Could I get a review of this P2 issue on SPARC? I had to fix some branch relocation issues first, before relaxing the oop verify in c1_LIRAssembler_sparc::type_profile_helper() and mem2reg(). Why did you change: 1391 __ verify_oop(src); in c1_LIRAssembler_sparc.cpp? It appears verify_klass_ptr() doesn't do anything currently so that nothing fails with this changed doesn't really prove it's correct. Roland. From roland.westrelin at oracle.com Mon Oct 7 09:18:15 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 7 Oct 2013 18:18:15 +0200 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: <5252BE6C.5070705@oracle.com> References: <5252BE6C.5070705@oracle.com> Message-ID: <967D916F-DCD6-4672-9960-782C95BA7B66@oracle.com> Hi Niclas, > The uninitialized pointer 'Reachblock' can be replaced with NULL at the call since the node we are re-materializing will not have any live range input (because of contains_no_live_range_input(def)). > > WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8013830/webrev00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8013830 Can you give more details? Which test in PhaseChaitin::split_Rematerialize() fails/succeeds so that we don't reach 378 assert(Reachblock != NULL, "Reachblock must be non-NULL"); 379 Node *rdef = Reachblock[lrg2reach[lidx]]; when contains_no_live_range_input(def)is true? Roland. From niclas.adlertz at oracle.com Mon Oct 7 10:14:23 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Mon, 07 Oct 2013 19:14:23 +0200 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: <967D916F-DCD6-4672-9960-782C95BA7B66@oracle.com> References: <5252BE6C.5070705@oracle.com> <967D916F-DCD6-4672-9960-782C95BA7B66@oracle.com> Message-ID: <5252EBEF.1030200@oracle.com> Hi, At row 1330 in reg_split.cpp we check if we can split by re-materializing 'def'. We only enter split_Rematerialize() at row 1341 if the 'def' node doesn't have any live range inputs (contains_no_live_range_input(def)). This means that the condition at split_Rematerialize() at row 377 will never be true when entering from row 1341. Because of this we can pass in NULL at the call on row 1341 instead of the uninitialized pointer 'Reachblock'. Kind Regards, Niclas Adlertz On 2013-10-07 18:18, Roland Westrelin wrote: > Hi Niclas, > >> The uninitialized pointer 'Reachblock' can be replaced with NULL at the call since the node we are re-materializing will not have any live range input (because of contains_no_live_range_input(def)). >> >> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8013830/webrev00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8013830 > > Can you give more details? Which test in PhaseChaitin::split_Rematerialize() fails/succeeds so that we don't reach > > 378 assert(Reachblock != NULL, "Reachblock must be non-NULL"); > 379 Node *rdef = Reachblock[lrg2reach[lidx]]; > > when contains_no_live_range_input(def)is true? > > Roland. > From christian.thalinger at oracle.com Mon Oct 7 10:55:51 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Oct 2013 10:55:51 -0700 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> References: <5252D87E.5060605@oracle.com> <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> Message-ID: <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> On Oct 7, 2013, at 9:11 AM, Roland Westrelin wrote: > > Hi Morris, > >> Could I get a review of this P2 issue on SPARC? I had to fix some branch relocation issues first, before relaxing the oop verify in c1_LIRAssembler_sparc::type_profile_helper() and mem2reg(). > > Why did you change: > > 1391 __ verify_oop(src); > > in c1_LIRAssembler_sparc.cpp? I concur. Did you hit a problem here? The check is guarded by: if (addr->base()->type() == T_OBJECT) { - __ verify_oop(src); + __ verify_klass_ptr(src); } so this should trigger. If it does then we are propagating the wrong type somewhere. > > It appears verify_klass_ptr() doesn't do anything currently so that nothing fails with this changed doesn't really prove it's correct. Correct; these methods are currently empty. When the runtime team removed perm-gen they added these methods but never implemented them. Not our issue. But the second change is definitely correct; the receiver is a Klass*. > > Roland. > From christian.thalinger at oracle.com Mon Oct 7 11:05:46 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Oct 2013 11:05:46 -0700 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: <5252EBEF.1030200@oracle.com> References: <5252BE6C.5070705@oracle.com> <967D916F-DCD6-4672-9960-782C95BA7B66@oracle.com> <5252EBEF.1030200@oracle.com> Message-ID: <7491BC5B-404E-459C-8F1C-2D3FEAF29EE5@oracle.com> This seems to be ok. The thing that's non-obvious is that: if (def->rematerialize() && contains_no_live_range_input(def)) { and the logic in PhaseChaitin::split_Rematerialize with: if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { are equivalent. The assert helps, though. On Oct 7, 2013, at 10:14 AM, Niclas Adlertz wrote: > Hi, > > At row 1330 in reg_split.cpp we check if we can split by re-materializing 'def'. We only enter split_Rematerialize() at row 1341 if the 'def' node doesn't have any live range inputs (contains_no_live_range_input(def)). > This means that the condition at split_Rematerialize() at row 377 will never be true when entering from row 1341. Because of this we can pass in NULL at the call on row 1341 instead of the uninitialized pointer 'Reachblock'. > > Kind Regards, > Niclas Adlertz > > > On 2013-10-07 18:18, Roland Westrelin wrote: >> Hi Niclas, >> >>> The uninitialized pointer 'Reachblock' can be replaced with NULL at the call since the node we are re-materializing will not have any live range input (because of contains_no_live_range_input(def)). >>> >>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8013830/webrev00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8013830 >> >> Can you give more details? Which test in PhaseChaitin::split_Rematerialize() fails/succeeds so that we don't reach >> >> 378 assert(Reachblock != NULL, "Reachblock must be non-NULL"); >> 379 Node *rdef = Reachblock[lrg2reach[lidx]]; >> >> when contains_no_live_range_input(def)is true? >> >> Roland. >> > From albert.noll at oracle.com Mon Oct 7 11:15:11 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 07 Oct 2013 20:15:11 +0200 Subject: RFR(XS): 8024008: Nashorn V8 (Crypto) benchmark crashes with small CodeCache size In-Reply-To: <524DC536.5030602@oracle.com> References: <522DD453.4010809@oracle.com> <522E09C4.1070700@oracle.com> <522EC44F.2060005@oracle.com> <522F1612.4030606@oracle.com> <522FA629.10509@oracle.com> <524DB4B6.7040201@oracle.com> <524DC536.5030602@oracle.com> Message-ID: <5252FA2F.6050102@oracle.com> Hi Valdimir, thanks for you feedback. If the generation of the AdapterHandlerLibrary wrapper is optional, the following changes in compileBroker.cpp should work: // If the compiler is shut off due to code cache getting full // fail out now so blocking compiles dont hang the java thread // if ( !should_compile_new_jobs()) { // CompilationPolicy::policy()->delay_compilation(method()); // return NULL; // } // do the compilation if (method->is_native()) { if (!PreferInterpreterNativeStubs || method->is_method_handle_intrinsic()) { // Acquire our lock. // int compile_id; // { // MutexLocker locker(MethodCompileQueue_lock, THREAD); // compile_id = assign_compile_id(method, standard_entry_bci); // } // (void) AdapterHandlerLibrary::create_native_wrapper(method, compile_id); } else { return NULL; } } else { compile_method_base(method, osr_bci, comp_level, hot_method, hot_count, comment, THREAD); } However, with the changes above, I get the "i2c adapter must return to an interpreter frame" even if the code cache is not full and compilation remains enabled. Something seems really broken here. Irrespective of the current bug, it seems that checking whether we should compile new methods in line 1304 in compileBroker.cpp does not make much sense, since this bit can change asynchronously any time. It made more sense before 8020151, but now I think it is time to remove it. Best, Albert On 03.10.2013 21:27, Vladimir Kozlov wrote: > Albert, > > I don't see connection between not generating wrapper (which is fine, > it is only needed for hot calls to native method) and wrong return > address when calling i2c adapter (failed message). Can you find what > return address is? > > It could be a different problem (or not) from what this bug about. > Several things can go bad when codecache is full. Also attached to bug > report hs_err files shows different crushes. > > Was you able to reproduce it with fastdebug VM? Switch off > -XX:-CheckCompressedOops to get the same code generation as with > product 64-bit VM. And switch off -XX:-VerifyDependencies to speed > testing (10x, this test is very expensive). > > Also can you try to run with latest VM version which has fixes to > produce more info for call stack in hs_err. To have only next lines is > not useful: > > C 0x0000000648baace0 > [error occurred during error reporting (printing native stack), id 0xb] > > Thanks, > Vladimir > > On 10/3/13 11:17 AM, Albert Noll wrote: >> Hi, >> >> I think I found the reason for the crash. Please forget the previous >> suggestions. >> >> See the following webrev: >> >> Problem: >> http://cr.openjdk.java.net/~anoll/8024008/webrev.02/ >> >> If the code cache gets full, this code in compileBroker.cpp is not >> executed. >> >> 1318 (void) >> AdapterHandlerLibrary::create_native_wrapper(method, compile_id); >> >> As a result, we get the following error "i2c adapter must return to >> an interpreter frame" >> if the JVM is called with "-XX:+UnlockDiagnosticVMOptions >> -XX:+VerifyAdapterCalls" >> >> I do not yet fully understand why that's the case, so please if you >> know let me know. >> >> Solution: >> Move the code cache is full-check after line 1318. >> >> Many thanks, >> Albert >> >> >> Am 11.09.2013 01:07, schrieb Vladimir Kozlov: >>> Albert, >>> >>> I would suggest to run as many tests as possible to verify correctness >>> of changes because this code is very important. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/10/13 5:52 AM, Albert Noll wrote: >>>> Hi, >>>> >>>> the current version causes a serious performance regression. >>>> I have to figure out what's wrong. >>>> >>>> Best, >>>> Albert >>>> >>>> On 10.09.2013 09:03, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks for looking at this. I checked all call sites of >>>>> 'make_not_entrant()' and 'make_zombie()'. I do not see any problems. >>>>> The worst thing that can happen is that an nmethod for which the call >>>>> returns fals gets removed later than expected. >>>>> >>>>> I updated the comment and did some minor code refactoring. >>>>> >>>>> Also I think that it is worth considering to backport this change, >>>>> since the bug can appear any time >>>>> the code cache fills up. If that bug appears, it is extremely hard to >>>>> reproduce and debug. >>>>> >>>>> Here is the updated webrev. >>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.01/ >>>>> >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> >>>>> On 09.09.2013 19:47, Vladimir Kozlov wrote: >>>>>> Several places in sources do not check returned result of >>>>>> make_not_entrant_or_zombie(). And they may assume that method marked >>>>>> as non-entrant, for example, because before we returned 'false' only >>>>>> when an other thread already changed the state to one we need. >>>>>> >>>>>> Can you check all call sites to make sure they work correctly with >>>>>> this change? >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/9/13 6:59 AM, Albert Noll wrote: >>>>>>> Hi, >>>>>>> >>>>>>> thanks for reviewing this patch. >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024008 >>>>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Many thanks in advance, >>>>>>> Albert >>>>>>> >>>>>>> Problem: >>>>>>> The state of nmethods that are currently locked by the VM must not >>>>>>> change. >>>>>>> Some operations such as setting ICs (e.g., >>>>>>> SharedRuntime::resolve_sub_helper()) >>>>>>> rely on this fact. 'nmethod::make_not_entrant_or_zombie does not >>>>>>> make this >>>>>>> check. >>>>>>> >>>>>>> Solution: >>>>>>> Do method state unchanged of nmethod is locked by the VM. >>>>>>> >>>>>>> Testing: Run Octane benchmarks on top of Nashorn with small code >>>>>>> cache size (16m). >>>>>>> >>>>> >>>> >> From vladimir.kozlov at oracle.com Mon Oct 7 12:31:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Oct 2013 12:31:08 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> Message-ID: <52530BFC.9040201@oracle.com> Rickard, Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? addExact(x,y) addExact(x,y) Thanks, Vladimir On 10/6/13 10:13 PM, Rickard B?ckman wrote: > Vladimir, > > both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 > uses of addExact this seems to be problematic. > > The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. > > Thank you > /R > > On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: > >> Rickard, >> >> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >> >> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >> >> Vladimir >> >> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>> Hi all, >>> >>> I would appreciate some reviews on this change. >>> >>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>> assert(idx >= 0) failed: index should be set >>> >>> It seems that gcm would put the addExact in a different block then the jump. >>> This change forces the producer of FlagsProjNode to be in the same block as >>> the consumer. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>> >>> Thanks >>> /R >>> > From vladimir.kozlov at oracle.com Mon Oct 7 12:46:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Oct 2013 12:46:23 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <6501BAF7-D1C6-4777-BE47-F77047853B12@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <524F95D6.9090200@oracle.com> <6501BAF7-D1C6-4777-BE47-F77047853B12@oracle.com> Message-ID: <52530F8F.8060800@oracle.com> On 10/5/13 2:58 AM, Roland Westrelin wrote: > > On Oct 5, 2013, at 6:30 AM, Vladimir Kozlov wrote: > >> >> >> On 10/4/13 5:59 PM, Vladimir Kozlov wrote: >>> Roland, >>> >>> I need more time to go through methoddate.?pp changes. >>> Here some preliminary comments. >>> >>> I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could >>> be set by other thread during small window. But it is still not atomic. >> >> We can't use orptr for klass record because other thread may store an other klass. As result we will get garbage value. So need to use mov. How expensive will be cmpxchg? I am just worried that we can't trust this type info due to concurrency. > > Why is it such concern in the case? Other profiling may also miss events due to concurrency (counter not updated, lost receiver at a call/type check). In the new code, we set the null bit only once, the recorded class only once, the unknown bit only once. It's true we can miss one of those events, but most likely the event will occur again and it can't be lost more than twice, I would say (because each of the events is recorded only once). So only a very rare event can be lost for good. We start profiling after several invocations of the method, so in practice we already risk loosing rare events. And in any case, we risk making a wrong assumption at compile time that we can recover from but not generate erroneous code. > To me, concurrency when counters are incremented must be much more of an issue. We risk repeatedly loosing events and end up with wrong relative frequencies. I agree with you about klass recording because we will generate klass check so the code will be correct even if recording is wrong (we go slow path). The same about unknown bit. I looked on never_see_null code in GraphKit::null_check_oop() and we generate uncommon trap otherwise merged result could be NULL. So it seems we will hit uncommon trap if we lost null_seen bit. Looks like we fine. Thanks, Vladimir > > Roland. > >> >> Vladimir >> >>> It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not >>> change, may be split in 2 field). Or may be use atomic cmpxchg. >>> Then we would not worry about concurrent updates from different threads. >>> >>> c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: >>> >>> + if (do_update) { >>> + #ifndef ASSERT >>> + __ jmpb(next); >>> + #else >>> + __ jmp(next); >>> + #endif >>> + } >>> + } else { >>> + #ifdef ASSERT >>> + __ testptr(tmp, tmp); >>> + __ jccb(Assembler::notZero, update); >>> + __ stop("unexpect null obj"); >>> + #endif >>> + } >>> >>> for example: >>> >>> + if (do_update) { >>> + #ifndef ASSERT >>> + __ jmpb(next); >>> + } >>> + #else >>> + __ jmp(next); >>> + } >>> + } else { >>> + __ testptr(tmp, tmp); >>> + __ jccb(Assembler::notZero, update); >>> + __ stop("unexpect null obj"); >>> + #endif >>> + } >>> >>> Indention in c1_LIRGenerator.cpp in sig_next_klass(): >>> >>> + if (first_sig_k != NULL) { >>> + sig_k = first_sig_k; >>> + first_sig_k = NULL; >>> >>> >>> java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more >>> statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). >>> >>> TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. >>> TypeProfileLeveL? >>> >>> Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/2/13 10:02 AM, Roland Westrelin wrote: >>>> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes >>>> tiered support on 32bit and 64bit x86. >>>> >>>> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >>>> >>>> The output of -XX:+PrintMethodData is: >>>> >>>> 6 invokevirtual 2 >>>> 0 bci: 6 VirtualCallData count(0) entries(1) >>>> 'TestProfiling'(4746 1.00) >>>> argument types 0: stack(1) 'TestProfiling$C' >>>> 1: stack(2) unknown (null seen) >>>> >>>> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda >>>> form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >>>> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to >>>> use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 >>>> etc. >>>> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >>>> >>>> Roland. >>>> >>>> > From christian.thalinger at oracle.com Mon Oct 7 13:49:56 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Oct 2013 13:49:56 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> Message-ID: <60593E1C-9B90-494F-A62A-4A9D2F40EAAC@oracle.com> src/share/vm/ci/ciStreams.hpp: + if (_holder != NULL) { + sig_k = _holder; + _holder = NULL; + } else { Instead of clearing _holder can you use pos to see if we are at the first position? src/share/vm/runtime/signature.cpp: + int SignatureStream::reference_parameter_count(int max) { Don't pass in max. This is only applicable to your use case. Do the max check inline. + profiled_k = TypeEntries::with_status((intptr_t)result, profiled_k); + return TypeEntries::with_status((intptr_t)klass, k); These two still use the intptr_t version. On Oct 7, 2013, at 7:46 AM, Roland Westrelin wrote: > Vladimir, Thanks for your comments. > >> I need more time to go through methoddate.?pp changes. > > Sure. Here is a new webrev that addresses Christian's comments and yours below. > > http://cr.openjdk.java.net/~roland/8023657/webrev.02/ > >> Here some preliminary comments. >> >> I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could be set by other thread during small window. But it is still not atomic. >> It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not change, may be split in 2 field). Or may be use atomic cmpxchg. > > In one of the follow up changes I will do profiling of the type of return values. For them there's not need of keeping track of the stack slot so we can't assume that there's an extra entry in the MDO for each type. > > Roland. > >> Then we would not worry about concurrent updates from different threads. >> >> c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: >> >> + if (do_update) { >> + #ifndef ASSERT >> + __ jmpb(next); >> + #else >> + __ jmp(next); >> + #endif >> + } >> + } else { >> + #ifdef ASSERT >> + __ testptr(tmp, tmp); >> + __ jccb(Assembler::notZero, update); >> + __ stop("unexpect null obj"); >> + #endif >> + } >> >> for example: >> >> + if (do_update) { >> + #ifndef ASSERT >> + __ jmpb(next); >> + } >> + #else >> + __ jmp(next); >> + } >> + } else { >> + __ testptr(tmp, tmp); >> + __ jccb(Assembler::notZero, update); >> + __ stop("unexpect null obj"); >> + #endif >> + } >> >> Indention in c1_LIRGenerator.cpp in sig_next_klass(): >> >> + if (first_sig_k != NULL) { >> + sig_k = first_sig_k; >> + first_sig_k = NULL; >> >> >> java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). >> >> TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. TypeProfileLeveL? >> >> Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. >> >> Thanks, >> Vladimir >> >> On 10/2/13 10:02 AM, Roland Westrelin wrote: >>> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. >>> >>> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >>> >>> The output of -XX:+PrintMethodData is: >>> >>> 6 invokevirtual 2 >>> 0 bci: 6 VirtualCallData count(0) entries(1) >>> 'TestProfiling'(4746 1.00) >>> argument types 0: stack(1) 'TestProfiling$C' >>> 1: stack(2) unknown (null seen) >>> >>> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >>> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. >>> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >>> >>> Roland. >>> >>> > From roland.westrelin at oracle.com Mon Oct 7 14:09:03 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 7 Oct 2013 23:09:03 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <60593E1C-9B90-494F-A62A-4A9D2F40EAAC@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> <60593E1C-9B90-494F-A62A-4A9D2F40EAAC@oracle.com> Message-ID: <4AEE1470-BFBA-421E-9E09-155B9B0D7CBC@oracle.com> On Oct 7, 2013, at 10:49 PM, Christian Thalinger wrote: > src/share/vm/ci/ciStreams.hpp: > > + if (_holder != NULL) { > + sig_k = _holder; > + _holder = NULL; > + } else { > > Instead of clearing _holder can you use pos to see if we are at the first position? if _holder != NULL, then _pos = 0 is first true when it returns _holder and then _pos = 0 is true again for the actual first position in the signature so it's not that simple. You need a way to know you've done the _holder at the previous call and this call is for _pos = 0; > src/share/vm/runtime/signature.cpp: > > + int SignatureStream::reference_parameter_count(int max) { > > Don't pass in max. This is only applicable to your use case. Do the max check inline. I'm not sure what you mean by "inline". Iterate over the entire signature and keep the MIN of the value returned and TypeProfileArgsLimit? Passing max doesn't look that bad to me. > + profiled_k = TypeEntries::with_status((intptr_t)result, profiled_k); > > + return TypeEntries::with_status((intptr_t)klass, k); > > These two still use the intptr_t version. Because they are passed a ciKlass* and not Klass*. One more version with ciKlass* would be needed. Roland. > > On Oct 7, 2013, at 7:46 AM, Roland Westrelin wrote: > >> Vladimir, Thanks for your comments. >> >>> I need more time to go through methoddate.?pp changes. >> >> Sure. Here is a new webrev that addresses Christian's comments and yours below. >> >> http://cr.openjdk.java.net/~roland/8023657/webrev.02/ >> >>> Here some preliminary comments. >>> >>> I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could be set by other thread during small window. But it is still not atomic. >>> It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not change, may be split in 2 field). Or may be use atomic cmpxchg. >> >> In one of the follow up changes I will do profiling of the type of return values. For them there's not need of keeping track of the stack slot so we can't assume that there's an extra entry in the MDO for each type. >> >> Roland. >> >>> Then we would not worry about concurrent updates from different threads. >>> >>> c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: >>> >>> + if (do_update) { >>> + #ifndef ASSERT >>> + __ jmpb(next); >>> + #else >>> + __ jmp(next); >>> + #endif >>> + } >>> + } else { >>> + #ifdef ASSERT >>> + __ testptr(tmp, tmp); >>> + __ jccb(Assembler::notZero, update); >>> + __ stop("unexpect null obj"); >>> + #endif >>> + } >>> >>> for example: >>> >>> + if (do_update) { >>> + #ifndef ASSERT >>> + __ jmpb(next); >>> + } >>> + #else >>> + __ jmp(next); >>> + } >>> + } else { >>> + __ testptr(tmp, tmp); >>> + __ jccb(Assembler::notZero, update); >>> + __ stop("unexpect null obj"); >>> + #endif >>> + } >>> >>> Indention in c1_LIRGenerator.cpp in sig_next_klass(): >>> >>> + if (first_sig_k != NULL) { >>> + sig_k = first_sig_k; >>> + first_sig_k = NULL; >>> >>> >>> java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). >>> >>> TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. TypeProfileLeveL? >>> >>> Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/2/13 10:02 AM, Roland Westrelin wrote: >>>> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. >>>> >>>> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >>>> >>>> The output of -XX:+PrintMethodData is: >>>> >>>> 6 invokevirtual 2 >>>> 0 bci: 6 VirtualCallData count(0) entries(1) >>>> 'TestProfiling'(4746 1.00) >>>> argument types 0: stack(1) 'TestProfiling$C' >>>> 1: stack(2) unknown (null seen) >>>> >>>> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >>>> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. >>>> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >>>> >>>> Roland. >>>> >>>> >> > From christian.thalinger at oracle.com Mon Oct 7 15:04:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 7 Oct 2013 15:04:34 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <4AEE1470-BFBA-421E-9E09-155B9B0D7CBC@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> <60593E1C-9B90-494F-A62A-4A9D2F40EAAC@oracle.com> <4AEE1470-BFBA-421E-9E09-155B9B0D7CBC@oracle.com> Message-ID: On Oct 7, 2013, at 2:09 PM, Roland Westrelin wrote: > > On Oct 7, 2013, at 10:49 PM, Christian Thalinger wrote: > >> src/share/vm/ci/ciStreams.hpp: >> >> + if (_holder != NULL) { >> + sig_k = _holder; >> + _holder = NULL; >> + } else { >> >> Instead of clearing _holder can you use pos to see if we are at the first position? > > > if _holder != NULL, then _pos = 0 is first true when it returns _holder and then _pos = 0 is true again for the actual first position in the signature so it's not that simple. You need a way to know you've done the _holder at the previous call and this call is for _pos = 0; Right. I missed that. I thought it would be nice for debugging to keep the holder around. > >> src/share/vm/runtime/signature.cpp: >> >> + int SignatureStream::reference_parameter_count(int max) { >> >> Don't pass in max. This is only applicable to your use case. Do the max check inline. > > I'm not sure what you mean by "inline". > Iterate over the entire signature and keep the MIN of the value returned and TypeProfileArgsLimit? Just return the number of reference parameters. > Passing max doesn't look that bad to me. Passing a max doesn't make sense for anyone else using this method in the future. The only answer I want back is the number of reference parameters. > >> + profiled_k = TypeEntries::with_status((intptr_t)result, profiled_k); >> >> + return TypeEntries::with_status((intptr_t)klass, k); >> >> These two still use the intptr_t version. > > Because they are passed a ciKlass* and not Klass*. One more version with ciKlass* would be needed. Please add that one too. > > Roland. > >> >> On Oct 7, 2013, at 7:46 AM, Roland Westrelin wrote: >> >>> Vladimir, Thanks for your comments. >>> >>>> I need more time to go through methoddate.?pp changes. >>> >>> Sure. Here is a new webrev that addresses Christian's comments and yours below. >>> >>> http://cr.openjdk.java.net/~roland/8023657/webrev.02/ >>> >>>> Here some preliminary comments. >>>> >>>> I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could be set by other thread during small window. But it is still not atomic. >>>> It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not change, may be split in 2 field). Or may be use atomic cmpxchg. >>> >>> In one of the follow up changes I will do profiling of the type of return values. For them there's not need of keeping track of the stack slot so we can't assume that there's an extra entry in the MDO for each type. >>> >>> Roland. >>> >>>> Then we would not worry about concurrent updates from different threads. >>>> >>>> c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: >>>> >>>> + if (do_update) { >>>> + #ifndef ASSERT >>>> + __ jmpb(next); >>>> + #else >>>> + __ jmp(next); >>>> + #endif >>>> + } >>>> + } else { >>>> + #ifdef ASSERT >>>> + __ testptr(tmp, tmp); >>>> + __ jccb(Assembler::notZero, update); >>>> + __ stop("unexpect null obj"); >>>> + #endif >>>> + } >>>> >>>> for example: >>>> >>>> + if (do_update) { >>>> + #ifndef ASSERT >>>> + __ jmpb(next); >>>> + } >>>> + #else >>>> + __ jmp(next); >>>> + } >>>> + } else { >>>> + __ testptr(tmp, tmp); >>>> + __ jccb(Assembler::notZero, update); >>>> + __ stop("unexpect null obj"); >>>> + #endif >>>> + } >>>> >>>> Indention in c1_LIRGenerator.cpp in sig_next_klass(): >>>> >>>> + if (first_sig_k != NULL) { >>>> + sig_k = first_sig_k; >>>> + first_sig_k = NULL; >>>> >>>> >>>> java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). >>>> >>>> TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. TypeProfileLeveL? >>>> >>>> Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/2/13 10:02 AM, Roland Westrelin wrote: >>>>> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. >>>>> >>>>> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >>>>> >>>>> The output of -XX:+PrintMethodData is: >>>>> >>>>> 6 invokevirtual 2 >>>>> 0 bci: 6 VirtualCallData count(0) entries(1) >>>>> 'TestProfiling'(4746 1.00) >>>>> argument types 0: stack(1) 'TestProfiling$C' >>>>> 1: stack(2) unknown (null seen) >>>>> >>>>> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >>>>> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. >>>>> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >>>>> >>>>> Roland. >>>>> >>>>> >>> >> > From christian.thalinger at oracle.com Mon Oct 7 15:19:04 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Mon, 07 Oct 2013 22:19:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Message-ID: <20131007221909.56A9762E17@hg.openjdk.java.net> Changeset: c775af091fe9 Author: twisti Date: 2013-10-07 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c775af091fe9 8025566: EXCEPTION_ACCESS_VIOLATION in compiled by C1 String.valueOf method Reviewed-by: kvn ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/parseHelper.cpp From vladimir.kozlov at oracle.com Mon Oct 7 18:40:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 07 Oct 2013 18:40:35 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> Message-ID: <52536293.6030606@oracle.com> Roland, I looked through code in methoddate.?pp and I think it is fine. Assembler code also good. So changes are fine from what I see. And we already discussed recorded state. Thanks, Vladimir On 10/7/13 7:46 AM, Roland Westrelin wrote: > Vladimir, Thanks for your comments. > >> I need more time to go through methoddate.?pp changes. > > Sure. Here is a new webrev that addresses Christian's comments and yours below. > > http://cr.openjdk.java.net/~roland/8023657/webrev.02/ > >> Here some preliminary comments. >> >> I think you need to use orptr(mdo_adr, obj) when storing klass first time to preserve sticky bit null_seen which could be set by other thread during small window. But it is still not atomic. >> It would be even better if you set these sticking flags in a separate field (may be in stack_slot_entry which does not change, may be split in 2 field). Or may be use atomic cmpxchg. > > In one of the follow up changes I will do profiling of the type of return values. For them there's not need of keeping track of the stack slot so we can't assume that there's an extra entry in the MDO for each type. > > Roland. > >> Then we would not worry about concurrent updates from different threads. >> >> c1_LIRAssembler_x86.cpp: could you clean up ifdefs?: >> >> + if (do_update) { >> + #ifndef ASSERT >> + __ jmpb(next); >> + #else >> + __ jmp(next); >> + #endif >> + } >> + } else { >> + #ifdef ASSERT >> + __ testptr(tmp, tmp); >> + __ jccb(Assembler::notZero, update); >> + __ stop("unexpect null obj"); >> + #endif >> + } >> >> for example: >> >> + if (do_update) { >> + #ifndef ASSERT >> + __ jmpb(next); >> + } >> + #else >> + __ jmp(next); >> + } >> + } else { >> + __ testptr(tmp, tmp); >> + __ jccb(Assembler::notZero, update); >> + __ stop("unexpect null obj"); >> + #endif >> + } >> >> Indention in c1_LIRGenerator.cpp in sig_next_klass(): >> >> + if (first_sig_k != NULL) { >> + sig_k = first_sig_k; >> + first_sig_k = NULL; >> >> >> java.cpp can you also print mdo size per method before (or after) invocation counters? I assume you want to print more statistic with new flag later. If it is only size then we may not need a new flag (we have too many of them already). >> >> TypeProfile is very general name and can be confusing. Current code already does type profiling: UseTypeProfile. TypeProfileLeveL? >> >> Also add new flags into /* compiler */ section of globals.hpp where other TypeProfile flags are defined. >> >> Thanks, >> Vladimir >> >> On 10/2/13 10:02 AM, Roland Westrelin wrote: >>> Here is a new webrev for the new profiling points, only profiling of arguments at calls this time. This one includes tiered support on 32bit and 64bit x86. >>> >>> http://cr.openjdk.java.net/~roland/8023657/webrev.01/ >>> >>> The output of -XX:+PrintMethodData is: >>> >>> 6 invokevirtual 2 >>> 0 bci: 6 VirtualCallData count(0) entries(1) >>> 'TestProfiling'(4746 1.00) >>> argument types 0: stack(1) 'TestProfiling$C' >>> 1: stack(2) unknown (null seen) >>> >>> Profiling can either be off, on only for jsr292 related calls (invokedynamic, invokehandle or all invokes in a lambda form) or on for all methods and invokes. -XX:TypeProfile={0,1,2} is used to pick a level of profiling. >>> Once all profiling is in (arguments, parameters, return value), in order to limit the number of options my plan is to use TypeProfile=xyz, with x,y,z in {0,1,2} to select the level of profiling for each. TypeProfile=111, Typeprofile=222 etc. >>> Profiling is by default on only for jsr292 related calls in order to not impact startup/footprint of standard java apps. >>> >>> Roland. >>> >>> > From roland.westrelin at oracle.com Tue Oct 8 03:03:31 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 08 Oct 2013 10:03:31 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8024067: Missing replace_in_map() calls following null checks Message-ID: <20131008100350.54D2262E28@hg.openjdk.java.net> Changeset: d9043b88eeb3 Author: roland Date: 2013-10-03 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d9043b88eeb3 8024067: Missing replace_in_map() calls following null checks Summary: add replace_in_map() calls following some null checks in type checks Reviewed-by: kvn ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp From roland.westrelin at oracle.com Tue Oct 8 05:06:49 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Oct 2013 14:06:49 +0200 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: <5252EBEF.1030200@oracle.com> References: <5252BE6C.5070705@oracle.com> <967D916F-DCD6-4672-9960-782C95BA7B66@oracle.com> <5252EBEF.1030200@oracle.com> Message-ID: > At row 1330 in reg_split.cpp we check if we can split by re-materializing 'def'. We only enter split_Rematerialize() at row 1341 if the 'def' node doesn't have any live range inputs (contains_no_live_range_input(def)). > This means that the condition at split_Rematerialize() at row 377 will never be true when entering from row 1341. Because of this we can pass in NULL at the call on row 1341 instead of the uninitialized pointer 'Reachblock'. Thanks for the explanation. That looks good to me then. Roland. From roland.westrelin at oracle.com Tue Oct 8 05:11:50 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Oct 2013 14:11:50 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> <60593E1C-9B90-494F-A62A-4A9D2F40EAAC@oracle.com> <4AEE1470-BFBA-421E-9E09-155B9B0D7CBC@oracle.com> Message-ID: <1E39D79B-5562-465F-9FE4-F02CB5B34B04@oracle.com> Here is a new webrev with Chris' last suggestions: http://cr.openjdk.java.net/~roland/8023657/webrev.03/ Roland. From roland.westrelin at oracle.com Tue Oct 8 05:12:07 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Oct 2013 14:12:07 +0200 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <52536293.6030606@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> <52536293.6030606@oracle.com> Message-ID: <48D9C2AC-A8B8-4ECD-9D51-F9B0596ADD31@oracle.com> > I looked through code in methoddate.?pp and I think it is fine. > Assembler code also good. So changes are fine from what I see. And we already discussed recorded state. Thanks, Vladimir. Roland. From niclas.adlertz at oracle.com Tue Oct 8 06:11:28 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 08 Oct 2013 15:11:28 +0200 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: References: <5252BE6C.5070705@oracle.com> <967D916F-DCD6-4672-9960-782C95BA7B66@oracle.com> <5252EBEF.1030200@oracle.com> Message-ID: <52540480.6070503@oracle.com> Thank you Roland. Kind Regards, Niclas Adlertz On 2013-10-08 14:06, Roland Westrelin wrote: >> At row 1330 in reg_split.cpp we check if we can split by re-materializing 'def'. We only enter split_Rematerialize() at row 1341 if the 'def' node doesn't have any live range inputs (contains_no_live_range_input(def)). >> This means that the condition at split_Rematerialize() at row 377 will never be true when entering from row 1341. Because of this we can pass in NULL at the call on row 1341 instead of the uninitialized pointer 'Reachblock'. > > Thanks for the explanation. That looks good to me then. > > Roland. > From morris.meyer at oracle.com Tue Oct 8 06:34:00 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 08 Oct 2013 09:34:00 -0400 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> References: <5252D87E.5060605@oracle.com> <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> Message-ID: <525409C8.8080801@oracle.com> Thanks for the bringing that up Roland and Christian. I fixed this issue and re-ran the change through JPRT. Here's the patch. --morris WEBREV - http://cr.openjdk.java.net/8008242.02 On 10/7/13, 1:55 PM, Christian Thalinger wrote: > On Oct 7, 2013, at 9:11 AM, Roland Westrelin wrote: > >> Hi Morris, >> >>> Could I get a review of this P2 issue on SPARC? I had to fix some branch relocation issues first, before relaxing the oop verify in c1_LIRAssembler_sparc::type_profile_helper() and mem2reg(). >> Why did you change: >> >> 1391 __ verify_oop(src); >> >> in c1_LIRAssembler_sparc.cpp? > I concur. Did you hit a problem here? The check is guarded by: > > if (addr->base()->type() == T_OBJECT) { > - __ verify_oop(src); > + __ verify_klass_ptr(src); > } > > so this should trigger. If it does then we are propagating the wrong type somewhere. > >> It appears verify_klass_ptr() doesn't do anything currently so that nothing fails with this changed doesn't really prove it's correct. > Correct; these methods are currently empty. When the runtime team removed perm-gen they added these methods but never implemented them. Not our issue. But the second change is definitely correct; the receiver is a Klass*. > >> Roland. >> From vladimir.kozlov at oracle.com Tue Oct 8 09:18:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Oct 2013 09:18:52 -0700 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: <5252BE6C.5070705@oracle.com> References: <5252BE6C.5070705@oracle.com> Message-ID: <5254306C.1050208@oracle.com> Good. Vladimir On 10/7/13 7:00 AM, Niclas Adlertz wrote: > Hi all, > > The uninitialized pointer 'Reachblock' can be replaced with NULL at the > call since the node we are re-materializing will not have any live range > input (because of contains_no_live_range_input(def)). > > WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8013830/webrev00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8013830 > > Kind Regards, > Niclas Adlertz > From roland.westrelin at oracle.com Tue Oct 8 09:22:13 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Oct 2013 18:22:13 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls Message-ID: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ Follow up to 8023657: New type profiling points: arguments to call 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. The output of PrintMethodData is: 17 invokevirtual 3 16 bci: 17 VirtualCallData count(0) entries(1) 'TestProfiling'(4744 1.00) argument types 0: stack(1) 'TestProfiling$C' 1: stack(2) 'TestProfiling$B' return type 'TestProfiling$C' Roland. From roland.westrelin at oracle.com Tue Oct 8 09:31:31 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Oct 2013 18:31:31 +0200 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <525409C8.8080801@oracle.com> References: <5252D87E.5060605@oracle.com> <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> <525409C8.8080801@oracle.com> Message-ID: <8EE536BC-8694-4537-B731-8F0A1EEC3CF1@oracle.com> Hi Morris, > Thanks for the bringing that up Roland and Christian. I fixed this issue and re-ran the change through JPRT. Why do you need to remove it entirely? Has this check caused failures? To me the check looks good and should be kept as it is. Also in your previous change: 2568 __ verify_oop(tmp1); became: 2568 __ verify_klass_ptr(tmp1); and that was good. Roland. From roland.westrelin at oracle.com Tue Oct 8 09:35:24 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Oct 2013 18:35:24 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <52377337.2090105@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <6E39E6D7-F989-4E62-8267-DBAE76E4F76F@oracle.com> <52377337.2090105@oracle.com> Message-ID: <185B61AA-F326-4257-BD08-7AC04488723A@oracle.com> Hi Vladimir, >>> You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types). >> >> Do you mean tests that show an improvement (artificially pollute profiling at a call site and verify that some profiling that dominates the call site helps for instance)? I have such tests but they need manual inspection of the resulting code or inlining. Given the effect of the change has no visible effects at the java level how would I automate testing? Run with -XX:+PrintInlining and parse the output? Have we done that before on other tests? > > No. I just want to test correctness. Something like merging array and instance types, reflection, constant types etc. To make sure your new code in C2 types works correctly (correct inlining). Use test cases which you think can be problematic. Even if a test doesn't fail with your current changes we need it. This is still not clear to me. Do you want tests to test correctness as in no VM crash or correctness as in correctly optimized? Maybe you can sketch a example test? Roland. From morris.meyer at oracle.com Tue Oct 8 09:45:36 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 08 Oct 2013 12:45:36 -0400 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <8EE536BC-8694-4537-B731-8F0A1EEC3CF1@oracle.com> References: <5252D87E.5060605@oracle.com> <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> <525409C8.8080801@oracle.com> <8EE536BC-8694-4537-B731-8F0A1EEC3CF1@oracle.com> Message-ID: <525436B0.10305@oracle.com> Roland, The x86 version of LIR_Assembler::type_profile_helper() does not have a verify_oop() and I removed the SPARC version accordingly. --mm On 10/8/13, 12:31 PM, Roland Westrelin wrote: > Hi Morris, > >> Thanks for the bringing that up Roland and Christian. I fixed this issue and re-ran the change through JPRT. > Why do you need to remove it entirely? Has this check caused failures? To me the check looks good and should be kept as it is. > > Also in your previous change: > > 2568 __ verify_oop(tmp1); > > became: > > 2568 __ verify_klass_ptr(tmp1); > > and that was good. > > Roland. From christian.thalinger at oracle.com Tue Oct 8 10:12:32 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 10:12:32 -0700 Subject: RFR(L): 8023657: New type profiling points: arguments to call In-Reply-To: <1E39D79B-5562-465F-9FE4-F02CB5B34B04@oracle.com> References: <5217E692.8090308@oracle.com> <4A2E28CD-6E92-49E7-B97A-4FCD2D3C5D83@oracle.com> <522A7CC1.9050603@oracle.com> <522E0395.2030906@oracle.com> <8C258BCC-0109-4A6B-9117-501EE62D3AA4@oracle.com> <541BDE20-900D-437A-8A1D-A1201AE2A6EA@oracle.com> <524F6487.8030606@oracle.com> <2C6936C4-ED19-41DB-A98B-28DCF18F88E1@oracle.com> <60593E1C-9B90-494F-A62A-4A9D2F40EAAC@oracle.com> <4AEE1470-BFBA-421E-9E09-155B9B0D7CBC@oracle.com> <1E39D79B-5562-465F-9FE4-F02CB5B34B04@oracle.com> Message-ID: <94FB1181-B497-4EFC-B594-F9E481FA320C@oracle.com> Thank you. Looks good. On Oct 8, 2013, at 5:11 AM, Roland Westrelin wrote: > > Here is a new webrev with Chris' last suggestions: > http://cr.openjdk.java.net/~roland/8023657/webrev.03/ > > Roland. From christian.thalinger at oracle.com Tue Oct 8 10:20:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 10:20:59 -0700 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <525436B0.10305@oracle.com> References: <5252D87E.5060605@oracle.com> <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> <525409C8.8080801@oracle.com> <8EE536BC-8694-4537-B731-8F0A1EEC3CF1@oracle.com> <525436B0.10305@oracle.com> Message-ID: <9BF6FAEC-7728-45C5-BE43-9C45957A31C8@oracle.com> On Oct 8, 2013, at 9:45 AM, Morris Meyer wrote: > Roland, > > The x86 version of LIR_Assembler::type_profile_helper() does not have a verify_oop() and I removed the SPARC version accordingly. Well, the reason that x86 doesn't have that check is because on x86 we can do a memory compare: __ cmpptr(recv, Address(mdo, md->byte_offset_of_slot(data, ReceiverTypeData::receiver_offset(i)))); So we don't have the value in a register to do the check. Please but the verify_klass_ptr check back. > > --mm > > > On 10/8/13, 12:31 PM, Roland Westrelin wrote: >> Hi Morris, >> >>> Thanks for the bringing that up Roland and Christian. I fixed this issue and re-ran the change through JPRT. >> Why do you need to remove it entirely? Has this check caused failures? To me the check looks good and should be kept as it is. >> >> Also in your previous change: >> >> 2568 __ verify_oop(tmp1); >> >> became: >> >> 2568 __ verify_klass_ptr(tmp1); >> >> and that was good. >> >> Roland. > From christian.thalinger at oracle.com Tue Oct 8 10:30:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 10:30:29 -0700 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <525409C8.8080801@oracle.com> References: <5252D87E.5060605@oracle.com> <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> <525409C8.8080801@oracle.com> Message-ID: <6F84855B-10D9-4F36-A69C-2018AA728ECA@oracle.com> We don't need this check (which is wrong btw.): + if (type == T_OBJECT) { + __ verify_oop(dest->as_register()); + } LIR_Assembler::load methods already do that: if (type == T_ARRAY || type == T_OBJECT) { __ verify_oop(to_reg->as_register()); } Once more, why did you remove this one? 1390 if (addr->base()->type() == T_OBJECT) { 1391 __ verify_oop(src); 1392 } On Oct 8, 2013, at 6:34 AM, Morris Meyer wrote: > Thanks for the bringing that up Roland and Christian. I fixed this issue and re-ran the change through JPRT. > > Here's the patch. > > --morris > > WEBREV - http://cr.openjdk.java.net/8008242.02 > > On 10/7/13, 1:55 PM, Christian Thalinger wrote: >> On Oct 7, 2013, at 9:11 AM, Roland Westrelin wrote: >> >>> Hi Morris, >>> >>>> Could I get a review of this P2 issue on SPARC? I had to fix some branch relocation issues first, before relaxing the oop verify in c1_LIRAssembler_sparc::type_profile_helper() and mem2reg(). >>> Why did you change: >>> >>> 1391 __ verify_oop(src); >>> >>> in c1_LIRAssembler_sparc.cpp? >> I concur. Did you hit a problem here? The check is guarded by: >> >> if (addr->base()->type() == T_OBJECT) { >> - __ verify_oop(src); >> + __ verify_klass_ptr(src); >> } >> >> so this should trigger. If it does then we are propagating the wrong type somewhere. >> >>> It appears verify_klass_ptr() doesn't do anything currently so that nothing fails with this changed doesn't really prove it's correct. >> Correct; these methods are currently empty. When the runtime team removed perm-gen they added these methods but never implemented them. Not our issue. But the second change is definitely correct; the receiver is a Klass*. >> >>> Roland. >>> > From vladimir.kozlov at oracle.com Tue Oct 8 10:34:14 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Oct 2013 10:34:14 -0700 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <185B61AA-F326-4257-BD08-7AC04488723A@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <6E39E6D7-F989-4E62-8267-DBAE76E4F76F@oracle.com> <52377337.2090105@oracle.com> <185B61AA-F326-4257-BD08-7AC04488723A@oracle.com> Message-ID: <52544216.7060503@oracle.com> Test produce correct results (1+2==3; the result could be wrong, for example, when an incorrect method is inlined because incorrect receiver type was used) and no assert (crushes). I don't ask to verify inlining/not_inlining decisions. thanks, Vladimir On 10/8/13 9:35 AM, Roland Westrelin wrote: > Hi Vladimir, > >>>> You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types). >>> >>> Do you mean tests that show an improvement (artificially pollute profiling at a call site and verify that some profiling that dominates the call site helps for instance)? I have such tests but they need manual inspection of the resulting code or inlining. Given the effect of the change has no visible effects at the java level how would I automate testing? Run with -XX:+PrintInlining and parse the output? Have we done that before on other tests? >> >> No. I just want to test correctness. Something like merging array and instance types, reflection, constant types etc. To make sure your new code in C2 types works correctly (correct inlining). Use test cases which you think can be problematic. Even if a test doesn't fail with your current changes we need it. > > This is still not clear to me. > Do you want tests to test correctness as in no VM crash or correctness as in correctly optimized? > Maybe you can sketch a example test? > > Roland. > From roland.westrelin at oracle.com Tue Oct 8 10:45:57 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 8 Oct 2013 19:45:57 +0200 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <9BF6FAEC-7728-45C5-BE43-9C45957A31C8@oracle.com> References: <5252D87E.5060605@oracle.com> <40E501F0-B2BD-4C74-BDCA-FCD580368B93@oracle.com> <358968F5-E7B8-4D1B-8134-8D118002EF0A@oracle.com> <525409C8.8080801@oracle.com> <8EE536BC-8694-4537-B731-8F0A1EEC3CF1@oracle.com> <525436B0.10305@oracle.com> <9BF6FAEC-7728-45C5-BE43-9C45957A31C8@oracle.com> Message-ID: <402AD379-4674-4D34-BDEF-CF7186FB6906@oracle.com> >> The x86 version of LIR_Assembler::type_profile_helper() does not have a verify_oop() and I removed the SPARC version accordingly. > > Well, the reason that x86 doesn't have that check is because on x86 we can do a memory compare: > > __ cmpptr(recv, Address(mdo, md->byte_offset_of_slot(data, ReceiverTypeData::receiver_offset(i)))); > > So we don't have the value in a register to do the check. Please but the verify_klass_ptr check back. I think you need to put the one in LIR_Assembler::mem2reg() back as well. If we need to remove it for some test to pass then it means there's another bug somewhere and we shouldn't hide it. Roland. From igor.veresov at oracle.com Tue Oct 8 10:47:29 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 08 Oct 2013 17:47:29 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 50 new changesets Message-ID: <20131008174916.1936A62E4D@hg.openjdk.java.net> Changeset: 586fa1919a89 Author: bpittore Date: 2013-09-20 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/586fa1919a89 8014911: Should use SUPPORTS_NATIVE_CX8 define to help C/C++ compiler elide blocks of code Summary: If SUPPORTS_NATIVE_CX8 true then supports_cx8() function hard coded to return 'true' Reviewed-by: kvn, twisti, dholmes ! src/share/vm/runtime/vm_version.hpp Changeset: 504d8f519adf Author: jiangli Date: 2013-09-20 20:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/504d8f519adf Merge Changeset: d682c6e24fe3 Author: bdelsart Date: 2013-09-26 01:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d682c6e24fe3 Merge Changeset: 60a2d625db36 Author: bdelsart Date: 2013-09-26 04:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/60a2d625db36 Merge Changeset: 2c022e432e10 Author: stefank Date: 2013-09-20 10:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2c022e432e10 8024974: Incorrect use of GC_locker::is_active() Summary: SymbolTable and StringTable can make calls to GC_locker::is_active() outside a safepoint. This isn't safe because the GC_locker active state (lock count) is only updated at a safepoint and only remains valid as long as _needs_gc is true. However, outside a safepoint_needs_gc can change to false at any time, which makes it impossible to do a correct call to is_active() in that context. In this case these calls can just be removed since the input argument to basic_add() should never be on the heap and so there's no need to check the GC_locker state. This change also adjusts the assert() in is_active() to makes sure all calls to this function are always done under a safepoint. Reviewed-by: brutisso, dcubed Contributed-by: per.liden at oracle.com ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 9361de86a50f Author: stefank Date: 2013-09-20 11:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9361de86a50f 8025059: Metspace::should_expand mixes bytes and words in check against MaxMetaspaceSize Reviewed-by: coleenp, brutisso, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: b960c9df4f11 Author: stefank Date: 2013-09-21 10:09 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b960c9df4f11 8025096: Move the ChunkManager instances out of the VirtualSpaceLists Reviewed-by: coleenp, mgerdin, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 10cc3b624f8f Author: tschatzl Date: 2013-09-24 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/10cc3b624f8f Merge - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: a19bea467577 Author: tschatzl Date: 2013-09-25 13:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a19bea467577 7163191: G1: introduce a "heap spanning table" abstraction Summary: Add G1BiasedArray that is an array where each element represents a fixed-sized subdivision of the heap. Use this abstraction to refactor the HeapRegionSeq class. Reviewed-by: brutisso ! make/excludeSrc.make + src/share/vm/gc_implementation/g1/g1BiasedArray.cpp + src/share/vm/gc_implementation/g1/g1BiasedArray.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.inline.hpp ! src/share/vm/gc_implementation/g1/vmStructs_g1.hpp ! src/share/vm/prims/jni.cpp Changeset: 03f493ce3a71 Author: brutisso Date: 2013-09-25 17:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/03f493ce3a71 8025228: assert(new_entry->reserved_words() == vs_word_size) fails in nightly Reviewed-by: mgerdin, tschatzl, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 461159cd7a91 Author: tschatzl Date: 2013-09-26 12:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/461159cd7a91 Merge ! src/share/vm/classfile/symbolTable.cpp Changeset: 3da9fad1391e Author: tschatzl Date: 2013-09-26 06:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3da9fad1391e Merge Changeset: c81dd5393a5e Author: tbell Date: 2013-09-25 12:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c81dd5393a5e 8025411: JPRT to switch to the new Win platforms for JDK8 builds this week Reviewed-by: ksrini, katleman ! make/jprt.properties Changeset: fff4842215d1 Author: cl Date: 2013-09-26 10:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fff4842215d1 Added tag jdk8-b109 for changeset c81dd5393a5e ! .hgtags Changeset: 58043478c26d Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/58043478c26d Merge Changeset: 6209b0ed51c0 Author: amurillo Date: 2013-09-26 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6209b0ed51c0 Added tag hs25-b52 for changeset 58043478c26d ! .hgtags Changeset: 24250c363d7f Author: amurillo Date: 2013-09-26 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/24250c363d7f 8025536: new hotspot build - hs25-b53 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 899ecf76b570 Author: dsimms Date: 2013-09-25 13:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/899ecf76b570 8023956: Provide a work-around to broken Linux 32 bit "Exec Shield" using CS for NX emulation (crashing with SI_KERNEL) Summary: Execute some code at a high virtual address value, and keep mapped Reviewed-by: coleenp, zgu ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.hpp Changeset: 5b1191bf0b4b Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5b1191bf0b4b 8024677: [TESTBUG] Move tests for classes in /testlibrary Summary: Moved the tests to /testlibrary_tests and updated TEST.groups Reviewed-by: dholmes, sla ! test/TEST.groups - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java + test/testlibrary_tests/AssertsTest.java + test/testlibrary_tests/OutputAnalyzerReportingTest.java + test/testlibrary_tests/OutputAnalyzerTest.java Changeset: c1fbf21c7397 Author: ctornqvi Date: 2013-09-25 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c1fbf21c7397 8024492: [TESTBUG] Test library class Platform.java needs to include methods for missing OS's and architectures Summary: Added methods for 32bit, arm, ppc, x64 and x86 Reviewed-by: zgu, hseigel, mseledtsov ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 190899198332 Author: hseigel Date: 2013-09-26 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/190899198332 7195622: CheckUnhandledOops has limited usefulness now Summary: Enable CHECK_UNHANDLED_OOPS in fastdebug builds across all supported platforms. Reviewed-by: coleenp, hseigel, dholmes, stefank, twisti, ihse, rdurbin Contributed-by: lois.foltan at oracle.com ! make/bsd/makefiles/fastdebug.make ! make/linux/makefiles/fastdebug.make ! make/windows/makefiles/fastdebug.make ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a5ac0873476c Author: zgu Date: 2013-09-27 10:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a5ac0873476c Merge ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 36b97be47bde Author: acorn Date: 2013-10-01 08:10 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/36b97be47bde 8011311: Private interface methods. Default conflicts:ICCE. no erased_super_default. Reviewed-by: coleenp, bharadwaj, minqi ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klassVtable.cpp Changeset: de059a14e159 Author: zgu Date: 2013-10-01 08:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/de059a14e159 8022187: Missing ResourceMark crash when assertion using FormatBufferResource fails Summary: Uses stack for the format buffer instead of resource memory Reviewed-by: kvn, coleenp ! src/share/vm/utilities/array.hpp Changeset: 90b27e931639 Author: zgu Date: 2013-10-01 09:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/90b27e931639 Merge Changeset: 31f0118ea584 Author: zgu Date: 2013-10-01 11:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/31f0118ea584 Merge Changeset: 268e7a2178d7 Author: iveresov Date: 2013-10-03 16:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/268e7a2178d7 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/services/classLoadingService.cpp Changeset: d68894a09c7c Author: jiangli Date: 2013-09-27 13:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d68894a09c7c 8024990: JT_JDK: 11 failures with SIGSEGV on arm-sflt platforms in nightly fastdebug build. Summary: Enable patching for load_appendix_id. Reviewed-by: kvn, dlong, bdelsart ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 5186dcaca431 Author: jiangli Date: 2013-09-27 13:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5186dcaca431 Merge ! src/share/vm/c1/c1_Runtime1.cpp - test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java - test/runtime/6878713/Test6878713.sh - test/runtime/6878713/testcase.jar - test/runtime/7020373/Test7020373.sh - test/runtime/7020373/testcase.jar Changeset: d0cfa6502dfe Author: jprovino Date: 2013-10-03 10:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d0cfa6502dfe Merge ! src/share/vm/c1/c1_Runtime1.cpp Changeset: 100614790c1e Author: vladidan Date: 2013-10-03 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/100614790c1e Merge Changeset: c319b188c7b2 Author: tschatzl Date: 2013-09-26 12:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c319b188c7b2 8014078: G1: improve remembered set summary information by providing per region type information Summary: Add memory consumption breakdown on a per region type in the G1 remembered set summary statistics. This simplifies remembered set memory consumption analysis. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! test/gc/g1/TestSummarizeRSetStats.java + test/gc/g1/TestSummarizeRSetStatsPerRegion.java + test/gc/g1/TestSummarizeRSetStatsTools.java Changeset: bc918fd1e584 Author: mgerdin Date: 2013-09-27 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bc918fd1e584 8025279: metaspace/flags/maxMetaspaceSize throws OOM: out of Compressed Klass space Summary: Only put "Compressed class space" as OOM cause if actually using Compressed class space Reviewed-by: jwilhelm, stefank, ehelin, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 4fa18058548e Author: tschatzl Date: 2013-09-27 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4fa18058548e Merge Changeset: ccef6e165e8b Author: tschatzl Date: 2013-09-27 13:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ccef6e165e8b Merge Changeset: d55c004e1d4d Author: mgerdin Date: 2013-09-24 14:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d55c004e1d4d 8025305: Cleanup CardTableModRefBS usage in G1 Summary: Move some G1 specific code from CardTableModRefBS to G1SATBCardTableModRefBS. Reviewed-by: brutisso, tschatzl, ehelin ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CardCounts.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1EvacFailure.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 7ec10139bf37 Author: tschatzl Date: 2013-09-30 12:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ec10139bf37 8025441: G1: assert "assert(thread < _num_vtimes) failed: just checking" fails when G1ConcRefinementThreads > ParallelGCThreads Summary: The initialization for the remembered set summary data structures used the wrong thread count, i.e. number of worker threads instead of number of refinement threads. Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.hpp + test/gc/g1/TestSummarizeRSetStatsThreads.java Changeset: 9de9169ddde6 Author: brutisso Date: 2013-10-01 07:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9de9169ddde6 8025605: G1: Heap expansion logging misleading for fully expanded heap Reviewed-by: tschatzl, jwilhelm, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 9ecd6d3782b1 Author: ehelin Date: 2013-10-01 15:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9ecd6d3782b1 8025313: MetaspaceMemoryPool incorrectly reports undefined size for max Reviewed-by: stefank, tschatzl ! src/share/vm/memory/collectorPolicy.cpp Changeset: 77a774ab3cf0 Author: mgerdin Date: 2013-10-02 14:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/77a774ab3cf0 8012525: gc/metaspace/G1AddMetaspaceDependency.java Test fails a safepoint timeout assertion or hangs. Reviewed-by: brutisso, tschatzl ! test/gc/metaspace/G1AddMetaspaceDependency.java Changeset: 6e22e7042433 Author: ehelin Date: 2013-09-30 11:39 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6e22e7042433 8025226: TestPerfCountersAndMemoryPools.java fails with -Xmixed or -Xcomp Reviewed-by: brutisso, mgerdin ! test/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 379ef2cc19c0 Author: ehelin Date: 2013-10-02 18:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/379ef2cc19c0 Merge Changeset: ab68fc0101ce Author: jwilhelm Date: 2013-10-03 13:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ab68fc0101ce 8025855: Simplify GenRemSet code slightly Summary: Remove a few redundant switch-statements Reviewed-by: jcoomes, tschatzl ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genRemSet.cpp Changeset: c49c7f835e8d Author: jwilhelm Date: 2013-10-03 17:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c49c7f835e8d 8025853: Remove unnecessary uses of GenerationSizer Summary: Removed stray includes and some minor cleanup of GenerationSizer Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp Changeset: 798522662fcd Author: jcoomes Date: 2013-10-04 13:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/798522662fcd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp Changeset: ebfa5793d349 Author: katleman Date: 2013-10-02 13:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ebfa5793d349 Added tag jdk8-b110 for changeset 6209b0ed51c0 ! .hgtags Changeset: 562a3d356de6 Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/562a3d356de6 Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java Changeset: f6962730bbde Author: amurillo Date: 2013-10-04 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f6962730bbde Added tag hs25-b53 for changeset 562a3d356de6 ! .hgtags Changeset: deec468baebd Author: amurillo Date: 2013-10-04 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/deec468baebd 8025859: new hotspot build - hs25-b54 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 17cda06bcb7d Author: iveresov Date: 2013-10-08 07:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/17cda06bcb7d Merge ! src/share/vm/classfile/defaultMethods.cpp - test/compiler/8013496/Test8013496.sh From vladimir.kozlov at oracle.com Tue Oct 8 12:02:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Oct 2013 12:02:07 -0700 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: References: Message-ID: <525456AF.7050602@oracle.com> ProfiledCodeHeapSize value is missleading because part of it will be cut for non_method section: profile_size = ProfiledCodeHeapSize - non_method_size; And you hided default non_method_size (8Mb) inside the code: + size_t non_method_size = ReservedCodeSpace::allocation_align_size_up(MIN2(ReservedCodeCacheSize, 8*M)); It is not good. If in future we add more stubs, for example, 8Mb could be not enough and it will be hard to find this place. May be NonProfiledCodeHeapSize + ProfiledCodeHeapSize == ReservedCodeCacheSize + 8Mb So the size could be adjusted by setting 2 flags. Why you need all heaps for Client VM (only C1 is available)? +bool CodeCache::heap_available(CodeBlobType bt) { + if (TieredCompilation || bt == btNonMethod) { + // Use all heaps for TieredCompilation + return true; + } else { +#ifdef COMPILER2 + // We only need the heap for C2 + return (bt == btMethodNoProfile); +#else + // We need both heaps + return true; +#endif + } } report_codemem_full(). When I discussed this feature with Igor, he told me that if you failed allocate in one heap you can allocate in an other heap. Or you can move boundary. The longer you run "stable" application the less ProfiledCodeHeap will be used (could be changed later when we add code to fall back to profiled code during nmethod deoptimization). It would be nice to redirect its space for NonProfiledCodeHeap. For this purpose layout of heaps should be reversed. It would be strange to see free space in whole codecache but not able to allocate. Next message is incorrect now since you need heap's specific flag: + warning("Try increasing the code cache size using -XX:ReservedCodeCacheSize="); thanks, Vladimir On 10/2/13 7:06 AM, Tobias Hartmann wrote: > Hi, > > please review the following change. > > bug: https://bugs.openjdk.java.net/browse/JDK-8015774 > webrev: http://cr.openjdk.java.net/~anoll/8015774/webrev.00/ > > This change implements support for multiple code heaps in the code > cache. The interface of the code cache was changed accordingly and > references from other components of the VM were adapted. This includes > the indirect references from: > - the Serviceability Agent: vmStructs and the Java code cache interface > (sun.jvm.hotspot.code.CodeCache) > - the dtrace ustack helper script (jhelper.d) > - the pstack support library libjvm_db.c > > Currently the code cache contains the following three code heaps each of > which contains CodeBlobs of a specific type: > - Non-Profiled methods: nmethods that are not profiled, i.e., those > compiled at tier 1 or 4 and native methods > - Profiled methods: nmethods that are profiled, i.e., those compiled at > tier 2 or 3 > - Non-methods: Non-methods like Buffers, Adapters and Runtime Stubs > > By default, 2/3 of the ReservedCodeCacheSize is used for the > non-profiled heap and 1/3 is used for the profiled heap. Experiments > with a small code cache size have shown that this configuration performs > best (see [1]). Sizes can be configured using the > NonProfiledCodeHeapSize and ProfiledCodeHeapSize parameters. By now the > non-method heap has a fixed size of 8mb. More tests have to be performed > to determine reasonable default values for different build and runtime > configurations. It would be also possible to add an additional heap for > the CodeBlobs needed during VM startup (adapters, stubs, interpreter, > ...) and use the non-method heap for non-method blobs allocated during > runtime. > > The main benefit of this allocation is that functions operating on > nmethods can now be optimized to only iterate over CodeBlobs on the > nmethod heaps, avoiding a full scan of the code cache including the > non-methods. Performance evaluation shows that this results in a great > reduction of the sweeping time. Further it is now possible to extend the > sweeper to selectively sweep nmethods of different compilation levels. > Because it is more expensive to recompile a highly optimized method, it > makes sense to first sweep those compiled at a lower level. Possible > future optimizations may also include multithreaded sweeping and > separation of nmethod code and metadata. > > The code was tested using Nashorn + Octane, DaCapo, SPECJvm2008 and jprt. > > Benchmark results: > - [2] shows the score of the old and new version running Nashorn with > the Octane benchmark at different code cache sizes (10 runs each, sizes > < 32mb crash with the old version). An performance improvement of around > 15% is reached. > - [3] shows the sweep time of the NMethodSweeper during runs of the > Octane benchmark with different code cache sizes (10 runs each). The > time is greatly reduced with the new version. > - [4] shows the time ratio (TOld / TNew - 1) of the DaCapo benchmarks > with a code cache size of 64mb (30 runs with 20 warmups each). With the > time differences being smaller than the confidence intervals it is not > possible determine a difference between the two versions. > - Multiple runs of the SPECJvm2008 benchmark with different code cache > sizes did not show a difference between the two versions. This is > probably due to the fact that not much code is compiled at runtime > compared to Nashorn with the Octane benchmark. > > The error bars at each data point show the 95% confidence interval. > > [1] https://bugs.openjdk.java.net/secure/attachment/16372/OctaneRatio.png > [2] > https://bugs.openjdk.java.net/secure/attachment/16374/OctaneCCSizes_new.png > [3] > https://bugs.openjdk.java.net/secure/attachment/16373/OctaneSweepTime_new.png > [4] > https://bugs.openjdk.java.net/secure/attachment/16371/DaCapoCCSizes_64.png > > Thanks and best regards, > > Tobias From christian.thalinger at oracle.com Tue Oct 8 12:08:19 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 12:08:19 -0700 Subject: RFR (XXS): 8007923: Tests on references fails Message-ID: https://bugs.openjdk.java.net/browse/JDK-8007923 http://cr.openjdk.java.net/~twisti/8007923/webrev.00/ 8007923: Tests on references fails Reviewed-by: Escape analysis treats java.lang.ref.Reference as any other object and tries to scalarize it. In this particular fail one Reference does not escape but the other one does. When it comes to a pointer equality check the pointer comparison optimization falsely assumes that the non-escaped Reference cannot escape but in fact it can when the garbage collector enqueues the Reference in the queue. After more internal discussion we decided to exclude java.lang.ref.Reference from being scalarized since they can escape globally any time. From christian.thalinger at oracle.com Tue Oct 8 12:25:28 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 12:25:28 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> Message-ID: <5E3AFA1B-FA91-4FF1-A73E-45D82FBDF8F2@oracle.com> src/share/vm/c1/c1_GraphBuilder.cpp: + void profile_return_type(Value ret, ciMethod* callee, ciMethod* m = NULL, int bci = -1); +void GraphBuilder::profile_return_type(Value ret, ciMethod* callee, ciMethod* m, int invoke_bci) { + assert((m == NULL) == (invoke_bci < 0), "invalid method and invalid bci together"); + if (m == NULL) { + m = method(); + } + if (invoke_bci < 0) { + invoke_bci = bci(); + } Is there potentially a problem if somehow InvocationEntryBci or InvalidOSREntryBci are passed in: enum MethodCompilation { InvocationEntryBci = -1, // i.e., not a on-stack replacement compilation InvalidOSREntryBci = -2 }; ? + int bci = invoke_bci; Why are you having a new variable here? + ciTypeEntriesAtCall* args_and_ret = data->is_CallTypeData() ? ((ciCallTypeData*)data)->args_and_ret() : ((ciVirtualCallTypeData*)data)->args_and_ret(); ! const TypeEntriesAtCall* args_and_ret() const { return &_args_and_ret; } I should've mentioned this in the previous review but can't we make args_and_ret() a virtual method? src/share/vm/oops/methodData.cpp: 159 int TypeStackSlotEntries::compute_cell_count(Symbol* signature, int max) { 160 int args_count = 0; 161 ResourceMark rm; 162 SignatureStream ss(signature); 163 args_count += MIN2(ss.reference_parameter_count(), max); 164 return args_count * per_arg_cell_count; 165 } Why are you using args_count += now? Before you had: 164 ResourceMark rm; 165 SignatureStream ss(inv.signature()); 166 int args_count = MIN2(ss.reference_parameter_count(), max); ! void TypeStackSlotEntries::post_initialize(Symbol* signature, bool has_receiver) { ResourceMark rm; + int start = 0; + ArgumentOffsetComputer aos(signature, _nb_entries-start); + aos.total(); + for (int i = start; i < _nb_entries; i++) { + set_stack_slot(i, aos.off_at(i-start) + (has_receiver ? 1 : 0)); + set_type(i, type_none()); + } + } I don't see start being changed. Any reason to have it in a local? If you want to keep it for clarity make it a const int. src/share/vm/oops/methodData.hpp: 753 protected: 754 const int _nb_entries; I'd advocate for not abbreviating to ambiguous letters. Use the word you wanted to use. On Oct 8, 2013, at 9:22 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8026054/webrev.00/ > > Follow up to 8023657: New type profiling points: arguments to call > > 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. > > The output of PrintMethodData is: > > 17 invokevirtual 3 > 16 bci: 17 VirtualCallData count(0) entries(1) > 'TestProfiling'(4744 1.00) > argument types 0: stack(1) 'TestProfiling$C' > 1: stack(2) 'TestProfiling$B' > return type 'TestProfiling$C' > > Roland. From vladimir.kozlov at oracle.com Tue Oct 8 12:35:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Oct 2013 12:35:08 -0700 Subject: RFR (XXS): 8007923: Tests on references fails In-Reply-To: References: Message-ID: <52545E6C.5010108@oracle.com> Please, fix assert in ciKlass::is_subtype_of() too. thanks, Vladimir On 10/8/13 12:08 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8007923 > http://cr.openjdk.java.net/~twisti/8007923/webrev.00/ > > 8007923: Tests on references fails > Reviewed-by: > > Escape analysis treats java.lang.ref.Reference as any other object and tries to scalarize it. In this particular fail one Reference does not escape but the other one does. When it comes to a pointer equality check the pointer comparison optimization falsely assumes that the non-escaped Reference cannot escape but in fact it can when the garbage collector enqueues the Reference in the queue. > > After more internal discussion we decided to exclude java.lang.ref.Reference from being scalarized since they can escape globally any time. > From vladimir.x.ivanov at oracle.com Tue Oct 8 12:41:23 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 08 Oct 2013 23:41:23 +0400 Subject: RFR (XXS): 8007923: Tests on references fails In-Reply-To: References: Message-ID: <52545FE3.4070704@oracle.com> Looks good (not a Reviewer). Best regards, Vladimir Ivanov On 10/8/13 11:08 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8007923 > http://cr.openjdk.java.net/~twisti/8007923/webrev.00/ > > 8007923: Tests on references fails > Reviewed-by: > > Escape analysis treats java.lang.ref.Reference as any other object and tries to scalarize it. In this particular fail one Reference does not escape but the other one does. When it comes to a pointer equality check the pointer comparison optimization falsely assumes that the non-escaped Reference cannot escape but in fact it can when the garbage collector enqueues the Reference in the queue. > > After more internal discussion we decided to exclude java.lang.ref.Reference from being scalarized since they can escape globally any time. > From christian.thalinger at oracle.com Tue Oct 8 13:54:46 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 13:54:46 -0700 Subject: RFR (XXS): 8007923: Tests on references fails In-Reply-To: <52545E6C.5010108@oracle.com> References: <52545E6C.5010108@oracle.com> Message-ID: <19E65995-87D9-4809-B17F-9CA5ECEB2533@oracle.com> On Oct 8, 2013, at 12:35 PM, Vladimir Kozlov wrote: > Please, fix assert in ciKlass::is_subtype_of() too. Yeah, good point. I've also removed the wrong comment in ciKlass::is_subclass_of: http://cr.openjdk.java.net/~twisti/8007923/webrev.01/ > > thanks, > Vladimir > > On 10/8/13 12:08 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8007923 >> http://cr.openjdk.java.net/~twisti/8007923/webrev.00/ >> >> 8007923: Tests on references fails >> Reviewed-by: >> >> Escape analysis treats java.lang.ref.Reference as any other object and tries to scalarize it. In this particular fail one Reference does not escape but the other one does. When it comes to a pointer equality check the pointer comparison optimization falsely assumes that the non-escaped Reference cannot escape but in fact it can when the garbage collector enqueues the Reference in the queue. >> >> After more internal discussion we decided to exclude java.lang.ref.Reference from being scalarized since they can escape globally any time. >> From vladimir.kozlov at oracle.com Tue Oct 8 13:56:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Oct 2013 13:56:53 -0700 Subject: RFR (XXS): 8007923: Tests on references fails In-Reply-To: <19E65995-87D9-4809-B17F-9CA5ECEB2533@oracle.com> References: <52545E6C.5010108@oracle.com> <19E65995-87D9-4809-B17F-9CA5ECEB2533@oracle.com> Message-ID: <52547195.1050304@oracle.com> Good. Vladimir On 10/8/13 1:54 PM, Christian Thalinger wrote: > > On Oct 8, 2013, at 12:35 PM, Vladimir Kozlov wrote: > >> Please, fix assert in ciKlass::is_subtype_of() too. > > Yeah, good point. I've also removed the wrong comment in ciKlass::is_subclass_of: > > http://cr.openjdk.java.net/~twisti/8007923/webrev.01/ > >> >> thanks, >> Vladimir >> >> On 10/8/13 12:08 PM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8007923 >>> http://cr.openjdk.java.net/~twisti/8007923/webrev.00/ >>> >>> 8007923: Tests on references fails >>> Reviewed-by: >>> >>> Escape analysis treats java.lang.ref.Reference as any other object and tries to scalarize it. In this particular fail one Reference does not escape but the other one does. When it comes to a pointer equality check the pointer comparison optimization falsely assumes that the non-escaped Reference cannot escape but in fact it can when the garbage collector enqueues the Reference in the queue. >>> >>> After more internal discussion we decided to exclude java.lang.ref.Reference from being scalarized since they can escape globally any time. >>> > From christian.thalinger at oracle.com Tue Oct 8 14:00:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 14:00:09 -0700 Subject: RFR (XXS): 8007923: Tests on references fails In-Reply-To: <52547195.1050304@oracle.com> References: <52545E6C.5010108@oracle.com> <19E65995-87D9-4809-B17F-9CA5ECEB2533@oracle.com> <52547195.1050304@oracle.com> Message-ID: <7A622E80-6B6F-4861-B55C-0F402E1DF993@oracle.com> Thank you, Vladimir. On Oct 8, 2013, at 1:56 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/8/13 1:54 PM, Christian Thalinger wrote: >> >> On Oct 8, 2013, at 12:35 PM, Vladimir Kozlov wrote: >> >>> Please, fix assert in ciKlass::is_subtype_of() too. >> >> Yeah, good point. I've also removed the wrong comment in ciKlass::is_subclass_of: >> >> http://cr.openjdk.java.net/~twisti/8007923/webrev.01/ >> >>> >>> thanks, >>> Vladimir >>> >>> On 10/8/13 12:08 PM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8007923 >>>> http://cr.openjdk.java.net/~twisti/8007923/webrev.00/ >>>> >>>> 8007923: Tests on references fails >>>> Reviewed-by: >>>> >>>> Escape analysis treats java.lang.ref.Reference as any other object and tries to scalarize it. In this particular fail one Reference does not escape but the other one does. When it comes to a pointer equality check the pointer comparison optimization falsely assumes that the non-escaped Reference cannot escape but in fact it can when the garbage collector enqueues the Reference in the queue. >>>> >>>> After more internal discussion we decided to exclude java.lang.ref.Reference from being scalarized since they can escape globally any time. >>>> >> From christian.thalinger at oracle.com Tue Oct 8 14:00:42 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 14:00:42 -0700 Subject: RFR (XXS): 8007923: Tests on references fails In-Reply-To: <52545FE3.4070704@oracle.com> References: <52545FE3.4070704@oracle.com> Message-ID: Thank you anyway, Vladimir I. On Oct 8, 2013, at 12:41 PM, Vladimir Ivanov wrote: > Looks good (not a Reviewer). > > Best regards, > Vladimir Ivanov > > On 10/8/13 11:08 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8007923 >> http://cr.openjdk.java.net/~twisti/8007923/webrev.00/ >> >> 8007923: Tests on references fails >> Reviewed-by: >> >> Escape analysis treats java.lang.ref.Reference as any other object and tries to scalarize it. In this particular fail one Reference does not escape but the other one does. When it comes to a pointer equality check the pointer comparison optimization falsely assumes that the non-escaped Reference cannot escape but in fact it can when the garbage collector enqueues the Reference in the queue. >> >> After more internal discussion we decided to exclude java.lang.ref.Reference from being scalarized since they can escape globally any time. >> From christian.thalinger at oracle.com Tue Oct 8 14:58:24 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 14:58:24 -0700 Subject: RFR (XXS): 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Message-ID: <43C6FE9C-6D37-4FFC-A70E-94F84F81E2F7@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8020750 http://cr.openjdk.java.net/~twisti/8020750/webrev.00/ 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: The problem is a missing top check in IfNode::fold_compares. From vladimir.kozlov at oracle.com Tue Oct 8 16:14:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Oct 2013 16:14:26 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> Message-ID: <525491D2.5070203@oracle.com> Roland, Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: class VirtualCallTypeData : public VirtualCallData { private: ! TypeStackSlotEntries _args; ! ReturnTypeEntry _ret; Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. Thanks, Vladimir On 10/8/13 9:22 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8026054/webrev.00/ > > Follow up to 8023657: New type profiling points: arguments to call > > 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. > > The output of PrintMethodData is: > > 17 invokevirtual 3 > 16 bci: 17 VirtualCallData count(0) entries(1) > 'TestProfiling'(4744 1.00) > argument types 0: stack(1) 'TestProfiling$C' > 1: stack(2) 'TestProfiling$B' > return type 'TestProfiling$C' > > Roland. > From vladimir.kozlov at oracle.com Tue Oct 8 16:17:56 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 08 Oct 2013 16:17:56 -0700 Subject: RFR (XXS): 8020750: Node::get_int: guarantee(t != NULL) failed: must be con In-Reply-To: <43C6FE9C-6D37-4FFC-A70E-94F84F81E2F7@oracle.com> References: <43C6FE9C-6D37-4FFC-A70E-94F84F81E2F7@oracle.com> Message-ID: <525492A4.6030906@oracle.com> Good. Vladimir On 10/8/13 2:58 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8020750 > http://cr.openjdk.java.net/~twisti/8020750/webrev.00/ > > 8020750: Node::get_int: guarantee(t != NULL) failed: must be con > Reviewed-by: > > The problem is a missing top check in IfNode::fold_compares. > From christian.thalinger at oracle.com Tue Oct 8 18:22:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 8 Oct 2013 18:22:38 -0700 Subject: RFR (XXS): 8020750: Node::get_int: guarantee(t != NULL) failed: must be con In-Reply-To: <525492A4.6030906@oracle.com> References: <43C6FE9C-6D37-4FFC-A70E-94F84F81E2F7@oracle.com> <525492A4.6030906@oracle.com> Message-ID: Thank you, Vladimir. On Oct 8, 2013, at 4:17 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/8/13 2:58 PM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8020750 >> http://cr.openjdk.java.net/~twisti/8020750/webrev.00/ >> >> 8020750: Node::get_int: guarantee(t != NULL) failed: must be con >> Reviewed-by: >> >> The problem is a missing top check in IfNode::fold_compares. >> From albert.noll at oracle.com Tue Oct 8 22:00:42 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 09 Oct 2013 07:00:42 +0200 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <524DEB5B.1060603@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> <524BEBC2.4030202@oracle.com> <524C4EA8.1020109@oracle.com> <524D6A32.5080003@oracle.com> <524DEB5B.1060603@oracle.com> Message-ID: <5254E2FA.1000602@oracle.com> Hi Vladimir, hi Christian, thanks for looking at the patch. @Christian: I fixed the issues you brought up. @Vladimir: See comments inline: Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.05/ On 04.10.2013 00:10, Vladimir Kozlov wrote: > c1_Compiler.cpp. Can you have next in header file since they are > empty? And why you need them at all (C2Compiler does not have them)?: > > +Compiler::Compiler () {} > +Compiler::~Compiler() {} > I need Compiler::Compiler() {}, otherwise I get the following error: Error: failed /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so, because /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so: undefined symbol: _ZN8CompilerC1Ev +Compiler::~Compiler() {} can be removed. > I think we can keep compiler objects (Compiler and c2Compiler) since > they should be very small. You can keep your comment in > shutdown_compiler_runtime() but remove commented code. > Done. > Indention in CompileQueue::delete_all(): > > } > _first = NULL; > } > Done. > >> In should_perform_shutdown() the _compiler_state could be changed > >> before other threads reach "if (comp->is_state_failed())" check in > >> init_compiler_runtime(). > > True. I added a function should_exit(), which returns true if the state > > if failed, or shutting down. > > You actually don't need to change state to shutting_shown. This state > is not checked anywhere (you removed waiting loop). The 'failed' state > can stay until the last thread change it to shut_down. So you don't > need new method should_exit(). > > Looking more on get_buffer_blob() == null case and I think you don't > need special C1 check in init_compiler_runtime() because it will not > reach it. Compiler::initialize() set state to 'failed' if buffer is > NULL so the first condition in init_compiler_runtime() will be true. > I think we need this check, since compiler initialization can be successful and there is enough free space in the code cache to allocate the buffer blob for the first couple of threads, but not for all threads. The test specifically tests this exit path. Many thanks again, Albert > The test is fine. At least we have something. > > Thanks, > Vladimir > > On 10/3/13 5:59 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks for looking at the patch. See comments inline. >> Here is the updated webrev: >> http://cr.openjdk.java.net/~anoll/8023014/webrev.04/ >> >> >> On 02.10.2013 18:49, Vladimir Kozlov wrote: >>> Albert, >>> >>> In disable_compilation_forever() the comment does not correspond to >>> code. >>> >> I removed the comment. >>> In should_perform_shutdown() the _compiler_state could be changed >>> before other threads reach "if (comp->is_state_failed())" check in >>> init_compiler_runtime(). >> True. I added a function should_exit(), which returns true if the state >> if failed, or shutting down. >>> Yes, decrementing with lock is fine, you are right. >>> >>> The message should say why we do shutdown (no space to initialize >>> compiler runtime): >>> warning("Shutting down compiler >>> >> The warning messages are now: >> - "Shutting down compiler %s (no space to run compiler)" or >> - "Initialization of %s thread failed (no space to run compiler thread)" >> if a C1 compiler thread fails to allocate memory. >>> Please, explain what references: >>> >>> + // We could delete compiler runtimes also. However, >>> + // there are references to the compiler runtime(s) >>> + // (e.g., by nmethods) which then fail. This can be >>> >> Done. >>> It would be nice to have regression test for this. >> I added a regression test, which checks that compiler threads exit, if >> there is not sufficient free code cache >> to init all threads. Testing a failing initialization of C2 is tricky, >> since a C2 initialization failure depends on the >> scheduling of the compiler threads. >> >> Thanks again, >> Albert >>> >>> Thanks, >>> Vladimir >>> >>> On 10/2/13 2:47 AM, Albert Noll wrote: >>>> Hi Vladimir, >>>> >>>> thanks again for the feedback. I tested the patch as you proposed, >>>> i.e., make sure that >>>> the patch works if the C1 and/or C2 compiler fails to initialize. I >>>> tested with up to 256 compiler >>>> threads. >>>> >>>> To make sure that all compiler threads exit, I had to do additional >>>> modifications in CompileQueue::get() >>>> and the caller of this method. With these changes, one can also exit >>>> compiler threads if -XX:-UseCodeCacheFlushing >>>> is set, which is also contained in this webrev. >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ >>>> >>>> >>>> See more comments inline: >>>> >>>> >>>> On 01.10.2013 18:17, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> In general it looks good. Please, test it extensively with Tiered >>>>> with codecache size enough to initialize one >>>>> compiler but not an other to verify your code. >>>>> >>>> Done. >>>>> I think you need to swap lock and decrement otherwise it will >>>>> deadlock: >>>>> >>>>> +bool AbstractCompiler::should_perform_shutdown() { >>>>> + MutexLocker only_one(CompileThread_lock); >>>>> + _num_compiler_threads--; >>>>> >>>> I simplified this function. In fact it is fine if the last thread >>>> (i.e., if _num_compiler_threads == 0) >>>> does the shutdown. The while() statement is really not necessary. >>>> However, we have to decrement >>>> _num_compiler_threads when we hold the lock. Otherwise we are not >>>> guaranteed to reach 0 >>>> (-- is not atomic). >>>> >>>>> comp->set_shut_down(); and delete _compilers[0]; should be done by >>>>> one thread I think. >>>> Done. >>>> >>>>> >>>>> Small note, you accidentally removed nl in c2compiler.cpp: >>>>> >>>>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> >>>>> >>>> Fixed. >>>> >>>> Thanks again, >>>> Albert >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/1/13 12:27 AM, Albert Noll wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thanks again for looking at the patch. See comments inline: >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>>>>> >>>>>> >>>>>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>>>>> Albert, >>>>>>> >>>>>>> There is small window between check and set_state where state can >>>>>>> became initialized or still be uninitialized: >>>>>>> + if (!is_initialized()) { >>>>>>> + set_state(failed); >>>>>>> >>>>>>> so you may hit assert in set_state(). >>>>>>> >>>>>>> I think you need to call set_state(failed) only when C1 runtime is >>>>>>> initialized after lock: >>>>>>> >>>>>>> if (should_perform_init()) { >>>>>>> if (buffer_blob == NULL) { >>>>>>> set_state(failed); >>>>>>> } else { >>>>>>> init_c1_runtime(); >>>>>>> set_state(initialized); >>>>>>> } >>>>>>> } >>>>>>> >>>>>> You are right. I adapted the patch according to your suggestion. >>>>>> >>>>>>> In this case it will match behavior for C2 which means that you >>>>>>> need to shutdown compilation since you was not able to >>>>>>> initialize compilation runtime. It will require more code to do >>>>>>> proper shutdown not just exiting thread (free >>>>>>> compilation queues, resetting flags). An it will be more >>>>>>> complicated for Tiered case (I think we can use simple >>>>>>> approach to shutdown all compilations even if only one Compiler is >>>>>>> not initialized since it is rare case). >>>>>>> >>>>>> I added code to shut-down compilation. If compiler runtime >>>>>> initialization fails, a flag is set which disables >>>>>> compilation forever. In the current >>>>>> version, all compilers are disabled if C1 and/or C2 runtime >>>>>> initialization fails (also in case of tiered compilation). I >>>>>> think this solution is fine for >>>>>> now, since a compiler runtime initialization failure should not >>>>>> happen in practice. If it ever turns out to be a >>>>>> problem, i.e., it is required that we >>>>>> we use one compiler if the other compiler failed to initialize, I >>>>>> suggest we fix this in another bug. The current bug >>>>>> appears only due to an artificial >>>>>> setting of the code cache size. >>>>>> >>>>>> Compiler shut-down is performed by one thread. This thread waits >>>>>> until all compiler threads have exited to compiler >>>>>> loop. The thread then >>>>>> deletes all tasks from the compile queue, deletes the compiler >>>>>> objects, and sets the objects to NULL. >>>>>> >>>>>> Please let me know if you think this solution is fine, or if there >>>>>> are other things that need to be considered. >>>>>> The current version passed jprt. >>>>>> >>>>>> Many thanks again, >>>>>> Albert >>>>>> >>>>>>> If C1 runtime was initialized but we was not able to allocate >>>>>>> buffer for some threads your current code in >>>>>>> compileBroker.cpp will handle such case. So you don't need to set >>>>>>> state to 'failed'. >>>>>>> >>>>>>> thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> thanks for looking at the patch. >>>>>>>> Here is the new webrev: >>>>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> See comments inline: >>>>>>>> >>>>>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>>>>> Thank you, Albert >>>>>>>>> >>>>>>>>> I would suggest to do TieredStartAtLevel changes separately, it >>>>>>>>> is not >>>>>>>>> related to this bug. >>>>>>>>> >>>>>>>> Done. >>>>>>>>> Second, how we can guard the initialization with a field >>>>>>>>> (_compiler_state and original _is_initialized) which is not >>>>>>>>> static? >>>>>>>>> >>>>>>>>> You don't need separate local do_init in C*_Compiler.cpp since >>>>>>>>> it is >>>>>>>>> used only once: >>>>>>>>> >>>>>>>> Done. >>>>>>>>> + if (should_perform_init()) { >>>>>>>>> >>>>>>>>> abstractCompiler.cpp: >>>>>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>>>>> check_prelock_state() called from Monitor::lock(): >>>>>>>>> >>>>>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>>>>> || rank() == Mutex::special, "wrong thread state for >>>>>>>>> using >>>>>>>>> locks"); >>>>>>>>> >>>>>>>>> Compiler threads are Java threads, so you should be in VM state >>>>>>>>> when >>>>>>>>> lock. How you did not hit this assert? >>>>>>>>> >>>>>>>> The state transition from native to VM (and ResetNoHandleMark) is >>>>>>>> now in >>>>>>>> compileBroker.cpp:1543. >>>>>>>>> >>>>>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>>>>> >>>>>>>>> + // This method returns true for the first compiler thread that >>>>>>>>> reaches that methos. >>>>>>>>> >>>>>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>>>>> object created for each compilation): >>>>>>>>> >>>>>>>>> + // This thread will initialize the compiler object. >>>>>>>>> >>>>>>>>> Swap lines (and use 'runtime' in the comment): >>>>>>>>> >>>>>>>>> ! bool is_initialized () { return _compiler_state == >>>>>>>>> initialized; } >>>>>>>>> ! // Get/set state of compiler objects >>>>>>>>> >>>>>>>>> >>>>>>>>> c2compiler.cpp: >>>>>>>>> >>>>>>>>> C2Compiler:: is not needed: >>>>>>>>> >>>>>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>>>>> >>>>>>>>> >>>>>>>> Fixed the issues above. >>>>>>>>> Should we exit Compiler thread which failed local buffer >>>>>>>>> allocation >>>>>>>>> instead parking? Why keep resources allocated for it? >>>>>>>>> >>>>>>>> You are right, there is no reason the keep these threads around. >>>>>>>> Compiler threads wo are not initialized correctly >>>>>>>> now exit the VM. >>>>>>>> >>>>>>>> The patch is currently in west queue. >>>>>>>> >>>>>>>> Many thanks again, >>>>>>>> Albert >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> could I have a review for this patch? >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Problem: C1/C2 compiler initialization can fail if there is not >>>>>>>>>> enough >>>>>>>>>> memory in the code cache to generate all stubs. >>>>>>>>>> This problem occurs only with a small code cache size. >>>>>>>>>> >>>>>>>>>> Solution: Check correctness of (parts of) C1/C2 >>>>>>>>>> initialization and >>>>>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>>>>> was not initialized correctly. >>>>>>>>>> >>>>>>>>>> Testing: jprt, test case, benchmarks >>>>>>>>>> >>>>>>>>>> This patch also contains a refactored version of compiler >>>>>>>>>> object/thread >>>>>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>>>>> initialized prior entering the main compiler loop. In the old >>>>>>>>>> version, >>>>>>>>>> the check if the compiler/thread is initialized was >>>>>>>>>> done in the main compiler loop (and hence before every >>>>>>>>>> compilation). >>>>>>>>>> >>>>>>>>>> To continue execution with a limited code cache size, the code >>>>>>>>>> types >>>>>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>>>>> be 'critical' allocations in the code cache, i.e., they must >>>>>>>>>> use space >>>>>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>>>>> >>>>>>>>>> In addition I removed some unued code. >>>>>>>>>> >>>>>>>>>> Many thanks in advance for reviewing. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>> >>>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131009/0b780f01/attachment-0001.html From albert.noll at oracle.com Tue Oct 8 22:18:36 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 09 Oct 2013 07:18:36 +0200 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache Message-ID: <5254E72C.2050004@oracle.com> Hi, could I have a review for this small patch? bug: https://bugs.openjdk.java.net/browse/JDK-8023191 webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ Problem: OSR methods are not removed from code cache to free space. Solution: Remove OSR methods from code cache. OSR methods c an be made not-entrant and are then removed from the code cache likenon-OSR methods. Other parts in the code (e.g., deoptimization.cpp:1547) already make OSR methods not-entrant. Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there is an impact on performance. Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131009/e3c2ddf2/attachment.html From christian.thalinger at oracle.com Tue Oct 8 23:41:19 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 09 Oct 2013 06:41:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8007923: Tests on references fails Message-ID: <20131009064124.5732162E72@hg.openjdk.java.net> Changeset: 6171eb9da4fd Author: twisti Date: 2013-10-08 19:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6171eb9da4fd 8007923: Tests on references fails Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/opto/escape.cpp From roland.westrelin at oracle.com Tue Oct 8 23:58:13 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Oct 2013 08:58:13 +0200 Subject: RFR (XXS): 8020750: Node::get_int: guarantee(t != NULL) failed: must be con In-Reply-To: <43C6FE9C-6D37-4FFC-A70E-94F84F81E2F7@oracle.com> References: <43C6FE9C-6D37-4FFC-A70E-94F84F81E2F7@oracle.com> Message-ID: > http://cr.openjdk.java.net/~twisti/8020750/webrev.00/ That looks good to me. Roland. From roland.westrelin at oracle.com Wed Oct 9 00:00:06 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Oct 2013 09:00:06 +0200 Subject: RFR (XXS): 8007923: Tests on references fails In-Reply-To: <19E65995-87D9-4809-B17F-9CA5ECEB2533@oracle.com> References: <52545E6C.5010108@oracle.com> <19E65995-87D9-4809-B17F-9CA5ECEB2533@oracle.com> Message-ID: <1389BE66-130F-4EC1-95A9-688CAA46449A@oracle.com> > http://cr.openjdk.java.net/~twisti/8007923/webrev.01/ That looks good to me. Roland. From niclas.adlertz at oracle.com Wed Oct 9 02:36:01 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 09 Oct 2013 11:36:01 +0200 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: <5254306C.1050208@oracle.com> References: <5252BE6C.5070705@oracle.com> <5254306C.1050208@oracle.com> Message-ID: <52552381.5040806@oracle.com> Thank you Vladimir. On 2013-10-08 18:18, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/7/13 7:00 AM, Niclas Adlertz wrote: >> Hi all, >> >> The uninitialized pointer 'Reachblock' can be replaced with NULL at the >> call since the node we are re-materializing will not have any live range >> input (because of contains_no_live_range_input(def)). >> >> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8013830/webrev00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8013830 >> >> Kind Regards, >> Niclas Adlertz >> From niclas.adlertz at oracle.com Wed Oct 9 02:36:35 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 09 Oct 2013 11:36:35 +0200 Subject: RFR(XS) JDK-8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument In-Reply-To: <7491BC5B-404E-459C-8F1C-2D3FEAF29EE5@oracle.com> References: <5252BE6C.5070705@oracle.com> <967D916F-DCD6-4672-9960-782C95BA7B66@oracle.com> <5252EBEF.1030200@oracle.com> <7491BC5B-404E-459C-8F1C-2D3FEAF29EE5@oracle.com> Message-ID: <525523A3.1020902@oracle.com> Thank you Christian. On 2013-10-07 20:05, Christian Thalinger wrote: > This seems to be ok. The thing that's non-obvious is that: > > if (def->rematerialize() && contains_no_live_range_input(def)) { > > and the logic in PhaseChaitin::split_Rematerialize with: > > if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { > > are equivalent. The assert helps, though. > > On Oct 7, 2013, at 10:14 AM, Niclas Adlertz wrote: > >> Hi, >> >> At row 1330 in reg_split.cpp we check if we can split by re-materializing 'def'. We only enter split_Rematerialize() at row 1341 if the 'def' node doesn't have any live range inputs (contains_no_live_range_input(def)). >> This means that the condition at split_Rematerialize() at row 377 will never be true when entering from row 1341. Because of this we can pass in NULL at the call on row 1341 instead of the uninitialized pointer 'Reachblock'. >> >> Kind Regards, >> Niclas Adlertz >> >> >> On 2013-10-07 18:18, Roland Westrelin wrote: >>> Hi Niclas, >>> >>>> The uninitialized pointer 'Reachblock' can be replaced with NULL at the call since the node we are re-materializing will not have any live range input (because of contains_no_live_range_input(def)). >>>> >>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8013830/webrev00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8013830 >>> >>> Can you give more details? Which test in PhaseChaitin::split_Rematerialize() fails/succeeds so that we don't reach >>> >>> 378 assert(Reachblock != NULL, "Reachblock must be non-NULL"); >>> 379 Node *rdef = Reachblock[lrg2reach[lidx]]; >>> >>> when contains_no_live_range_input(def)is true? >>> >>> Roland. >>> >> > From tobi.hartmann at gmail.com Wed Oct 9 06:38:31 2013 From: tobi.hartmann at gmail.com (Tobias Hartmann) Date: Wed, 9 Oct 2013 15:38:31 +0200 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <525456AF.7050602@oracle.com> References: <525456AF.7050602@oracle.com> Message-ID: Christian, Vladimir thank you for your reviews! Please find the new webrev at: http://cr.openjdk.java.net/~anoll/8015774/webrev.01/ See comments for both reviews inline: 2013/10/8 Vladimir Kozlov > ProfiledCodeHeapSize value is missleading because part of it will be cut > for non_method section: > > profile_size = ProfiledCodeHeapSize - non_method_size; > > And you hided default non_method_size (8Mb) inside the code: > > + size_t non_method_size = ReservedCodeSpace::allocation_** > align_size_up(MIN2(**ReservedCodeCacheSize, 8*M)); > > It is not good. If in future we add more stubs, for example, 8Mb could be > not enough and it will be hard to find this place. May be > I agree, this part is still a little bit unclear. This is partly due to the fact that I'm still not sure how to set the size of the non method heap. On my machine around 3.5Mb are sufficient for all benchmarks (debug/product). The jprt tests seem to need more, that's why it is temporarily set to 8Mb. I have to evaluate that in more detail. Probably we can set it depending on build/runtime settings and operating system. One option would be to create a new heap for all blobs needed by the VM to startup. This heap size can be set to CodeCacheMinimumUseSpace. All non method blobs created by the running java application are then put into the non method heap. > NonProfiledCodeHeapSize + ProfiledCodeHeapSize == ReservedCodeCacheSize + > 8Mb > > So the size could be adjusted by setting 2 flags. > Do you mean that the 8Mb for the non method heap should be subtracted half from the NonProfiledCodeHeapSize and half from ProfiledCodeHeapSize? Why you need all heaps for Client VM (only C1 is available)? > > +bool CodeCache::heap_available(**CodeBlobType bt) { > + if (TieredCompilation || bt == btNonMethod) { > + // Use all heaps for TieredCompilation > + return true; > + } else { > +#ifdef COMPILER2 > + // We only need the heap for C2 > + return (bt == btMethodNoProfile); > +#else > + // We need both heaps > + return true; > +#endif > + } > } > If we have a client build with only the C1 compiler available we still need the non profiled code heap, because we still have the compilation levels CompLevel_none (native methods) and CompLevel_simple (C1 compiled without profiling) that belong in this heap. > report_codemem_full(). When I discussed this feature with Igor, he told me > that if you failed allocate in one heap you can allocate in an other heap. > Or you can move boundary. The longer you run "stable" application the less > ProfiledCodeHeap will be used (could be changed later when we add code to > fall back to profiled code during nmethod deoptimization). It would be nice > to redirect its space for NonProfiledCodeHeap. For this purpose layout of > heaps should be reversed. > It would be strange to see free space in whole codecache but not able to > allocate. > I'm not sure if I understood your point correctly. At the moment we delay compilation for the corresponding compilation level if a heap is full. In practice (at least for the benchmarks I run) the second heap then fills up really fast. Your suggestion to allocate CodeBlobs in another heap somehow "breaks" the design, because the client of the CodeCache could then encounter non profiled, e.g. C2 compiled, methods while iterating over the profiled heap. This is not really a problem at the moment, since no code relies on the fact that the non profiled heap _only_ contains C2 methods (as long as it contains only _methods_). However, I think that the second suggestion to move the boundary between the heaps is better. One could then increase the non profiled heap and decrease the profiled heap size if the first is full. Over time the non profiled heap would probably grow, whereas the profiled heap would shrink. Because I suspect this to be another big change, I would however suggest to implement this behavior with a second patch and first finish the current changes. Next message is incorrect now since you need heap's specific flag: > > + warning("Try increasing the code cache size using > -XX:ReservedCodeCacheSize="); > It is not incorrect as increasing the ReservedCodeCacheSize also increases the non profiled and the profiled heap sizes (if no explicit value is set by the user). One option would be to print "Try increasing the code cache size using -XX:ReservedCodeCacheSize= or -XX:NonProfiledCodeHeapSize" (or "-XX:ProfiledCodeHeapSize", depending on the heap that is full). thanks, > Vladimir 2013/10/4 Christian Thalinger > Some general comments: > > Don't use T1, T2, ? to name the tiers because SPARC processors are named > like this. It's confusing. Use tier 1, tier 2, ? instead. The > compilation policies actually talk about tier levels... > I changed the names of the code heaps and comments accordingly. > I was hoping that we can have a more loose definition of the code heaps. > So we can easily add more. What this patch does is a good start but all > the hardcoded values and fields need to go at a later point in time, in my > opinion. > To improve the adding of new heaps I completely removed the direct dependencies on code heaps from the serviceability agent, dtrace and the pstack library, especially the fields _heap_non_method, _heap_non_profiled and _heap_profiled fields in the code cache. The GrowableArray* is now the only field used to reference the code heaps. This allows adding new heaps to the cache without the need to adapt references. An exception is the dtrace ustack helper script (jhelper.d). Because the D language does not allow loops, one has to define a probe for each code heap. For now, the script supports up to 5 code heaps, but more can be added by simply adding new probes to the script (comment in line 183 in jhelper.d describes this). To summarize, if I want to add a new code heap to the cache, all I have to do is to - define a new CodeBlobType (and add it to IsMethodPredicate if it is a method type) - create the heap in CodeCache::initialize_heaps() and define default sizes [- define heap availability in CodeCache::heap_available] [- define the compilation level -> code blob type translation in CodeCache::get_code_blob_type] The last two steps are optional. CodeBlobs created with the new CodeBlobType are then allocated in the corresponding heap. I'm not completely sure what you mean with "hardcoded" values. Do you mean the default values for NonProfiledCodeHeapSize and ProfiledCodeHeapSize? Of course we could compute them implicitly as 1/3 and 2/3 of the ReservedCodeCacheSize (as it is now done if the user does not provide a value), without defining them as VM parameter, but otherwise we have to define default values for them. > src/share/vm/code/codeBlob.hpp: > > +// CodeBlob Types+// Used in the CodeCache to assign CodeBlobs to different CodeHeaps+enum CodeBlobType {+ btMethodNoProfile = 0, // T1 and T4 methods (including native methods)+ btMethodProfile = 1, // T2 and T3 methods with profile information+ btNonMethod = 2 // Non-methods like Buffers, Adapters and Runtime Stubs+}; > > The bt prefix is already overloaded (e.g. BasicType). Generally speaking, > I never liked the fact that enums don't have their name as scope. Maybe we > can agree on doing something like this: > > struct CodeBlobType { > enum Enum { > NonMethod = 2 > }; > }; > > void foo() { > int a = CodeBlobType::NonMethod; > int b = (CodeBlobType::Enum) 1; > } > > Or we move to C++11 :-) > > http://www.stroustrup.com/C++11FAQ.html#enum > Yes, it is probably more clear to include the scope. I followed your suggestion and changed it to a struct with an anonymous enum. > src/share/vm/code/codeCache.cpp: > > +#define FOR_ALL_HEAPS(index) for (int index = 0; index < _heaps->length(); ++index) > > I'm one of the people who started to hate macros (for various reasons). > Although I see the point in defining these I'd rather go without them. Is > there a way we can use STL vectors with our allocators? Or we could write > our own iterator class which iterates either over GrowableArrays in general > or the code heaps in particular. > I perfectly agree with you that macros should be used only if necessary and to improve readability in special cases. I checked the option of using STL vectors but since the STL is not used in the code yet and I'm not sure if they can be used with the hotspot allocators, I think it is better to work with own iterator classes. I therefore defined the custom iterator classes GrowableArrayIterator and GrowableArrayFilterIterator. They implement the STL input iterator interface without actually inheriting from it (since #include seems not to work with solaris). The filter iterator is used to iterate only over those code heaps satisfying a given predicate, for example those heaps containing nmethods. This makes the code a lot more readable and reduces the number of macros. I think the remaining four macros, namely FOR_ALL_HEAPS and FOR_ALL_METHOD_HEAPS to iterate over the heaps and FOR_ALL_BLOBS and FOR_ALL_ALIVE_BLOBS to iterate over the blobs are justified, because they are simple (only declaring the iterators) and make the code more readable. > src/share/vm/memory/heap.hpp: > > + const char* getName() const { return _name; } > > This should either be get_name() or name(). > I renamed it to name(). Thanks! Best regards Tobias > On 10/2/13 7:06 AM, Tobias Hartmann wrote: > >> Hi, >> >> please review the following change. >> >> bug: https://bugs.openjdk.java.net/**browse/JDK-8015774 >> webrev: http://cr.openjdk.java.net/~**anoll/8015774/webrev.00/ >> >> This change implements support for multiple code heaps in the code >> cache. The interface of the code cache was changed accordingly and >> references from other components of the VM were adapted. This includes >> the indirect references from: >> - the Serviceability Agent: vmStructs and the Java code cache interface >> (sun.jvm.hotspot.code.**CodeCache) >> - the dtrace ustack helper script (jhelper.d) >> - the pstack support library libjvm_db.c >> >> Currently the code cache contains the following three code heaps each of >> which contains CodeBlobs of a specific type: >> - Non-Profiled methods: nmethods that are not profiled, i.e., those >> compiled at tier 1 or 4 and native methods >> - Profiled methods: nmethods that are profiled, i.e., those compiled at >> tier 2 or 3 >> - Non-methods: Non-methods like Buffers, Adapters and Runtime Stubs >> >> By default, 2/3 of the ReservedCodeCacheSize is used for the >> non-profiled heap and 1/3 is used for the profiled heap. Experiments >> with a small code cache size have shown that this configuration performs >> best (see [1]). Sizes can be configured using the >> NonProfiledCodeHeapSize and ProfiledCodeHeapSize parameters. By now the >> non-method heap has a fixed size of 8mb. More tests have to be performed >> to determine reasonable default values for different build and runtime >> configurations. It would be also possible to add an additional heap for >> the CodeBlobs needed during VM startup (adapters, stubs, interpreter, >> ...) and use the non-method heap for non-method blobs allocated during >> runtime. >> >> The main benefit of this allocation is that functions operating on >> nmethods can now be optimized to only iterate over CodeBlobs on the >> nmethod heaps, avoiding a full scan of the code cache including the >> non-methods. Performance evaluation shows that this results in a great >> reduction of the sweeping time. Further it is now possible to extend the >> sweeper to selectively sweep nmethods of different compilation levels. >> Because it is more expensive to recompile a highly optimized method, it >> makes sense to first sweep those compiled at a lower level. Possible >> future optimizations may also include multithreaded sweeping and >> separation of nmethod code and metadata. >> >> The code was tested using Nashorn + Octane, DaCapo, SPECJvm2008 and jprt. >> >> Benchmark results: >> - [2] shows the score of the old and new version running Nashorn with >> the Octane benchmark at different code cache sizes (10 runs each, sizes >> < 32mb crash with the old version). An performance improvement of around >> 15% is reached. >> - [3] shows the sweep time of the NMethodSweeper during runs of the >> Octane benchmark with different code cache sizes (10 runs each). The >> time is greatly reduced with the new version. >> - [4] shows the time ratio (TOld / TNew - 1) of the DaCapo benchmarks >> with a code cache size of 64mb (30 runs with 20 warmups each). With the >> time differences being smaller than the confidence intervals it is not >> possible determine a difference between the two versions. >> - Multiple runs of the SPECJvm2008 benchmark with different code cache >> sizes did not show a difference between the two versions. This is >> probably due to the fact that not much code is compiled at runtime >> compared to Nashorn with the Octane benchmark. >> >> The error bars at each data point show the 95% confidence interval. >> >> [1] https://bugs.openjdk.java.net/**secure/attachment/16372/** >> OctaneRatio.png >> [2] >> https://bugs.openjdk.java.net/**secure/attachment/16374/** >> OctaneCCSizes_new.png >> [3] >> https://bugs.openjdk.java.net/**secure/attachment/16373/** >> OctaneSweepTime_new.png >> [4] >> https://bugs.openjdk.java.net/**secure/attachment/16371/** >> DaCapoCCSizes_64.png >> >> Thanks and best regards, >> >> Tobias >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131009/f59b74ed/attachment-0001.html From roland.westrelin at oracle.com Wed Oct 9 08:46:16 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Oct 2013 17:46:16 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <5E3AFA1B-FA91-4FF1-A73E-45D82FBDF8F2@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <5E3AFA1B-FA91-4FF1-A73E-45D82FBDF8F2@oracle.com> Message-ID: Hi Chris, Thanks for reviewing this. > src/share/vm/c1/c1_GraphBuilder.cpp: > > + void profile_return_type(Value ret, ciMethod* callee, ciMethod* m = NULL, int bci = -1); > > +void GraphBuilder::profile_return_type(Value ret, ciMethod* callee, ciMethod* m, int invoke_bci) { > + assert((m == NULL) == (invoke_bci < 0), "invalid method and invalid bci together"); > + if (m == NULL) { > + m = method(); > + } > + if (invoke_bci < 0) { > + invoke_bci = bci(); > + } > > Is there potentially a problem if somehow InvocationEntryBci or InvalidOSREntryBci are passed in: > > enum MethodCompilation { > InvocationEntryBci = -1, // i.e., not a on-stack replacement compilation > InvalidOSREntryBci = -2 > }; > > ? You mean profile_return_type() being passed bci = InvocationEntryBci and overriding it? Passing InvocationEntryBci would be a bit problem here and I don't see how it can happen. > + int bci = invoke_bci; > > Why are you having a new variable here? There's another change coming on top of this one. I broke a big change in pieces to the best I could but some code may still look a bit strange. Thanks for spotting it. I'll get rid of bci. > > + ciTypeEntriesAtCall* args_and_ret = data->is_CallTypeData() ? ((ciCallTypeData*)data)->args_and_ret() : ((ciVirtualCallTypeData*)data)->args_and_ret(); > > ! const TypeEntriesAtCall* args_and_ret() const { return &_args_and_ret; } > > I should've mentioned this in the previous review but can't we make args_and_ret() a virtual method? In what class? ProfileData? Wouldn't that expose some implementation details at a level where they don't make much sense. Also on ci* side, there's no common root class and we probably don't want ci* stuff to leak in methodData.hpp. > src/share/vm/oops/methodData.cpp: > > 159 int TypeStackSlotEntries::compute_cell_count(Symbol* signature, int max) { > 160 int args_count = 0; > 161 ResourceMark rm; > 162 SignatureStream ss(signature); > 163 args_count += MIN2(ss.reference_parameter_count(), max); > 164 return args_count * per_arg_cell_count; > 165 } > > Why are you using args_count += now? Before you had: > > 164 ResourceMark rm; > 165 SignatureStream ss(inv.signature()); > 166 int args_count = MIN2(ss.reference_parameter_count(), max); Same as above. Will clean it up. > > ! void TypeStackSlotEntries::post_initialize(Symbol* signature, bool has_receiver) { > ResourceMark rm; > + int start = 0; > + ArgumentOffsetComputer aos(signature, _nb_entries-start); > + aos.total(); > + for (int i = start; i < _nb_entries; i++) { > + set_stack_slot(i, aos.off_at(i-start) + (has_receiver ? 1 : 0)); > + set_type(i, type_none()); > + } > + } > > I don't see start being changed. Any reason to have it in a local? If you want to keep it for clarity make it a const int. Again same as above. > src/share/vm/oops/methodData.hpp: > > 753 protected: > 754 const int _nb_entries; > > I'd advocate for not abbreviating to ambiguous letters. Use the word you wanted to use. Ok. Roland. > > On Oct 8, 2013, at 9:22 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >> >> Follow up to 8023657: New type profiling points: arguments to call >> >> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >> >> The output of PrintMethodData is: >> >> 17 invokevirtual 3 >> 16 bci: 17 VirtualCallData count(0) entries(1) >> 'TestProfiling'(4744 1.00) >> argument types 0: stack(1) 'TestProfiling$C' >> 1: stack(2) 'TestProfiling$B' >> return type 'TestProfiling$C' >> >> Roland. > From vladimir.kozlov at oracle.com Wed Oct 9 09:02:30 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Oct 2013 09:02:30 -0700 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <5254E2FA.1000602@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> <524BEBC2.4030202@oracle.com> <524C4EA8.1020109@oracle.com> <524D6A32.5080003@oracle.com> <524DEB5B.1060603@oracle.com> <5254E2FA.1000602@oracle.com> Message-ID: <52557E16.7040800@oracle.com> Looks good. Albert, I agree with your comments. See below. Thanks, Vladimir On 10/8/13 10:00 PM, Albert Noll wrote: > Hi Vladimir, hi Christian, > > thanks for looking at the patch. > @Christian: I fixed the issues you brought up. > @Vladimir: See comments inline: > > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8023014/webrev.05/ > > > On 04.10.2013 00:10, Vladimir Kozlov wrote: >> c1_Compiler.cpp. Can you have next in header file since they are >> empty? And why you need them at all (C2Compiler does not have them)?: >> >> +Compiler::Compiler () {} >> +Compiler::~Compiler() {} >> > I need Compiler::Compiler() {}, otherwise I get the following error: > > Error: failed /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so, > because /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so: > undefined symbol: _ZN8CompilerC1Ev Okay. > > +Compiler::~Compiler() {} can be removed. > >> I think we can keep compiler objects (Compiler and c2Compiler) since >> they should be very small. You can keep your comment in >> shutdown_compiler_runtime() but remove commented code. >> > Done. >> Indention in CompileQueue::delete_all(): >> >> } >> _first = NULL; >> } >> > Done. >> >> In should_perform_shutdown() the _compiler_state could be changed >> >> before other threads reach "if (comp->is_state_failed())" check in >> >> init_compiler_runtime(). >> > True. I added a function should_exit(), which returns true if the state >> > if failed, or shutting down. >> >> You actually don't need to change state to shutting_shown. This state >> is not checked anywhere (you removed waiting loop). The 'failed' state >> can stay until the last thread change it to shut_down. So you don't >> need new method should_exit(). >> >> Looking more on get_buffer_blob() == null case and I think you don't >> need special C1 check in init_compiler_runtime() because it will not >> reach it. Compiler::initialize() set state to 'failed' if buffer is >> NULL so the first condition in init_compiler_runtime() will be true. >> > I think we need this check, since compiler initialization can be > successful and there is enough free > space in the code cache to allocate the buffer blob for the first couple > of threads, but not for all threads. > The test specifically tests this exit path. Yes, you are right. Only initialization thread will set the state to 'failed'. > > Many thanks again, > Albert > >> The test is fine. At least we have something. >> >> Thanks, >> Vladimir >> >> On 10/3/13 5:59 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for looking at the patch. See comments inline. >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~anoll/8023014/webrev.04/ >>> >>> >>> On 02.10.2013 18:49, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> In disable_compilation_forever() the comment does not correspond to >>>> code. >>>> >>> I removed the comment. >>>> In should_perform_shutdown() the _compiler_state could be changed >>>> before other threads reach "if (comp->is_state_failed())" check in >>>> init_compiler_runtime(). >>> True. I added a function should_exit(), which returns true if the state >>> if failed, or shutting down. >>>> Yes, decrementing with lock is fine, you are right. >>>> >>>> The message should say why we do shutdown (no space to initialize >>>> compiler runtime): >>>> warning("Shutting down compiler >>>> >>> The warning messages are now: >>> - "Shutting down compiler %s (no space to run compiler)" or >>> - "Initialization of %s thread failed (no space to run compiler thread)" >>> if a C1 compiler thread fails to allocate memory. >>>> Please, explain what references: >>>> >>>> + // We could delete compiler runtimes also. However, >>>> + // there are references to the compiler runtime(s) >>>> + // (e.g., by nmethods) which then fail. This can be >>>> >>> Done. >>>> It would be nice to have regression test for this. >>> I added a regression test, which checks that compiler threads exit, if >>> there is not sufficient free code cache >>> to init all threads. Testing a failing initialization of C2 is tricky, >>> since a C2 initialization failure depends on the >>> scheduling of the compiler threads. >>> >>> Thanks again, >>> Albert >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/2/13 2:47 AM, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks again for the feedback. I tested the patch as you proposed, >>>>> i.e., make sure that >>>>> the patch works if the C1 and/or C2 compiler fails to initialize. I >>>>> tested with up to 256 compiler >>>>> threads. >>>>> >>>>> To make sure that all compiler threads exit, I had to do additional >>>>> modifications in CompileQueue::get() >>>>> and the caller of this method. With these changes, one can also exit >>>>> compiler threads if -XX:-UseCodeCacheFlushing >>>>> is set, which is also contained in this webrev. >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ >>>>> >>>>> >>>>> See more comments inline: >>>>> >>>>> >>>>> On 01.10.2013 18:17, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> In general it looks good. Please, test it extensively with Tiered >>>>>> with codecache size enough to initialize one >>>>>> compiler but not an other to verify your code. >>>>>> >>>>> Done. >>>>>> I think you need to swap lock and decrement otherwise it will >>>>>> deadlock: >>>>>> >>>>>> +bool AbstractCompiler::should_perform_shutdown() { >>>>>> + MutexLocker only_one(CompileThread_lock); >>>>>> + _num_compiler_threads--; >>>>>> >>>>> I simplified this function. In fact it is fine if the last thread >>>>> (i.e., if _num_compiler_threads == 0) >>>>> does the shutdown. The while() statement is really not necessary. >>>>> However, we have to decrement >>>>> _num_compiler_threads when we hold the lock. Otherwise we are not >>>>> guaranteed to reach 0 >>>>> (-- is not atomic). >>>>> >>>>>> comp->set_shut_down(); and delete _compilers[0]; should be done by >>>>>> one thread I think. >>>>> Done. >>>>> >>>>>> >>>>>> Small note, you accidentally removed nl in c2compiler.cpp: >>>>>> >>>>>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> >>>>>> >>>>> Fixed. >>>>> >>>>> Thanks again, >>>>> Albert >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/1/13 12:27 AM, Albert Noll wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> thanks again for looking at the patch. See comments inline: >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>>>>>> >>>>>>> >>>>>>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>>>>>> Albert, >>>>>>>> >>>>>>>> There is small window between check and set_state where state can >>>>>>>> became initialized or still be uninitialized: >>>>>>>> + if (!is_initialized()) { >>>>>>>> + set_state(failed); >>>>>>>> >>>>>>>> so you may hit assert in set_state(). >>>>>>>> >>>>>>>> I think you need to call set_state(failed) only when C1 runtime is >>>>>>>> initialized after lock: >>>>>>>> >>>>>>>> if (should_perform_init()) { >>>>>>>> if (buffer_blob == NULL) { >>>>>>>> set_state(failed); >>>>>>>> } else { >>>>>>>> init_c1_runtime(); >>>>>>>> set_state(initialized); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>> You are right. I adapted the patch according to your suggestion. >>>>>>> >>>>>>>> In this case it will match behavior for C2 which means that you >>>>>>>> need to shutdown compilation since you was not able to >>>>>>>> initialize compilation runtime. It will require more code to do >>>>>>>> proper shutdown not just exiting thread (free >>>>>>>> compilation queues, resetting flags). An it will be more >>>>>>>> complicated for Tiered case (I think we can use simple >>>>>>>> approach to shutdown all compilations even if only one Compiler is >>>>>>>> not initialized since it is rare case). >>>>>>>> >>>>>>> I added code to shut-down compilation. If compiler runtime >>>>>>> initialization fails, a flag is set which disables >>>>>>> compilation forever. In the current >>>>>>> version, all compilers are disabled if C1 and/or C2 runtime >>>>>>> initialization fails (also in case of tiered compilation). I >>>>>>> think this solution is fine for >>>>>>> now, since a compiler runtime initialization failure should not >>>>>>> happen in practice. If it ever turns out to be a >>>>>>> problem, i.e., it is required that we >>>>>>> we use one compiler if the other compiler failed to initialize, I >>>>>>> suggest we fix this in another bug. The current bug >>>>>>> appears only due to an artificial >>>>>>> setting of the code cache size. >>>>>>> >>>>>>> Compiler shut-down is performed by one thread. This thread waits >>>>>>> until all compiler threads have exited to compiler >>>>>>> loop. The thread then >>>>>>> deletes all tasks from the compile queue, deletes the compiler >>>>>>> objects, and sets the objects to NULL. >>>>>>> >>>>>>> Please let me know if you think this solution is fine, or if there >>>>>>> are other things that need to be considered. >>>>>>> The current version passed jprt. >>>>>>> >>>>>>> Many thanks again, >>>>>>> Albert >>>>>>> >>>>>>>> If C1 runtime was initialized but we was not able to allocate >>>>>>>> buffer for some threads your current code in >>>>>>>> compileBroker.cpp will handle such case. So you don't need to set >>>>>>>> state to 'failed'. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> thanks for looking at the patch. >>>>>>>>> Here is the new webrev: >>>>>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> See comments inline: >>>>>>>>> >>>>>>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>>>>>> Thank you, Albert >>>>>>>>>> >>>>>>>>>> I would suggest to do TieredStartAtLevel changes separately, it >>>>>>>>>> is not >>>>>>>>>> related to this bug. >>>>>>>>>> >>>>>>>>> Done. >>>>>>>>>> Second, how we can guard the initialization with a field >>>>>>>>>> (_compiler_state and original _is_initialized) which is not >>>>>>>>>> static? >>>>>>>>>> >>>>>>>>>> You don't need separate local do_init in C*_Compiler.cpp since >>>>>>>>>> it is >>>>>>>>>> used only once: >>>>>>>>>> >>>>>>>>> Done. >>>>>>>>>> + if (should_perform_init()) { >>>>>>>>>> >>>>>>>>>> abstractCompiler.cpp: >>>>>>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>>>>>> check_prelock_state() called from Monitor::lock(): >>>>>>>>>> >>>>>>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>>>>>> || rank() == Mutex::special, "wrong thread state for >>>>>>>>>> using >>>>>>>>>> locks"); >>>>>>>>>> >>>>>>>>>> Compiler threads are Java threads, so you should be in VM state >>>>>>>>>> when >>>>>>>>>> lock. How you did not hit this assert? >>>>>>>>>> >>>>>>>>> The state transition from native to VM (and ResetNoHandleMark) is >>>>>>>>> now in >>>>>>>>> compileBroker.cpp:1543. >>>>>>>>>> >>>>>>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>>>>>> >>>>>>>>>> + // This method returns true for the first compiler thread that >>>>>>>>>> reaches that methos. >>>>>>>>>> >>>>>>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>>>>>> object created for each compilation): >>>>>>>>>> >>>>>>>>>> + // This thread will initialize the compiler object. >>>>>>>>>> >>>>>>>>>> Swap lines (and use 'runtime' in the comment): >>>>>>>>>> >>>>>>>>>> ! bool is_initialized () { return _compiler_state == >>>>>>>>>> initialized; } >>>>>>>>>> ! // Get/set state of compiler objects >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> c2compiler.cpp: >>>>>>>>>> >>>>>>>>>> C2Compiler:: is not needed: >>>>>>>>>> >>>>>>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Fixed the issues above. >>>>>>>>>> Should we exit Compiler thread which failed local buffer >>>>>>>>>> allocation >>>>>>>>>> instead parking? Why keep resources allocated for it? >>>>>>>>>> >>>>>>>>> You are right, there is no reason the keep these threads around. >>>>>>>>> Compiler threads wo are not initialized correctly >>>>>>>>> now exit the VM. >>>>>>>>> >>>>>>>>> The patch is currently in west queue. >>>>>>>>> >>>>>>>>> Many thanks again, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> could I have a review for this patch? >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Problem: C1/C2 compiler initialization can fail if there is not >>>>>>>>>>> enough >>>>>>>>>>> memory in the code cache to generate all stubs. >>>>>>>>>>> This problem occurs only with a small code cache size. >>>>>>>>>>> >>>>>>>>>>> Solution: Check correctness of (parts of) C1/C2 >>>>>>>>>>> initialization and >>>>>>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>>>>>> was not initialized correctly. >>>>>>>>>>> >>>>>>>>>>> Testing: jprt, test case, benchmarks >>>>>>>>>>> >>>>>>>>>>> This patch also contains a refactored version of compiler >>>>>>>>>>> object/thread >>>>>>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>>>>>> initialized prior entering the main compiler loop. In the old >>>>>>>>>>> version, >>>>>>>>>>> the check if the compiler/thread is initialized was >>>>>>>>>>> done in the main compiler loop (and hence before every >>>>>>>>>>> compilation). >>>>>>>>>>> >>>>>>>>>>> To continue execution with a limited code cache size, the code >>>>>>>>>>> types >>>>>>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>>>>>> be 'critical' allocations in the code cache, i.e., they must >>>>>>>>>>> use space >>>>>>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>>>>>> >>>>>>>>>>> In addition I removed some unued code. >>>>>>>>>>> >>>>>>>>>>> Many thanks in advance for reviewing. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Albert >>>>>>>>> >>>>>>> >>>>> >>> > From niclas.adlertz at oracle.com Wed Oct 9 09:14:11 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Wed, 09 Oct 2013 16:14:11 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131009161417.84E3462E98@hg.openjdk.java.net> Changeset: 98692a2d36d7 Author: adlertz Date: 2013-10-09 13:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/98692a2d36d7 8013830: [parfait] Uninitialised pointer 'Reachblock' may be used as argument Summary: Replace uninitialised pointer with NULL at argument. Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 4e7f99b70d9d Author: adlertz Date: 2013-10-09 05:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4e7f99b70d9d Merge - test/testlibrary/AssertsTest.java - test/testlibrary/OutputAnalyzerReportingTest.java - test/testlibrary/OutputAnalyzerTest.java From roland.westrelin at oracle.com Wed Oct 9 09:18:25 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Oct 2013 18:18:25 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <525491D2.5070203@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> Message-ID: Hi Vladimir, Thanks for reviewing this. > Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. > > Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. > > So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: > > class VirtualCallTypeData : public VirtualCallData { > private: > ! TypeStackSlotEntries _args; > ! ReturnTypeEntry _ret; > > Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). > > And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. ArgTypeEntries seems to imply it's only used for arguments. In the next change, it's used for parameters. That's why I named it TypeStackSlotEntries. What about this: http://cr.openjdk.java.net/~roland/8026054/webrev.01/ ? I kept TypeEntriesAtCall only for the static methods but otherwise refactored as you suggested, I think. This also includes Chris' feedback. Roland. > > Thanks, > Vladimir > > On 10/8/13 9:22 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >> >> Follow up to 8023657: New type profiling points: arguments to call >> >> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >> >> The output of PrintMethodData is: >> >> 17 invokevirtual 3 >> 16 bci: 17 VirtualCallData count(0) entries(1) >> 'TestProfiling'(4744 1.00) >> argument types 0: stack(1) 'TestProfiling$C' >> 1: stack(2) 'TestProfiling$B' >> return type 'TestProfiling$C' >> >> Roland. >> From vladimir.kozlov at oracle.com Wed Oct 9 10:21:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Oct 2013 10:21:16 -0700 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5254E72C.2050004@oracle.com> References: <5254E72C.2050004@oracle.com> Message-ID: <5255908C.1080308@oracle.com> Albert, Changes are fine but you need more testing. Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests with -Xcomp and without it). Also the bug report has link to test (jittest). Can you build and run it too to see if it solves the problem with small codecache? It fills codecache with osr nmethods. It is very delicate matter. There was a reason we did not remove OSR nmethod until corresponding klass is unloaded (yes, deoptimization can make it non-entrant). Unfortunately I don't remember it. May be John know. Non of inline caches are pointing to OSR nmethods since it is called only from Interpreter. There is transition phase at the start of OSR nmethod when it calls runtime to convert interpreter frame to compiled frame. And method has separate field for osr nmethods. Thanks, Vladimir On 10/8/13 10:18 PM, Albert Noll wrote: > Hi, > > could I have a review for this small patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8023191 > webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ > > > Problem: OSR methods are not removed from code cache to free space. > Solution: Remove OSR methods from code cache. OSR methods c an be made > not-entrant and are then removed from the code cache > likenon-OSR > methods. Other parts in the code (e.g., > deoptimization.cpp:1547) already make > OSR methods not-entrant. > > Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there > is an impact on performance. > > Many thanks in advance, > Albert From christian.thalinger at oracle.com Wed Oct 9 10:58:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 9 Oct 2013 10:58:40 -0700 Subject: RFR (XXS): 8020750: Node::get_int: guarantee(t != NULL) failed: must be con In-Reply-To: References: <43C6FE9C-6D37-4FFC-A70E-94F84F81E2F7@oracle.com> Message-ID: Thank you, Roland. On Oct 8, 2013, at 11:58 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~twisti/8020750/webrev.00/ > > That looks good to me. > > Roland. From vladimir.kozlov at oracle.com Wed Oct 9 11:44:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Oct 2013 11:44:34 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> Message-ID: <5255A412.1080901@oracle.com> On 10/9/13 9:18 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > >> Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. >> >> Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. >> >> So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: >> >> class VirtualCallTypeData : public VirtualCallData { >> private: >> ! TypeStackSlotEntries _args; >> ! ReturnTypeEntry _ret; >> >> Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). >> >> And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. > > ArgTypeEntries seems to imply it's only used for arguments. In the next change, it's used for parameters. That's why I named it TypeStackSlotEntries. I see, then may be CallTypeEntries. Again, we are not profiling stack slots. > > What about this: > http://cr.openjdk.java.net/~roland/8026054/webrev.01/ > ? It is better. About header_cell_count(), previous version was different. As I understand you always need cell_count cell to separate case when you have only 1 argument vs no profilable arguments but have ret type. Right? So my suggestion to have always ret_type cell will not help. Another question. You execute arguments profiling in assembler only if tag is CallTypeData or VirtualCallTypeData. But you don't do such check for return_type profiling. Why? About assembler. Why you need subl(tmp, 1) (there is no comment)? And why it is not done during stack_slot cell initialization? About C1 code for ret profiling. I see only new code in c1_LIRGenerator.cpp which calls profile_arg_type() and no new assembler. Is it enough? thanks, Vladimir > > I kept TypeEntriesAtCall only for the static methods but otherwise refactored as you suggested, I think. > This also includes Chris' feedback. > > Roland. > >> >> Thanks, >> Vladimir >> >> On 10/8/13 9:22 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >>> >>> Follow up to 8023657: New type profiling points: arguments to call >>> >>> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >>> >>> The output of PrintMethodData is: >>> >>> 17 invokevirtual 3 >>> 16 bci: 17 VirtualCallData count(0) entries(1) >>> 'TestProfiling'(4744 1.00) >>> argument types 0: stack(1) 'TestProfiling$C' >>> 1: stack(2) 'TestProfiling$B' >>> return type 'TestProfiling$C' >>> >>> Roland. >>> > From albert.noll at oracle.com Wed Oct 9 12:20:09 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 9 Oct 2013 21:20:09 +0200 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <52557E16.7040800@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> <524BEBC2.4030202@oracle.com> <524C4EA8.1020109@oracle.com> <524D6A32.5080003@oracle.com> <524DEB5B.1060603@oracle.com> <5254E2FA.1000602@oracle.com> <52557E16.7040800@oracle.com> Message-ID: <4E99742C-29CD-4D2F-A9BB-0C81281789FF@oracle.com> Thank you, Vladimir. Best, Albert Von meinem iPhone gesendet > Am 09.10.2013 um 18:02 schrieb Vladimir Kozlov : > > Looks good. > > Albert, I agree with your comments. See below. > > Thanks, > Vladimir > >> On 10/8/13 10:00 PM, Albert Noll wrote: >> Hi Vladimir, hi Christian, >> >> thanks for looking at the patch. >> @Christian: I fixed the issues you brought up. >> @Vladimir: See comments inline: >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~anoll/8023014/webrev.05/ >> >> >>> On 04.10.2013 00:10, Vladimir Kozlov wrote: >>> c1_Compiler.cpp. Can you have next in header file since they are >>> empty? And why you need them at all (C2Compiler does not have them)?: >>> >>> +Compiler::Compiler () {} >>> +Compiler::~Compiler() {} >> I need Compiler::Compiler() {}, otherwise I get the following error: >> >> Error: failed /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so, >> because /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so: >> undefined symbol: _ZN8CompilerC1Ev > > Okay. > >> >> +Compiler::~Compiler() {} can be removed. >> >>> I think we can keep compiler objects (Compiler and c2Compiler) since >>> they should be very small. You can keep your comment in >>> shutdown_compiler_runtime() but remove commented code. >> Done. >>> Indention in CompileQueue::delete_all(): >>> >>> } >>> _first = NULL; >>> } >> Done. >>> >> In should_perform_shutdown() the _compiler_state could be changed >>> >> before other threads reach "if (comp->is_state_failed())" check in >>> >> init_compiler_runtime(). >>> > True. I added a function should_exit(), which returns true if the state >>> > if failed, or shutting down. >>> >>> You actually don't need to change state to shutting_shown. This state >>> is not checked anywhere (you removed waiting loop). The 'failed' state >>> can stay until the last thread change it to shut_down. So you don't >>> need new method should_exit(). >>> >>> Looking more on get_buffer_blob() == null case and I think you don't >>> need special C1 check in init_compiler_runtime() because it will not >>> reach it. Compiler::initialize() set state to 'failed' if buffer is >>> NULL so the first condition in init_compiler_runtime() will be true. >> I think we need this check, since compiler initialization can be >> successful and there is enough free >> space in the code cache to allocate the buffer blob for the first couple >> of threads, but not for all threads. >> The test specifically tests this exit path. > > Yes, you are right. Only initialization thread will set the state to 'failed'. > >> >> Many thanks again, >> Albert >> >>> The test is fine. At least we have something. >>> >>> Thanks, >>> Vladimir >>> >>>> On 10/3/13 5:59 AM, Albert Noll wrote: >>>> Hi Vladimir, >>>> >>>> thanks for looking at the patch. See comments inline. >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.04/ >>>> >>>> >>>>> On 02.10.2013 18:49, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> In disable_compilation_forever() the comment does not correspond to >>>>> code. >>>> I removed the comment. >>>>> In should_perform_shutdown() the _compiler_state could be changed >>>>> before other threads reach "if (comp->is_state_failed())" check in >>>>> init_compiler_runtime(). >>>> True. I added a function should_exit(), which returns true if the state >>>> if failed, or shutting down. >>>>> Yes, decrementing with lock is fine, you are right. >>>>> >>>>> The message should say why we do shutdown (no space to initialize >>>>> compiler runtime): >>>>> warning("Shutting down compiler >>>> The warning messages are now: >>>> - "Shutting down compiler %s (no space to run compiler)" or >>>> - "Initialization of %s thread failed (no space to run compiler thread)" >>>> if a C1 compiler thread fails to allocate memory. >>>>> Please, explain what references: >>>>> >>>>> + // We could delete compiler runtimes also. However, >>>>> + // there are references to the compiler runtime(s) >>>>> + // (e.g., by nmethods) which then fail. This can be >>>> Done. >>>>> It would be nice to have regression test for this. >>>> I added a regression test, which checks that compiler threads exit, if >>>> there is not sufficient free code cache >>>> to init all threads. Testing a failing initialization of C2 is tricky, >>>> since a C2 initialization failure depends on the >>>> scheduling of the compiler threads. >>>> >>>> Thanks again, >>>> Albert >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> On 10/2/13 2:47 AM, Albert Noll wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thanks again for the feedback. I tested the patch as you proposed, >>>>>> i.e., make sure that >>>>>> the patch works if the C1 and/or C2 compiler fails to initialize. I >>>>>> tested with up to 256 compiler >>>>>> threads. >>>>>> >>>>>> To make sure that all compiler threads exit, I had to do additional >>>>>> modifications in CompileQueue::get() >>>>>> and the caller of this method. With these changes, one can also exit >>>>>> compiler threads if -XX:-UseCodeCacheFlushing >>>>>> is set, which is also contained in this webrev. >>>>>> >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ >>>>>> >>>>>> >>>>>> See more comments inline: >>>>>> >>>>>> >>>>>>> On 01.10.2013 18:17, Vladimir Kozlov wrote: >>>>>>> Albert, >>>>>>> >>>>>>> In general it looks good. Please, test it extensively with Tiered >>>>>>> with codecache size enough to initialize one >>>>>>> compiler but not an other to verify your code. >>>>>> Done. >>>>>>> I think you need to swap lock and decrement otherwise it will >>>>>>> deadlock: >>>>>>> >>>>>>> +bool AbstractCompiler::should_perform_shutdown() { >>>>>>> + MutexLocker only_one(CompileThread_lock); >>>>>>> + _num_compiler_threads--; >>>>>> I simplified this function. In fact it is fine if the last thread >>>>>> (i.e., if _num_compiler_threads == 0) >>>>>> does the shutdown. The while() statement is really not necessary. >>>>>> However, we have to decrement >>>>>> _num_compiler_threads when we hold the lock. Otherwise we are not >>>>>> guaranteed to reach 0 >>>>>> (-- is not atomic). >>>>>> >>>>>>> comp->set_shut_down(); and delete _compilers[0]; should be done by >>>>>>> one thread I think. >>>>>> Done. >>>>>> >>>>>>> >>>>>>> Small note, you accidentally removed nl in c2compiler.cpp: >>>>>>> >>>>>>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>>> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>> Fixed. >>>>>> >>>>>> Thanks again, >>>>>> Albert >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> On 10/1/13 12:27 AM, Albert Noll wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> thanks again for looking at the patch. See comments inline: >>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>>>>>>> >>>>>>>> >>>>>>>>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>>>>>>> Albert, >>>>>>>>> >>>>>>>>> There is small window between check and set_state where state can >>>>>>>>> became initialized or still be uninitialized: >>>>>>>>> + if (!is_initialized()) { >>>>>>>>> + set_state(failed); >>>>>>>>> >>>>>>>>> so you may hit assert in set_state(). >>>>>>>>> >>>>>>>>> I think you need to call set_state(failed) only when C1 runtime is >>>>>>>>> initialized after lock: >>>>>>>>> >>>>>>>>> if (should_perform_init()) { >>>>>>>>> if (buffer_blob == NULL) { >>>>>>>>> set_state(failed); >>>>>>>>> } else { >>>>>>>>> init_c1_runtime(); >>>>>>>>> set_state(initialized); >>>>>>>>> } >>>>>>>>> } >>>>>>>> You are right. I adapted the patch according to your suggestion. >>>>>>>> >>>>>>>>> In this case it will match behavior for C2 which means that you >>>>>>>>> need to shutdown compilation since you was not able to >>>>>>>>> initialize compilation runtime. It will require more code to do >>>>>>>>> proper shutdown not just exiting thread (free >>>>>>>>> compilation queues, resetting flags). An it will be more >>>>>>>>> complicated for Tiered case (I think we can use simple >>>>>>>>> approach to shutdown all compilations even if only one Compiler is >>>>>>>>> not initialized since it is rare case). >>>>>>>> I added code to shut-down compilation. If compiler runtime >>>>>>>> initialization fails, a flag is set which disables >>>>>>>> compilation forever. In the current >>>>>>>> version, all compilers are disabled if C1 and/or C2 runtime >>>>>>>> initialization fails (also in case of tiered compilation). I >>>>>>>> think this solution is fine for >>>>>>>> now, since a compiler runtime initialization failure should not >>>>>>>> happen in practice. If it ever turns out to be a >>>>>>>> problem, i.e., it is required that we >>>>>>>> we use one compiler if the other compiler failed to initialize, I >>>>>>>> suggest we fix this in another bug. The current bug >>>>>>>> appears only due to an artificial >>>>>>>> setting of the code cache size. >>>>>>>> >>>>>>>> Compiler shut-down is performed by one thread. This thread waits >>>>>>>> until all compiler threads have exited to compiler >>>>>>>> loop. The thread then >>>>>>>> deletes all tasks from the compile queue, deletes the compiler >>>>>>>> objects, and sets the objects to NULL. >>>>>>>> >>>>>>>> Please let me know if you think this solution is fine, or if there >>>>>>>> are other things that need to be considered. >>>>>>>> The current version passed jprt. >>>>>>>> >>>>>>>> Many thanks again, >>>>>>>> Albert >>>>>>>> >>>>>>>>> If C1 runtime was initialized but we was not able to allocate >>>>>>>>> buffer for some threads your current code in >>>>>>>>> compileBroker.cpp will handle such case. So you don't need to set >>>>>>>>> state to 'failed'. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> thanks for looking at the patch. >>>>>>>>>> Here is the new webrev: >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> See comments inline: >>>>>>>>>> >>>>>>>>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>>>>>>> Thank you, Albert >>>>>>>>>>> >>>>>>>>>>> I would suggest to do TieredStartAtLevel changes separately, it >>>>>>>>>>> is not >>>>>>>>>>> related to this bug. >>>>>>>>>> Done. >>>>>>>>>>> Second, how we can guard the initialization with a field >>>>>>>>>>> (_compiler_state and original _is_initialized) which is not >>>>>>>>>>> static? >>>>>>>>>>> >>>>>>>>>>> You don't need separate local do_init in C*_Compiler.cpp since >>>>>>>>>>> it is >>>>>>>>>>> used only once: >>>>>>>>>> Done. >>>>>>>>>>> + if (should_perform_init()) { >>>>>>>>>>> >>>>>>>>>>> abstractCompiler.cpp: >>>>>>>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>>>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>>>>>>> check_prelock_state() called from Monitor::lock(): >>>>>>>>>>> >>>>>>>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>>>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>>>>>>> || rank() == Mutex::special, "wrong thread state for >>>>>>>>>>> using >>>>>>>>>>> locks"); >>>>>>>>>>> >>>>>>>>>>> Compiler threads are Java threads, so you should be in VM state >>>>>>>>>>> when >>>>>>>>>>> lock. How you did not hit this assert? >>>>>>>>>> The state transition from native to VM (and ResetNoHandleMark) is >>>>>>>>>> now in >>>>>>>>>> compileBroker.cpp:1543. >>>>>>>>>>> >>>>>>>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>>>>>>> >>>>>>>>>>> + // This method returns true for the first compiler thread that >>>>>>>>>>> reaches that methos. >>>>>>>>>>> >>>>>>>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>>>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>>>>>>> object created for each compilation): >>>>>>>>>>> >>>>>>>>>>> + // This thread will initialize the compiler object. >>>>>>>>>>> >>>>>>>>>>> Swap lines (and use 'runtime' in the comment): >>>>>>>>>>> >>>>>>>>>>> ! bool is_initialized () { return _compiler_state == >>>>>>>>>>> initialized; } >>>>>>>>>>> ! // Get/set state of compiler objects >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> c2compiler.cpp: >>>>>>>>>>> >>>>>>>>>>> C2Compiler:: is not needed: >>>>>>>>>>> >>>>>>>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>>>>>> Fixed the issues above. >>>>>>>>>>> Should we exit Compiler thread which failed local buffer >>>>>>>>>>> allocation >>>>>>>>>>> instead parking? Why keep resources allocated for it? >>>>>>>>>> You are right, there is no reason the keep these threads around. >>>>>>>>>> Compiler threads wo are not initialized correctly >>>>>>>>>> now exit the VM. >>>>>>>>>> >>>>>>>>>> The patch is currently in west queue. >>>>>>>>>> >>>>>>>>>> Many thanks again, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> could I have a review for this patch? >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Problem: C1/C2 compiler initialization can fail if there is not >>>>>>>>>>>> enough >>>>>>>>>>>> memory in the code cache to generate all stubs. >>>>>>>>>>>> This problem occurs only with a small code cache size. >>>>>>>>>>>> >>>>>>>>>>>> Solution: Check correctness of (parts of) C1/C2 >>>>>>>>>>>> initialization and >>>>>>>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>>>>>>> was not initialized correctly. >>>>>>>>>>>> >>>>>>>>>>>> Testing: jprt, test case, benchmarks >>>>>>>>>>>> >>>>>>>>>>>> This patch also contains a refactored version of compiler >>>>>>>>>>>> object/thread >>>>>>>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>>>>>>> initialized prior entering the main compiler loop. In the old >>>>>>>>>>>> version, >>>>>>>>>>>> the check if the compiler/thread is initialized was >>>>>>>>>>>> done in the main compiler loop (and hence before every >>>>>>>>>>>> compilation). >>>>>>>>>>>> >>>>>>>>>>>> To continue execution with a limited code cache size, the code >>>>>>>>>>>> types >>>>>>>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>>>>>>> be 'critical' allocations in the code cache, i.e., they must >>>>>>>>>>>> use space >>>>>>>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>>>>>>> >>>>>>>>>>>> In addition I removed some unued code. >>>>>>>>>>>> >>>>>>>>>>>> Many thanks in advance for reviewing. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Albert >> From chris.plummer at oracle.com Wed Oct 9 12:24:17 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 09 Oct 2013 12:24:17 -0700 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5255908C.1080308@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> Message-ID: <5255AD61.5040503@oracle.com> Hi Albert, I recall having experimented with this same change and started getting crashes when using a small code cache and inducing a lot of sweeping and flushing. This was earlier in the year, and I also had made a couple of other changes that may have been the cause of the crashes, but I was highly suspect of this one. I'd suggest running Nashorn with the v8 benchmark and SpecJVM98 with about 3800k codecache. Also use -client if making the codecache this small. This is roughly what I was doing when I saw crashes, but it was long ago and I forget all the details. You may want to try other codecaches of similar sizes. The key is making sure it is small enough to induce some performance regression (maybe 10% to 50%) so you know the codecache flushing code is being heavily stressed. cheers, Chris On 10/9/13 10:21 AM, Vladimir Kozlov wrote: > Albert, > > Changes are fine but you need more testing. > > Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk > tests with -Xcomp and without it). > > Also the bug report has link to test (jittest). Can you build and run > it too to see if it solves the problem with small codecache? It fills > codecache with osr nmethods. > > It is very delicate matter. There was a reason we did not remove OSR > nmethod until corresponding klass is unloaded (yes, deoptimization can > make it non-entrant). Unfortunately I don't remember it. May be John > know. Non of inline caches are pointing to OSR nmethods since it is > called only from Interpreter. There is transition phase at the start > of OSR nmethod when it calls runtime to convert interpreter frame to > compiled frame. And method has separate field for osr nmethods. > > Thanks, > Vladimir > > On 10/8/13 10:18 PM, Albert Noll wrote: >> Hi, >> >> could I have a review for this small patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8023191 >> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ >> >> >> Problem: OSR methods are not removed from code cache to free space. >> Solution: Remove OSR methods from code cache. OSR methods c an be made >> not-entrant and are then removed from the code cache >> likenon-OSR >> methods. Other parts in the code (e.g., >> deoptimization.cpp:1547) already make >> OSR methods not-entrant. >> >> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there >> is an impact on performance. >> >> Many thanks in advance, >> Albert From john.r.rose at oracle.com Wed Oct 9 12:40:45 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 9 Oct 2013 12:40:45 -0700 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5255908C.1080308@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> Message-ID: On Oct 9, 2013, at 10:21 AM, Vladimir Kozlov wrote: > Changes are fine but you need more testing. > > Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests with -Xcomp and without it). > > Also the bug report has link to test (jittest). Can you build and run it too to see if it solves the problem with small codecache? It fills codecache with osr nmethods. > > It is very delicate matter. There was a reason we did not remove OSR nmethod until corresponding klass is unloaded (yes, deoptimization can make it non-entrant). Unfortunately I don't remember it. May be John know. IIRC we introduced OSR n-methods long before we figured out the right way to do sweeping and n-method flushing. Managing regular n-methods requires lots of tricks, and OSR n-methods have always been subject to different rules. I suspect the current rules for OSRs are conservative simply to avoid interactions with the sweeper. We need to clarify the rules for determining n-method liveness and storage management so there is less mystery. We are making progress on this. Along the same line, I would like to see less special-purpose machinery for managing OSR code, and an emphasis on allowing Java methods to have multiple variant compilations, with normal and OSR modes being special cases. Other special cases might be "optimized but re-profiling" or "partially optimized and suitable for OSR or deopt" or "compiled for a coprocessor" or "loop-customized for a given closure". In some cases the variant is a "plug compatible" replacement for the main variant; in some cases it is a strength reduced version (loop customization); and in some cases it is special-purpose code (for OSR entry or GPU execution). > Non of inline caches are pointing to OSR nmethods since it is called only from Interpreter. There is transition phase at the start of OSR nmethod when it calls runtime to convert interpreter frame to compiled frame. And method has separate field for osr nmethods. Extending the point above, there should (at most) one field in a methodOop that points to a linked list of n-method versions, with an open-ended set of possibilities. Most methods have no n-methods at all, so this has interactions with density. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131009/36be77e2/attachment-0001.html From azeem.jiva at oracle.com Wed Oct 9 12:44:43 2013 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Wed, 9 Oct 2013 12:44:43 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <5255A412.1080901@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> <5255A412.1080901@oracle.com> Message-ID: <87F507B4-A465-486C-850A-D5818D19EDA6@oracle.com> Roland, I don't see any new tests with this change. Do you think the current set of tests are sufficient for this change? -- Azeem Jiva @javawithjiva On Oct 9, 2013, at 11:44 AM, Vladimir Kozlov wrote: > On 10/9/13 9:18 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >> Thanks for reviewing this. >> >>> Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. >>> >>> Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. >>> >>> So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: >>> >>> class VirtualCallTypeData : public VirtualCallData { >>> private: >>> ! TypeStackSlotEntries _args; >>> ! ReturnTypeEntry _ret; >>> >>> Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). >>> >>> And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. >> >> ArgTypeEntries seems to imply it's only used for arguments. In the next change, it's used for parameters. That's why I named it TypeStackSlotEntries. > > I see, then may be CallTypeEntries. Again, we are not profiling stack slots. > >> >> What about this: >> http://cr.openjdk.java.net/~roland/8026054/webrev.01/ >> ? > > It is better. About header_cell_count(), previous version was different. As I understand you always need cell_count cell to separate case when you have only 1 argument vs no profilable arguments but have ret type. Right? So my suggestion to have always ret_type cell will not help. > > Another question. You execute arguments profiling in assembler only if tag is CallTypeData or VirtualCallTypeData. But you don't do such check for return_type profiling. Why? > > About assembler. Why you need subl(tmp, 1) (there is no comment)? And why it is not done during stack_slot cell initialization? > > About C1 code for ret profiling. I see only new code in c1_LIRGenerator.cpp which calls profile_arg_type() and no new assembler. Is it enough? > > thanks, > Vladimir > >> >> I kept TypeEntriesAtCall only for the static methods but otherwise refactored as you suggested, I think. >> This also includes Chris' feedback. >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/8/13 9:22 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >>>> >>>> Follow up to 8023657: New type profiling points: arguments to call >>>> >>>> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >>>> >>>> The output of PrintMethodData is: >>>> >>>> 17 invokevirtual 3 >>>> 16 bci: 17 VirtualCallData count(0) entries(1) >>>> 'TestProfiling'(4744 1.00) >>>> argument types 0: stack(1) 'TestProfiling$C' >>>> 1: stack(2) 'TestProfiling$B' >>>> return type 'TestProfiling$C' >>>> >>>> Roland. >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131009/afde507a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131009/afde507a/signature.asc From christian.thalinger at oracle.com Wed Oct 9 14:32:30 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 09 Oct 2013 21:32:30 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Message-ID: <20131009213232.7FA9162EB1@hg.openjdk.java.net> Changeset: 46ef27bcacb3 Author: twisti Date: 2013-10-09 11:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/46ef27bcacb3 8020750: Node::get_int: guarantee(t != NULL) failed: must be con Reviewed-by: kvn, roland ! src/share/vm/opto/ifnode.cpp From roland.westrelin at oracle.com Wed Oct 9 14:37:21 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Oct 2013 23:37:21 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <5255A412.1080901@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> <5255A412.1080901@oracle.com> Message-ID: <2635463E-4729-44A0-9AC3-7755E04CF726@oracle.com> Thanks Vladimir for taking another look. See inlined. On Oct 9, 2013, at 8:44 PM, Vladimir Kozlov wrote: > On 10/9/13 9:18 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >> Thanks for reviewing this. >> >>> Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. >>> >>> Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. >>> >>> So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: >>> >>> class VirtualCallTypeData : public VirtualCallData { >>> private: >>> ! TypeStackSlotEntries _args; >>> ! ReturnTypeEntry _ret; >>> >>> Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). >>> >>> And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. >> >> ArgTypeEntries seems to imply it's only used for arguments. In the next change, it's used for parameters. That's why I named it TypeStackSlotEntries. > > I see, then may be CallTypeEntries. Again, we are not profiling stack slots. That would sound quite confusing if I indeed keep TypeEntriesAtCall. We are not profiling stack slots but we are keeping stack slots together with the profiling. The first profiling change is in the jprt queue so if the name is changed that will happen with this second change. > >> >> What about this: >> http://cr.openjdk.java.net/~roland/8026054/webrev.01/ >> ? > > It is better. About header_cell_count(), previous version was different. As I understand you always need cell_count cell to separate case when you have only 1 argument vs no profilable arguments but have ret type. Right? So my suggestion to have always ret_type cell will not help. Yes it's right. The previous version would not include a cell count if return value profiling was off and the upper bound on the number of arguments was 1. Then CallTypeData/VirtualCallTypeData would only exist for calls where we would have one and only one argument to profile. You're right that it's confusing and overkill to optimize for this rare case. > > Another question. You execute arguments profiling in assembler only if tag is CallTypeData or VirtualCallTypeData. But you don't do such check for return_type profiling. Why? Thanks for spotting that. It's a bug. I used to only have the option to turn profiling for return values on and off. If it's on and a object is returned, we profile. Otherwise we don't. But with the current change, we can decide to profile only for JSR292 and in this case, it's not sufficient to find a returned value that is an object to know whether to profile or not. The problem is that the profiling code at the call moves the mdp right after the cells to do the profiling at the invoke (we may return to the interpreter after a deopt so it was I think easier to move the mdp past the current VirtualCallTypeData/CallTypeData rather than modify the deopt code to restore the mdp at the location where the return value must be done). I think the easiest way to fix this is to add this code: void InterpreterMacroAssembler::profile_return_type(Register mdp, Register ret, Register tmp) { + assert_different_registers(mdp, ret, tmp, rsi); if (ProfileInterpreter && MethodData::profile_return()) { Label profile_continue, done; test_method_data_pointer(mdp, profile_continue); + if (MethodData::profile_return_jsr292_only()) { + Label do_profile; + cmpb(Address(rsi, 0), Bytecodes::_invokedynamic); + jcc(Assembler::equal, do_profile); + cmpb(Address(rsi, 0), Bytecodes::_invokehandle); + jcc(Assembler::equal, do_profile); + get_method(tmp); + cmpb(Address(tmp, Method::intrinsic_id_offset_in_bytes()), vmIntrinsics::_compiledLambdaForm); + jcc(Assembler::notEqual, profile_continue); + + bind(do_profile); + } + Address mdo_ret_addr(mdp, -in_bytes(ReturnTypeEntry::size())); mov(tmp, ret); profile_obj_type(tmp, mdo_ret_addr); > > About assembler. Why you need subl(tmp, 1) (there is no comment)? And why it is not done during stack_slot cell initialization? If you have a method with a single argument, it is at slot 0. Number of arguments is 1. 1 - 0 = 1 but the actual offset compared to sp is 1 - 0 - 1 = 0. That's where the 1 is coming from. > > About C1 code for ret profiling. I see only new code in c1_LIRGenerator.cpp which calls profile_arg_type() and no new assembler. Is it enough? It is. The code in c1_LIRAssembler_x86.cpp handles profiling of one object in all cases (arguments, return, parameters). LIRGenerator::profile_arg_type() generates a LIR instruction with this: __ profile_type(new LIR_Address(mdp, md_offset, T_METADATA), value.result(), exact_klass, profiled_k, new_pointer_register(), not_null, exact_signature_k != NULL); that is later emitted with the code in c1_LIRAssembler_x86.cpp I'll send a new webrev tomorrow. Roland. > > thanks, > Vladimir > >> >> I kept TypeEntriesAtCall only for the static methods but otherwise refactored as you suggested, I think. >> This also includes Chris' feedback. >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/8/13 9:22 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >>>> >>>> Follow up to 8023657: New type profiling points: arguments to call >>>> >>>> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >>>> >>>> The output of PrintMethodData is: >>>> >>>> 17 invokevirtual 3 >>>> 16 bci: 17 VirtualCallData count(0) entries(1) >>>> 'TestProfiling'(4744 1.00) >>>> argument types 0: stack(1) 'TestProfiling$C' >>>> 1: stack(2) 'TestProfiling$B' >>>> return type 'TestProfiling$C' >>>> >>>> Roland. >>>> >> From roland.westrelin at oracle.com Wed Oct 9 14:38:18 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 9 Oct 2013 23:38:18 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <87F507B4-A465-486C-850A-D5818D19EDA6@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> <5255A412.1080901@oracle.com> <87F507B4-A465-486C-850A-D5818D19EDA6@oracle.com> Message-ID: Hi Azeem, > I don't see any new tests with this change. Do you think the current set of tests are sufficient for this change? Every JSR 292 test we have will trigger the new code. That should provide pretty good coverage. Roland. From niclas.adlertz at oracle.com Wed Oct 9 15:08:31 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 10 Oct 2013 00:08:31 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Message-ID: <5255D3DF.4090104@oracle.com> Hi all, When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes bigger than 65535. To solve this I've doubled that max value of _mask_size. Appreciate feedback on this. Should we increase it by more? Or find another solution for this? Or file a future enhancement bug to solve this in a cleaner way later on? (I've ran CTW + JPRT tests) WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8011415 Kind Regards, Niclas Adlertz From igor.veresov at oracle.com Wed Oct 9 15:11:04 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 9 Oct 2013 15:11:04 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Message-ID: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> String concat optimization optimization collapses the pattern StringBuffer x = new StringBuffer(); x.append(y); x.append(z); x.toString(); into a single allocation of a string and forming the result directly. All possible deopts that may happen in the optimized code restart this pattern from the beginning (starting from the StringBuffer allocation). That means that the whole pattern must me side-effect free. Existing code verifies that the pattern is sound from the control flow point of view, but omits the memory flow verification. This leaves a possibility for a computation on an argument of append() to have side effects. The fix adds memory flow analysis to find the possibly offending stores. We iterate up the memory graph (doing DFS) finding all possible simple paths starting from an append call, until we see the next append call, or a StringBuffer constructor. Then we analyze the path to see if it contains side effects. The analysis is exponential, so we limit the number of iterations. Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ Testing: eyeballing the graph, the failing tests, jprt igor From vladimir.kozlov at oracle.com Wed Oct 9 15:18:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Oct 2013 15:18:13 -0700 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5255908C.1080308@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> Message-ID: <5255D625.1090609@oracle.com> On 10/9/13 10:21 AM, Vladimir Kozlov wrote: > Albert, > > Changes are fine but you need more testing. > > Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests > with -Xcomp and without it). > > Also the bug report has link to test (jittest). Can you build and run it > too to see if it solves the problem with small codecache? It fills > codecache with osr nmethods. > > It is very delicate matter. There was a reason we did not remove OSR > nmethod until corresponding klass is unloaded (yes, deoptimization can > make it non-entrant). Unfortunately I don't remember it. May be John > know. Non of inline caches are pointing to OSR nmethods since it is > called only from Interpreter. There is transition phase at the start of > OSR nmethod when it calls runtime to convert interpreter frame to > compiled frame. And method has separate field for osr nmethods. I think I dig out the answer. First, the last statement in previous mail is wrong. The method object does not have reference to osr nmethods. Each java method can have several alive OSR nmethods for different bcis. Instead method's holder class has list of all OSR nmethods associated with all methods of this class. Each time we do osr lookup we go through this list. Since method does not have reference to OSR the original flushing (speculative disconnection) could not be implemented for OSR nmethods. Second. Originally osr nmethod were not cleaned up from codecache. Here is the comment and the code in nmethod::make_not_entrant_or_zombie() from long time ago: // Code for an on-stack-replacement nmethod is removed when a class gets unloaded. // They never become zombie/non-entrant, so the nmethod sweeper will never remove // them. Instead the entry_bci is set to InvalidOSREntryBci, so the osr nmethod // will never be used anymore. That the nmethods only gets removed when class unloading // happens, make life much simpler, since the nmethods are not just going to disappear // out of the blue. if (is_osr_only_method()) { if (osr_entry_bci() != InvalidOSREntryBci) { // only log this once log_state_change(state); } invalidate_osr_method(); return; } This code was changed by Tom for 5057818 4 years ago to allow cleanup unused OSR nmethods from codecache: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/032260830071 Third, I think those changes are not complete. nmethod::invalidate_osr_method() should check for _entry_bci == InvalidOSREntryBci to avoid lookup through osr list again after nmethod change from non_entrant to zombie (invalidate_osr_method() is called each time make_not_entrant_or_zombie() is called). May be other places. Note, when we process osr nmethod::_code should not be touched since it is pointing to normal compiled nmethod which could still be alive. Thanks, Vladimir > > Thanks, > Vladimir > > On 10/8/13 10:18 PM, Albert Noll wrote: >> Hi, >> >> could I have a review for this small patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8023191 >> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ >> >> >> Problem: OSR methods are not removed from code cache to free space. >> Solution: Remove OSR methods from code cache. OSR methods c an be made >> not-entrant and are then removed from the code cache >> likenon-OSR >> methods. Other parts in the code (e.g., >> deoptimization.cpp:1547) already make >> OSR methods not-entrant. >> >> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there >> is an impact on performance. >> >> Many thanks in advance, >> Albert From vladimir.kozlov at oracle.com Wed Oct 9 16:51:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Oct 2013 16:51:31 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <2635463E-4729-44A0-9AC3-7755E04CF726@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> <5255A412.1080901@oracle.com> <2635463E-4729-44A0-9AC3-7755E04CF726@oracle.com> Message-ID: <5255EC03.5090307@oracle.com> Suggested fix for profile_return_type() seems reasonable. Add comment why we do that. Thanks, Vladimir On 10/9/13 2:37 PM, Roland Westrelin wrote: > Thanks Vladimir for taking another look. See inlined. > > On Oct 9, 2013, at 8:44 PM, Vladimir Kozlov wrote: > >> On 10/9/13 9:18 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> Thanks for reviewing this. >>> >>>> Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. >>>> >>>> Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. >>>> >>>> So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: >>>> >>>> class VirtualCallTypeData : public VirtualCallData { >>>> private: >>>> ! TypeStackSlotEntries _args; >>>> ! ReturnTypeEntry _ret; >>>> >>>> Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). >>>> >>>> And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. >>> >>> ArgTypeEntries seems to imply it's only used for arguments. In the next change, it's used for parameters. That's why I named it TypeStackSlotEntries. >> >> I see, then may be CallTypeEntries. Again, we are not profiling stack slots. > > That would sound quite confusing if I indeed keep TypeEntriesAtCall. We are not profiling stack slots but we are keeping stack slots together with the profiling. The first profiling change is in the jprt queue so if the name is changed that will happen with this second change. > >> >>> >>> What about this: >>> http://cr.openjdk.java.net/~roland/8026054/webrev.01/ >>> ? >> >> It is better. About header_cell_count(), previous version was different. As I understand you always need cell_count cell to separate case when you have only 1 argument vs no profilable arguments but have ret type. Right? So my suggestion to have always ret_type cell will not help. > > Yes it's right. The previous version would not include a cell count if return value profiling was off and the upper bound on the number of arguments was 1. Then CallTypeData/VirtualCallTypeData would only exist for calls where we would have one and only one argument to profile. You're right that it's confusing and overkill to optimize for this rare case. > >> >> Another question. You execute arguments profiling in assembler only if tag is CallTypeData or VirtualCallTypeData. But you don't do such check for return_type profiling. Why? > > Thanks for spotting that. It's a bug. I used to only have the option to turn profiling for return values on and off. If it's on and a object is returned, we profile. Otherwise we don't. But with the current change, we can decide to profile only for JSR292 and in this case, it's not sufficient to find a returned value that is an object to know whether to profile or not. The problem is that the profiling code at the call moves the mdp right after the cells to do the profiling at the invoke (we may return to the interpreter after a deopt so it was I think easier to move the mdp past the current VirtualCallTypeData/CallTypeData rather than modify the deopt code to restore the mdp at the location where the return value must be done). I think the easiest way to fix this is to add this code: > > void InterpreterMacroAssembler::profile_return_type(Register mdp, Register ret, Register tmp) { > + assert_different_registers(mdp, ret, tmp, rsi); > if (ProfileInterpreter && MethodData::profile_return()) { > Label profile_continue, done; > > test_method_data_pointer(mdp, profile_continue); > > + if (MethodData::profile_return_jsr292_only()) { > + Label do_profile; > + cmpb(Address(rsi, 0), Bytecodes::_invokedynamic); > + jcc(Assembler::equal, do_profile); > + cmpb(Address(rsi, 0), Bytecodes::_invokehandle); > + jcc(Assembler::equal, do_profile); > + get_method(tmp); > + cmpb(Address(tmp, Method::intrinsic_id_offset_in_bytes()), vmIntrinsics::_compiledLambdaForm); > + jcc(Assembler::notEqual, profile_continue); > + > + bind(do_profile); > + } > + > Address mdo_ret_addr(mdp, -in_bytes(ReturnTypeEntry::size())); > mov(tmp, ret); > profile_obj_type(tmp, mdo_ret_addr); > > > >> >> About assembler. Why you need subl(tmp, 1) (there is no comment)? And why it is not done during stack_slot cell initialization? > > If you have a method with a single argument, it is at slot 0. Number of arguments is 1. 1 - 0 = 1 but the actual offset compared to sp is 1 - 0 - 1 = 0. > That's where the 1 is coming from. > >> >> About C1 code for ret profiling. I see only new code in c1_LIRGenerator.cpp which calls profile_arg_type() and no new assembler. Is it enough? > > It is. The code in c1_LIRAssembler_x86.cpp handles profiling of one object in all cases (arguments, return, parameters). LIRGenerator::profile_arg_type() generates a LIR instruction with this: > > __ profile_type(new LIR_Address(mdp, md_offset, T_METADATA), > value.result(), exact_klass, profiled_k, new_pointer_register(), not_null, exact_signature_k != NULL); > > that is later emitted with the code in c1_LIRAssembler_x86.cpp > > I'll send a new webrev tomorrow. > > Roland. > >> >> thanks, >> Vladimir >> >>> >>> I kept TypeEntriesAtCall only for the static methods but otherwise refactored as you suggested, I think. >>> This also includes Chris' feedback. >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/8/13 9:22 AM, Roland Westrelin wrote: >>>>> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >>>>> >>>>> Follow up to 8023657: New type profiling points: arguments to call >>>>> >>>>> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >>>>> >>>>> The output of PrintMethodData is: >>>>> >>>>> 17 invokevirtual 3 >>>>> 16 bci: 17 VirtualCallData count(0) entries(1) >>>>> 'TestProfiling'(4744 1.00) >>>>> argument types 0: stack(1) 'TestProfiling$C' >>>>> 1: stack(2) 'TestProfiling$B' >>>>> return type 'TestProfiling$C' >>>>> >>>>> Roland. >>>>> >>> > From vladimir.kozlov at oracle.com Wed Oct 9 18:29:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Oct 2013 18:29:37 -0700 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5255D3DF.4090104@oracle.com> References: <5255D3DF.4090104@oracle.com> Message-ID: <52560301.2060700@oracle.com> Can you use 0xFFFFF format? It will *8 but it should be fine since we need a big number. I am little worry that it (mask_size()) is used somewhere in a code which expects 16bit value only. Could you look? Note for reviewers: lo_degree() { return degree() <= degrees_of_freedom(); } degrees_of_freedom() { return mask_size() - _num_regs; } degree() { return _eff_degree; } uint _eff_degree; // Effective degree: Sum of neighbors _num_regs Thanks, Vladimir On 10/9/13 3:08 PM, Niclas Adlertz wrote: > Hi all, > > When compiling very big methods, in this particular case a method of > 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still > have lo_degree() == false. This because the _mask_size of 'l' can be at > most 65535, at the same time 'l' is interfering with so many other live > ranges that the value of _eff_degree becomes bigger than 65535. > > To solve this I've doubled that max value of _mask_size. > Appreciate feedback on this. Should we increase it by more? Or find > another solution for this? Or file a future enhancement bug to solve > this in a cleaner way later on? > > (I've ran CTW + JPRT tests) > > WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8011415 > > Kind Regards, > Niclas Adlertz From igor.veresov at oracle.com Wed Oct 9 19:39:17 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 9 Oct 2013 19:39:17 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> Message-ID: I've update the code a bit. I decided to share the arrays I use for traversal between the calls to path_has_side_effects(). On Oct 9, 2013, at 3:11 PM, Igor Veresov wrote: > String concat optimization optimization collapses the pattern > > StringBuffer x = new StringBuffer(); > x.append(y); > x.append(z); > x.toString(); > > into a single allocation of a string and forming the result directly. All possible deopts that may happen in the optimized code restart this pattern from the beginning (starting from the StringBuffer allocation). That means that the whole pattern must me side-effect free. Existing code verifies that the pattern is sound from the control flow point of view, but omits the memory flow verification. This leaves a possibility for a computation on an argument of append() to have side effects. The fix adds memory flow analysis to find the possibly offending stores. We iterate up the memory graph (doing DFS) finding all possible simple paths starting from an append call, until we see the next append call, or a StringBuffer constructor. Then we analyze the path to see if it contains side effects. The analysis is exponential, so we limit the number of iterations. > > Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ > > Testing: eyeballing the graph, the failing tests, jprt > > igor From vladimir.kozlov at oracle.com Wed Oct 9 22:57:26 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 09 Oct 2013 22:57:26 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> Message-ID: <525641C6.8030702@oracle.com> + // Find if any path from start_mem to any node is end_set has side effects. typo ^ is -> in Can you use set() method instead visited <<= start_mem->_idx? It is the same but more easy to understand. General note. Instead of checking memory between all possible combinations of append calls can you check only between final call toString and first call to StringBuffer? It should cover all. I think in product VM you can bailout immideately when you see store and loadstore. Instead of next_edge + path you can use Node_Stack class specifically designed for such cases. See example in PhaseCFG::schedule_early(). I think you need to assert assert for nodes you skip - closing } should be } else { assert() } to make sure you did not miss some nodes which affect memory. thanks, Vladimir On 10/9/13 7:39 PM, Igor Veresov wrote: > I've update the code a bit. I decided to share the arrays I use for traversal between the calls to path_has_side_effects(). > > On Oct 9, 2013, at 3:11 PM, Igor Veresov wrote: > >> String concat optimization optimization collapses the pattern >> >> StringBuffer x = new StringBuffer(); >> x.append(y); >> x.append(z); >> x.toString(); >> >> into a single allocation of a string and forming the result directly. All possible deopts that may happen in the optimized code restart this pattern from the beginning (starting from the StringBuffer allocation). That means that the whole pattern must me side-effect free. Existing code verifies that the pattern is sound from the control flow point of view, but omits the memory flow verification. This leaves a possibility for a computation on an argument of append() to have side effects. The fix adds memory flow analysis to find the possibly offending stores. We iterate up the memory graph (doing DFS) finding all possible simple paths starting from an append call, until we see the next append call, or a StringBuffer constructor. Then we analyze the path to see if it contains side effects. The analysis is exponential, so we limit the number of iterations. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ >> >> Testing: eyeballing the graph, the failing tests, jprt >> >> igor > From niclas.adlertz at oracle.com Thu Oct 10 00:08:59 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 10 Oct 2013 09:08:59 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <52560301.2060700@oracle.com> References: <5255D3DF.4090104@oracle.com> <52560301.2060700@oracle.com> Message-ID: <5256528B.5080709@oracle.com> Hi Vladimir, thank you. > Can you use 0xFFFFF format? Sure, I can switch to hexadecimal format in the code. The new value already is 0xFFFFF (but in decimal representation). > It will *8 but it should be fine since we need a big number. Won't it be * 16? I meant it will be * 16, not doubled. Sorry for the confusion. > I am little worry that it (mask_size()) is used somewhere in a code which expects 16bit value only. Could you look? I will look for uses of mask_size() to see if I can find uses where it needs 16bit. I will send out an updated webrev soon. Thanks. Kind Regards, Niclas Adlertz On 2013-10-10 03:29, Vladimir Kozlov wrote: > Can you use 0xFFFFF format? It will *8 but it should be fine since we need a big number. > I am little worry that it (mask_size()) is used somewhere in a code which expects 16bit value only. Could you look? > > Note for reviewers: > > lo_degree() { return degree() <= degrees_of_freedom(); } > degrees_of_freedom() { return mask_size() - _num_regs; } > degree() { return _eff_degree; } > uint _eff_degree; // Effective degree: Sum of neighbors _num_regs > > Thanks, > Vladimir > > On 10/9/13 3:08 PM, Niclas Adlertz wrote: >> Hi all, >> >> When compiling very big methods, in this particular case a method of >> 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still >> have lo_degree() == false. This because the _mask_size of 'l' can be at >> most 65535, at the same time 'l' is interfering with so many other live >> ranges that the value of _eff_degree becomes bigger than 65535. >> >> To solve this I've doubled that max value of _mask_size. >> Appreciate feedback on this. Should we increase it by more? Or find >> another solution for this? Or file a future enhancement bug to solve >> this in a cleaner way later on? >> >> (I've ran CTW + JPRT tests) >> >> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8011415 >> >> Kind Regards, >> Niclas Adlertz From vladimir.kozlov at oracle.com Thu Oct 10 00:43:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 00:43:34 -0700 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: References: <525456AF.7050602@oracle.com> Message-ID: <52565AA6.1010000@oracle.com> Tobias, if (UseCodeCacheFlushing) { + // Because we now check for each CodeBlobType if the corresponding heap in the + // code cache is full and delay compilation if so, it does not make sense anymore + // to disable compilation for all CodeBlobTypes at this point. + /* And you totally removed code in sweeper which enables compilation again. This is bad. PSR runs FA in VM environment only with few threads (2) and with this C2 Compiler threads will continue consume resources even when there are no space to store produced code. Output will be stormed by "CodeHeap for %s is full." messages. It doesn't even do decay invocation counters because next code is not executed: if (!should_compile_new_jobs()) { CompilationPolicy::policy()->delay_compilation(method()); return NULL; } Next code is also not executed. As result you continue do only partial sweeps when codecache (some heaps) is full: 266 if (!CompileBroker::should_compile_new_jobs()) { 267 // If we have turned off compilations we might as well do full sweeps 268 // in order to reach the clean state faster. Otherwise the sleeping compiler 269 // threads will slow down sweeping. 270 _invocations = 1; 271 } See other comments below. On 10/9/13 6:38 AM, Tobias Hartmann wrote: > Christian, Vladimir thank you for your reviews! > > Please find the new webrev at: http://cr.openjdk.java.net/~anoll/8015774/webrev.01/ > > See comments for both reviews inline: > > > 2013/10/8 Vladimir Kozlov > > > ProfiledCodeHeapSize value is missleading because part of it will be cut for non_method section: > > profile_size = ProfiledCodeHeapSize - non_method_size; > > And you hided default non_method_size (8Mb) inside the code: > > + size_t non_method_size = ReservedCodeSpace::allocation___align_size_up(MIN2(__ReservedCodeCacheSize, 8*M)); > > It is not good. If in future we add more stubs, for example, 8Mb could be not enough and it will be hard to find > this place. May be > > I agree, this part is still a little bit unclear. This is partly due to the fact that I'm still not sure how to set the > size of the non method heap. On my machine around 3.5Mb are sufficient for all benchmarks (debug/product). The jprt > tests seem to need more, that's why it is temporarily set to 8Mb. I have to evaluate that in more detail. Probably we > can set it depending on build/runtime settings and operating system. [Non]ProfiledCodeHeapSize are already platform specific flags. You don't need to do anything spacial. > > One option would be to create a new heap for all blobs needed by the VM to startup. This heap size can be set to > CodeCacheMinimumUseSpace. All non method blobs created by the running java application are then put into the non method > heap. CodeCacheMinimumUseSpace is already used to run only Interpreter. You can't change its meaning. You need to make sure your new code allow to run with such size. > > NonProfiledCodeHeapSize + ProfiledCodeHeapSize == ReservedCodeCacheSize + 8Mb > > So the size could be adjusted by setting 2 flags. > > Do you mean that the 8Mb for the non method heap should be subtracted half from the NonProfiledCodeHeapSize and half > from ProfiledCodeHeapSize? I mean: size_t non_method_size = ReservedCodeCacheSize - (ProfiledCodeHeapSize + NonProfiledCodeHeapSize); > > Why you need all heaps for Client VM (only C1 is available)? > > +bool CodeCache::heap_available(__CodeBlobType bt) { > + if (TieredCompilation || bt == btNonMethod) { > + // Use all heaps for TieredCompilation > + return true; > + } else { > +#ifdef COMPILER2 > + // We only need the heap for C2 > + return (bt == btMethodNoProfile); > +#else > + // We need both heaps > + return true; > +#endif > + } > } > > If we have a client build with only the C1 compiler available we still need the non profiled code heap, because we still > have the compilation levels CompLevel_none (native methods) and CompLevel_simple (C1 compiled without profiling) that > belong in this heap. My question was: why you need Profiled heap for C1 and Zero? Because this is what you get if COMPILER2 is not defined (Client or Zero VM). > > report_codemem_full(). When I discussed this feature with Igor, he told me that if you failed allocate in one heap > you can allocate in an other heap. Or you can move boundary. The longer you run "stable" application the less > ProfiledCodeHeap will be used (could be changed later when we add code to fall back to profiled code during nmethod > deoptimization). It would be nice to redirect its space for NonProfiledCodeHeap. For this purpose layout of heaps > should be reversed. > It would be strange to see free space in whole codecache but not able to allocate. > > > I'm not sure if I understood your point correctly. At the moment we delay compilation for the corresponding compilation > level if a heap is full. In practice (at least for the benchmarks I run) the second heap then fills up really fast. Your > suggestion to allocate CodeBlobs in another heap somehow "breaks" the design, because the client of the CodeCache could > then encounter non profiled, e.g. C2 compiled, methods while iterating over the profiled heap. This is not really a > problem at the moment, since no code relies on the fact that the non profiled heap _only_ contains C2 methods (as long > as it contains only _methods_). > However, I think that the second suggestion to move the boundary between the heaps is better. One could then increase > the non profiled heap and decrease the profiled heap size if the first is full. Over time the non profiled heap would > probably grow, whereas the profiled heap would shrink. > > Because I suspect this to be another big change, I would however suggest to implement this behavior with a second patch > and first finish the current changes. Agree that it is for an other changes. But you need to design current layout to allow to do that (move boundary) in a future. > > Next message is incorrect now since you need heap's specific flag: > > + warning("Try increasing the code cache size using -XX:ReservedCodeCacheSize="); > > > It is not incorrect as increasing the ReservedCodeCacheSize also increases the non profiled and the profiled heap sizes > (if no explicit value is set by the user). One option would be to print "Try increasing the code cache size using > -XX:ReservedCodeCacheSize= or -XX:NonProfiledCodeHeapSize" (or "-XX:ProfiledCodeHeapSize", depending on the heap that is > full). Whole print code is this: + warning("CodeHeap for %s is full. Compilation for these methods has been delayed.", CodeCache::get_heap_name(code_blob_type)); + warning("Try increasing the code cache size using -XX:ReservedCodeCacheSize="); You print specific code code heap name in first message (I agree with Christian that name are not good). You need to additionally print corresponding flag in next message because increasing ReservedCodeCacheSize will not help to NonProfiled heap if you don't increase NonProfiledCodeHeapSize. About changes in sweeper.cpp. I think you accidentally removed collection of freed_memory in sweep_code_cache(). And you can simplify the code (no need for external loop while (_current_type <=) ) if you move "while (_current_method == NULL ..." inside inner loop after "_current_nmethod = next". Vladimir > > thanks, > Vladimir > > 2013/10/4 Christian Thalinger > > > Some general comments: > > Don't use T1, T2, ? to name the tiers because SPARC processors are named like this. It's confusing. Use tier 1, > tier 2, ? instead. The compilation policies actually talk about tier levels... > > > I changed the names of the code heaps and comments accordingly. > > I was hoping that we can have a more loose definition of the code heaps. So we can easily add more. What this > patch does is a good start but all the hardcoded values and fields need to go at a later point in time, in my opinion. > > > To improve the adding of new heaps I completely removed the direct dependencies on code heaps from the serviceability > agent, dtrace and the pstack library, especially the fields _heap_non_method, _heap_non_profiled and _heap_profiled > fields in the code cache. The GrowableArray* is now the only field used to reference the code heaps. This > allows adding new heaps to the cache without the need to adapt references. An exception is the dtrace ustack helper > script (jhelper.d). Because the D language does not allow loops, one has to define a probe for each code heap. For now, > the script supports up to 5 code heaps, but more can be added by simply adding new probes to the script (comment in line > 183 in jhelper.d describes this). > > To summarize, if I want to add a new code heap to the cache, all I have to do is to > - define a new CodeBlobType (and add it to IsMethodPredicate if it is a method type) > - create the heap in CodeCache::initialize_heaps() and define default sizes > [- define heap availability in CodeCache::heap_available] > [- define the compilation level -> code blob type translation in CodeCache::get_code_blob_type] > > The last two steps are optional. CodeBlobs created with the new CodeBlobType are then allocated in the corresponding heap. > > I'm not completely sure what you mean with "hardcoded" values. Do you mean the default values for > NonProfiledCodeHeapSize and ProfiledCodeHeapSize? Of course we could compute them implicitly as 1/3 and 2/3 of the > ReservedCodeCacheSize (as it is now done if the user does not provide a value), without defining them as VM parameter, > but otherwise we have to define default values for them. > > src/share/vm/code/codeBlob.hpp: > > +// CodeBlob Types > +// Used in the CodeCache to assign CodeBlobs to different CodeHeaps > +enum CodeBlobType { > + btMethodNoProfile = 0, // T1 and T4 methods (including native methods) > + btMethodProfile = 1, // T2 and T3 methods with profile information > + btNonMethod = 2 // Non-methods like Buffers, Adapters and Runtime Stubs > +}; > > The bt prefix is already overloaded (e.g. BasicType). Generally speaking, I never liked the fact that enums don't > have their name as scope. Maybe we can agree on doing something like this: > > struct CodeBlobType { > enum Enum { > NonMethod = 2 > }; > }; > > void foo() { > int a = CodeBlobType::NonMethod; > int b = (CodeBlobType::Enum) 1; > } > > Or we move to C++11 :-) > > http://www.stroustrup.com/C++11FAQ.html#enum > > > Yes, it is probably more clear to include the scope. I followed your suggestion and changed it to a struct with an > anonymous enum. > > src/share/vm/code/codeCache.cpp: > > +#define FOR_ALL_HEAPS(index) for (int index = 0; index < _heaps->length(); ++index) > > I'm one of the people who started to hate macros (for various reasons). Although I see the point in defining these > I'd rather go without them. Is there a way we can use STL vectors with our allocators? Or we could write our own > iterator class which iterates either over GrowableArrays in general or the code heaps in particular. > > > I perfectly agree with you that macros should be used only if necessary and to improve readability in special cases. I > checked the option of using STL vectors but since the STL is not used in the code yet and I'm not sure if they can be > used with the hotspot allocators, I think it is better to work with own iterator classes. I therefore defined the custom > iterator classes GrowableArrayIterator and GrowableArrayFilterIterator. They implement the STL input iterator interface > without actually inheriting from it (since #include seems not to work with solaris). The filter iterator is > used to iterate only over those code heaps satisfying a given predicate, for example those heaps containing nmethods. > This makes the code a lot more readable and reduces the number of macros. I think the remaining four macros, namely > FOR_ALL_HEAPS and FOR_ALL_METHOD_HEAPS to iterate over the heaps and FOR_ALL_BLOBS and FOR_ALL_ALIVE_BLOBS to iterate > over the blobs are justified, because they are simple (only declaring the iterators) and make the code more readable. > > src/share/vm/memory/heap.hpp: > > + const char* getName() const { return _name; } > > This should either be get_name() or name(). > > I renamed it to name(). > > Thanks! > > Best regards > Tobias > > > On 10/2/13 7:06 AM, Tobias Hartmann wrote: > > Hi, > > please review the following change. > > bug: https://bugs.openjdk.java.net/__browse/JDK-8015774 > webrev: http://cr.openjdk.java.net/~__anoll/8015774/webrev.00/ > > > This change implements support for multiple code heaps in the code > cache. The interface of the code cache was changed accordingly and > references from other components of the VM were adapted. This includes > the indirect references from: > - the Serviceability Agent: vmStructs and the Java code cache interface > (sun.jvm.hotspot.code.__CodeCache) > - the dtrace ustack helper script (jhelper.d) > - the pstack support library libjvm_db.c > > Currently the code cache contains the following three code heaps each of > which contains CodeBlobs of a specific type: > - Non-Profiled methods: nmethods that are not profiled, i.e., those > compiled at tier 1 or 4 and native methods > - Profiled methods: nmethods that are profiled, i.e., those compiled at > tier 2 or 3 > - Non-methods: Non-methods like Buffers, Adapters and Runtime Stubs > > By default, 2/3 of the ReservedCodeCacheSize is used for the > non-profiled heap and 1/3 is used for the profiled heap. Experiments > with a small code cache size have shown that this configuration performs > best (see [1]). Sizes can be configured using the > NonProfiledCodeHeapSize and ProfiledCodeHeapSize parameters. By now the > non-method heap has a fixed size of 8mb. More tests have to be performed > to determine reasonable default values for different build and runtime > configurations. It would be also possible to add an additional heap for > the CodeBlobs needed during VM startup (adapters, stubs, interpreter, > ...) and use the non-method heap for non-method blobs allocated during > runtime. > > The main benefit of this allocation is that functions operating on > nmethods can now be optimized to only iterate over CodeBlobs on the > nmethod heaps, avoiding a full scan of the code cache including the > non-methods. Performance evaluation shows that this results in a great > reduction of the sweeping time. Further it is now possible to extend the > sweeper to selectively sweep nmethods of different compilation levels. > Because it is more expensive to recompile a highly optimized method, it > makes sense to first sweep those compiled at a lower level. Possible > future optimizations may also include multithreaded sweeping and > separation of nmethod code and metadata. > > The code was tested using Nashorn + Octane, DaCapo, SPECJvm2008 and jprt. > > Benchmark results: > - [2] shows the score of the old and new version running Nashorn with > the Octane benchmark at different code cache sizes (10 runs each, sizes > < 32mb crash with the old version). An performance improvement of around > 15% is reached. > - [3] shows the sweep time of the NMethodSweeper during runs of the > Octane benchmark with different code cache sizes (10 runs each). The > time is greatly reduced with the new version. > - [4] shows the time ratio (TOld / TNew - 1) of the DaCapo benchmarks > with a code cache size of 64mb (30 runs with 20 warmups each). With the > time differences being smaller than the confidence intervals it is not > possible determine a difference between the two versions. > - Multiple runs of the SPECJvm2008 benchmark with different code cache > sizes did not show a difference between the two versions. This is > probably due to the fact that not much code is compiled at runtime > compared to Nashorn with the Octane benchmark. > > The error bars at each data point show the 95% confidence interval. > > [1] https://bugs.openjdk.java.net/__secure/attachment/16372/__OctaneRatio.png > > [2] > https://bugs.openjdk.java.net/__secure/attachment/16374/__OctaneCCSizes_new.png > > [3] > https://bugs.openjdk.java.net/__secure/attachment/16373/__OctaneSweepTime_new.png > > [4] > https://bugs.openjdk.java.net/__secure/attachment/16371/__DaCapoCCSizes_64.png > > > Thanks and best regards, > > Tobias > > From niclas.adlertz at oracle.com Thu Oct 10 05:32:35 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 10 Oct 2013 14:32:35 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5256528B.5080709@oracle.com> References: <5255D3DF.4090104@oracle.com> <52560301.2060700@oracle.com> <5256528B.5080709@oracle.com> Message-ID: <52569E63.20601@oracle.com> I couldn't find any place where it expects a 16bit value only. Here's an updated webrev:http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev01/ Kind Regards, Niclas Adlertz On 2013-10-10 09:08, Niclas Adlertz wrote: > Hi Vladimir, thank you. > >> Can you use 0xFFFFF format? > Sure, I can switch to hexadecimal format in the code. The new value already is 0xFFFFF (but in decimal representation). > >> It will *8 but it should be fine since we need a big number. > Won't it be * 16? I meant it will be * 16, not doubled. Sorry for the confusion. > >> I am little worry that it (mask_size()) is used somewhere in a code which expects 16bit value only. Could you look? > I will look for uses of mask_size() to see if I can find uses where it needs 16bit. > > I will send out an updated webrev soon. > > Thanks. > > Kind Regards, > Niclas Adlertz > > On 2013-10-10 03:29, Vladimir Kozlov wrote: >> Can you use 0xFFFFF format? It will *8 but it should be fine since we need a big number. >> I am little worry that it (mask_size()) is used somewhere in a code which expects 16bit value only. Could you look? >> >> Note for reviewers: >> >> lo_degree() { return degree() <= degrees_of_freedom(); } >> degrees_of_freedom() { return mask_size() - _num_regs; } >> degree() { return _eff_degree; } >> uint _eff_degree; // Effective degree: Sum of neighbors _num_regs >> >> Thanks, >> Vladimir >> >> On 10/9/13 3:08 PM, Niclas Adlertz wrote: >>> Hi all, >>> >>> When compiling very big methods, in this particular case a method of >>> 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still >>> have lo_degree() == false. This because the _mask_size of 'l' can be at >>> most 65535, at the same time 'l' is interfering with so many other live >>> ranges that the value of _eff_degree becomes bigger than 65535. >>> >>> To solve this I've doubled that max value of _mask_size. >>> Appreciate feedback on this. Should we increase it by more? Or find >>> another solution for this? Or file a future enhancement bug to solve >>> this in a cleaner way later on? >>> >>> (I've ran CTW + JPRT tests) >>> >>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8011415 >>> >>> Kind Regards, >>> Niclas Adlertz > From roland.westrelin at oracle.com Thu Oct 10 05:41:50 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 Oct 2013 14:41:50 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5255D3DF.4090104@oracle.com> References: <5255D3DF.4090104@oracle.com> Message-ID: <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> > When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes bigger than 65535. Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? Roland. From roland.westrelin at oracle.com Thu Oct 10 06:39:36 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 Oct 2013 15:39:36 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <5255EC03.5090307@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> <5255A412.1080901@oracle.com> <2635463E-4729-44A0-9AC3-7755E04CF726@oracle.com> <5255EC03.5090307@oracle.com> Message-ID: <2BB25F0C-D73D-4EAB-9957-DBF7D394448C@oracle.com> Here is a new webrev: http://cr.openjdk.java.net/~roland/8026054/webrev.02/ Roland. On Oct 10, 2013, at 1:51 AM, Vladimir Kozlov wrote: > Suggested fix for profile_return_type() seems reasonable. Add comment why we do that. > > Thanks, > Vladimir > > On 10/9/13 2:37 PM, Roland Westrelin wrote: >> Thanks Vladimir for taking another look. See inlined. >> >> On Oct 9, 2013, at 8:44 PM, Vladimir Kozlov wrote: >> >>> On 10/9/13 9:18 AM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for reviewing this. >>>> >>>>> Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. >>>>> >>>>> Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. >>>>> >>>>> So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: >>>>> >>>>> class VirtualCallTypeData : public VirtualCallData { >>>>> private: >>>>> ! TypeStackSlotEntries _args; >>>>> ! ReturnTypeEntry _ret; >>>>> >>>>> Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). >>>>> >>>>> And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. >>>> >>>> ArgTypeEntries seems to imply it's only used for arguments. In the next change, it's used for parameters. That's why I named it TypeStackSlotEntries. >>> >>> I see, then may be CallTypeEntries. Again, we are not profiling stack slots. >> >> That would sound quite confusing if I indeed keep TypeEntriesAtCall. We are not profiling stack slots but we are keeping stack slots together with the profiling. The first profiling change is in the jprt queue so if the name is changed that will happen with this second change. >> >>> >>>> >>>> What about this: >>>> http://cr.openjdk.java.net/~roland/8026054/webrev.01/ >>>> ? >>> >>> It is better. About header_cell_count(), previous version was different. As I understand you always need cell_count cell to separate case when you have only 1 argument vs no profilable arguments but have ret type. Right? So my suggestion to have always ret_type cell will not help. >> >> Yes it's right. The previous version would not include a cell count if return value profiling was off and the upper bound on the number of arguments was 1. Then CallTypeData/VirtualCallTypeData would only exist for calls where we would have one and only one argument to profile. You're right that it's confusing and overkill to optimize for this rare case. >> >>> >>> Another question. You execute arguments profiling in assembler only if tag is CallTypeData or VirtualCallTypeData. But you don't do such check for return_type profiling. Why? >> >> Thanks for spotting that. It's a bug. I used to only have the option to turn profiling for return values on and off. If it's on and a object is returned, we profile. Otherwise we don't. But with the current change, we can decide to profile only for JSR292 and in this case, it's not sufficient to find a returned value that is an object to know whether to profile or not. The problem is that the profiling code at the call moves the mdp right after the cells to do the profiling at the invoke (we may return to the interpreter after a deopt so it was I think easier to move the mdp past the current VirtualCallTypeData/CallTypeData rather than modify the deopt code to restore the mdp at the location where the return value must be done). I think the easiest way to fix this is to add this code: >> >> void InterpreterMacroAssembler::profile_return_type(Register mdp, Register ret, Register tmp) { >> + assert_different_registers(mdp, ret, tmp, rsi); >> if (ProfileInterpreter && MethodData::profile_return()) { >> Label profile_continue, done; >> >> test_method_data_pointer(mdp, profile_continue); >> >> + if (MethodData::profile_return_jsr292_only()) { >> + Label do_profile; >> + cmpb(Address(rsi, 0), Bytecodes::_invokedynamic); >> + jcc(Assembler::equal, do_profile); >> + cmpb(Address(rsi, 0), Bytecodes::_invokehandle); >> + jcc(Assembler::equal, do_profile); >> + get_method(tmp); >> + cmpb(Address(tmp, Method::intrinsic_id_offset_in_bytes()), vmIntrinsics::_compiledLambdaForm); >> + jcc(Assembler::notEqual, profile_continue); >> + >> + bind(do_profile); >> + } >> + >> Address mdo_ret_addr(mdp, -in_bytes(ReturnTypeEntry::size())); >> mov(tmp, ret); >> profile_obj_type(tmp, mdo_ret_addr); >> >> >> >>> >>> About assembler. Why you need subl(tmp, 1) (there is no comment)? And why it is not done during stack_slot cell initialization? >> >> If you have a method with a single argument, it is at slot 0. Number of arguments is 1. 1 - 0 = 1 but the actual offset compared to sp is 1 - 0 - 1 = 0. >> That's where the 1 is coming from. >> >>> >>> About C1 code for ret profiling. I see only new code in c1_LIRGenerator.cpp which calls profile_arg_type() and no new assembler. Is it enough? >> >> It is. The code in c1_LIRAssembler_x86.cpp handles profiling of one object in all cases (arguments, return, parameters). LIRGenerator::profile_arg_type() generates a LIR instruction with this: >> >> __ profile_type(new LIR_Address(mdp, md_offset, T_METADATA), >> value.result(), exact_klass, profiled_k, new_pointer_register(), not_null, exact_signature_k != NULL); >> >> that is later emitted with the code in c1_LIRAssembler_x86.cpp >> >> I'll send a new webrev tomorrow. >> >> Roland. >> >>> >>> thanks, >>> Vladimir >>> >>>> >>>> I kept TypeEntriesAtCall only for the static methods but otherwise refactored as you suggested, I think. >>>> This also includes Chris' feedback. >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/8/13 9:22 AM, Roland Westrelin wrote: >>>>>> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >>>>>> >>>>>> Follow up to 8023657: New type profiling points: arguments to call >>>>>> >>>>>> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >>>>>> >>>>>> The output of PrintMethodData is: >>>>>> >>>>>> 17 invokevirtual 3 >>>>>> 16 bci: 17 VirtualCallData count(0) entries(1) >>>>>> 'TestProfiling'(4744 1.00) >>>>>> argument types 0: stack(1) 'TestProfiling$C' >>>>>> 1: stack(2) 'TestProfiling$B' >>>>>> return type 'TestProfiling$C' >>>>>> >>>>>> Roland. >>>>>> >>>> >> From niclas.adlertz at oracle.com Thu Oct 10 07:07:36 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 10 Oct 2013 16:07:36 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> Message-ID: <5256B4A8.4020302@oracle.com> Hi Roland, > Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? There's nothing wrong about _eff_degree being bigger than LRG_All_STACK_SIZE as long as we don't have a mask supporting stack locations, but you are right that we could add asserts when setting _eff_degree or adding to _eff_degree when the mask supports stack positions. > Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? That might be a good idea, I just followed the old standard. Thanks. webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ Kind Regards, Niclas Adlertz On 2013-10-10 14:41, Roland Westrelin wrote: >> When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes bigger than 65535. > > Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? > Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? > > Roland. > From albert.noll at oracle.com Thu Oct 10 08:34:42 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 10 Oct 2013 17:34:42 +0200 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5255D625.1090609@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> <5255D625.1090609@oracle.com> Message-ID: <5256C912.8010709@oracle.com> Vladimir, Chris, John, many thanks for your feedback. I'll run more tests to show that removing OSR methods in the sweeper is stable (or not). So far, I have not run into problems. @Chris, maybe you ran into 8024008 when you ran nashorn with a small code cache size. There is one thing I do not understand in the current implementation. What is the reason that OSR nmethods are maintained in InstanceKlass and not in Method? I do not see a reason but maybe I am missing something. Another thing I do not understand: When we remove an OSR method from the list (in InstanceKlass), we search for the max_comp level of all OSR nmethods of that class and then set this max_level as the max_level of the Method. Why would we set max_comp_level of Method X to max_comp_level of Method Y? I've an updated webrev, which moves the maintaining of the list of OSR methods from InstanceKlass to Method. This seems more logical to me. Moving the code to Method, also fixes the problem (if it is a problem) mentioned in the previous paragraph. Here is the webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.01/ Tests are still running but so far everything looks good. Thanks in advance for your help. Best, Albert On 10.10.2013 00:18, Vladimir Kozlov wrote: > On 10/9/13 10:21 AM, Vladimir Kozlov wrote: >> Albert, >> >> Changes are fine but you need more testing. >> >> Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests >> with -Xcomp and without it). >> >> Also the bug report has link to test (jittest). Can you build and run it >> too to see if it solves the problem with small codecache? It fills >> codecache with osr nmethods. >> >> It is very delicate matter. There was a reason we did not remove OSR >> nmethod until corresponding klass is unloaded (yes, deoptimization can >> make it non-entrant). Unfortunately I don't remember it. May be John >> know. Non of inline caches are pointing to OSR nmethods since it is >> called only from Interpreter. There is transition phase at the start of >> OSR nmethod when it calls runtime to convert interpreter frame to >> compiled frame. And method has separate field for osr nmethods. > > I think I dig out the answer. > > First, the last statement in previous mail is wrong. The method object > does not have reference to osr nmethods. Each java method can have > several alive OSR nmethods for different bcis. Instead method's holder > class has list of all OSR nmethods associated with all methods of this > class. Each time we do osr lookup we go through this list. > Since method does not have reference to OSR the original flushing > (speculative disconnection) could not be implemented for OSR nmethods. > > Second. Originally osr nmethod were not cleaned up from codecache. > Here is the comment and the code in > nmethod::make_not_entrant_or_zombie() from long time ago: > > // Code for an on-stack-replacement nmethod is removed when a class > gets unloaded. > // They never become zombie/non-entrant, so the nmethod sweeper will > never remove > // them. Instead the entry_bci is set to InvalidOSREntryBci, so the > osr nmethod > // will never be used anymore. That the nmethods only gets removed > when class unloading > // happens, make life much simpler, since the nmethods are not just > going to disappear > // out of the blue. > if (is_osr_only_method()) { > if (osr_entry_bci() != InvalidOSREntryBci) { > // only log this once > log_state_change(state); > } > invalidate_osr_method(); > return; > } > > This code was changed by Tom for 5057818 4 years ago to allow cleanup > unused OSR nmethods from codecache: > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/032260830071 > > Third, I think those changes are not complete. > nmethod::invalidate_osr_method() should check for _entry_bci == > InvalidOSREntryBci to avoid lookup through osr list again after > nmethod change from non_entrant to zombie (invalidate_osr_method() is > called each time make_not_entrant_or_zombie() is called). May be other > places. Note, when we process osr nmethod::_code should not be touched > since it is pointing to normal compiled nmethod which could still be > alive. > > Thanks, > Vladimir > >> >> Thanks, >> Vladimir >> >> On 10/8/13 10:18 PM, Albert Noll wrote: >>> Hi, >>> >>> could I have a review for this small patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8023191 >>> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ >>> >>> >>> Problem: OSR methods are not removed from code cache to free space. >>> Solution: Remove OSR methods from code cache. OSR methods c an be made >>> not-entrant and are then removed from the code cache >>> likenon-OSR >>> methods. Other parts in the code (e.g., >>> deoptimization.cpp:1547) already make >>> OSR methods not-entrant. >>> >>> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there >>> is an impact on performance. >>> >>> Many thanks in advance, >>> Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131010/aec6770a/attachment-0001.html From tobi.hartmann at gmail.com Thu Oct 10 08:36:18 2013 From: tobi.hartmann at gmail.com (Tobias Hartmann) Date: Thu, 10 Oct 2013 17:36:18 +0200 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <52565AA6.1010000@oracle.com> References: <525456AF.7050602@oracle.com> <52565AA6.1010000@oracle.com> Message-ID: Vladimir, thanks again for the quick review! Please find the new webrev at: http://cr.openjdk.java.net/~anoll/8015774/webrev.02/ See comments inline: 2013/10/10 Vladimir Kozlov > > > And you totally removed code in sweeper which enables compilation again. > > This is bad. PSR runs FA in VM environment only with few threads (2) and > with this C2 Compiler threads will continue consume resources even when > there are no space to store produced code. Output will be stormed by > "CodeHeap for %s is full." messages. > > It doesn't even do decay invocation counters because next code is not > executed: > if (!should_compile_new_jobs()) { > CompilationPolicy::policy()->**delay_compilation(method()); > return NULL; > } > > Next code is also not executed. As result you continue do only partial > sweeps when codecache (some heaps) is full: > > 266 if (!CompileBroker::should_**compile_new_jobs()) { > 267 // If we have turned off compilations we might as well do full > sweeps > 268 // in order to reach the clean state faster. Otherwise the > sleeping compiler > 269 // threads will slow down sweeping. > 270 _invocations = 1; > 271 } The "CodeHeap for %s is full warning" is printed only once for each CodeHeap, so in fact we print less warnings than the old implementation does. Because we check in the common transition functions of the threshold policies (SimpleThresholdPolicy::common and AdvancedThresholdPolicy::common) if the CodeHeap for the next compilation level is available and remain at the current level if it is full, the compiler threads do not produce code if a heap is full: if (CodeCache::is_full(CodeCache::get_code_blob_type(next_level))) { // The CodeHeap for next_level is full, stay at current level return cur_level; } They only consume resources to repeatedly check if the CodeHeap for the next compilation level is now available. Benchmarking showed that this does not negatively affect performance. You are right with the not executed code parts and the partial sweeps. Although this can be adapted easily I followed your suggestions and reverted the changes. As before, compilation is now disabled as long as a code heap is full and enabled after sweeping. I still think that it would be better to disable compilation for CodeHeaps individually (as this was done implicitly by my implementation), because we could still compile into the other heap. Maybe this can be introduced in a future patch. > I agree, this part is still a little bit unclear. This is partly due to >> the fact that I'm still not sure how to set the >> size of the non method heap. On my machine around 3.5Mb are sufficient >> for all benchmarks (debug/product). The jprt >> tests seem to need more, that's why it is temporarily set to 8Mb. I have >> to evaluate that in more detail. Probably we >> can set it depending on build/runtime settings and operating system. >> > > [Non]ProfiledCodeHeapSize are already platform specific flags. You don't > need to do anything spacial. Yes, I meant that I still have to figure out the specific values for each platform. > One option would be to create a new heap for all blobs needed by the VM to >> startup. This heap size can be set to >> CodeCacheMinimumUseSpace. All non method blobs created by the running >> java application are then put into the non method >> heap. >> > > CodeCacheMinimumUseSpace is already used to run only Interpreter. You > can't change its meaning. You need to make sure your new code allow to run > with such size. I mean: > > size_t non_method_size = ReservedCodeCacheSize - (ProfiledCodeHeapSize + > NonProfiledCodeHeapSize); > I implemented it as you suggested. By default NonProfiledCodeHeapSize is approximately ProfiledCodeHeapSize * 2. I will set the platform specific default values such that the non_method_size is big enough to run the interpreter (currently it is set to 4Mb). > My question was: why you need Profiled heap for C1 and Zero? Because this > is what you get if COMPILER2 is not defined (Client or Zero VM). You are perfectly right. The profiled heap is not needed if COMPILER2 is not defined. I changed it accordingly. > I'm not sure if I understood your point correctly. At the moment we delay >> compilation for the corresponding compilation >> level if a heap is full. In practice (at least for the benchmarks I run) >> the second heap then fills up really fast. Your >> suggestion to allocate CodeBlobs in another heap somehow "breaks" the >> design, because the client of the CodeCache could >> then encounter non profiled, e.g. C2 compiled, methods while iterating >> over the profiled heap. This is not really a >> problem at the moment, since no code relies on the fact that the non >> profiled heap _only_ contains C2 methods (as long >> as it contains only _methods_). >> However, I think that the second suggestion to move the boundary between >> the heaps is better. One could then increase >> the non profiled heap and decrease the profiled heap size if the first is >> full. Over time the non profiled heap would >> probably grow, whereas the profiled heap would shrink. >> >> Because I suspect this to be another big change, I would however suggest >> to implement this behavior with a second patch >> and first finish the current changes. >> > > Agree that it is for an other changes. But you need to design current > layout to allow to do that (move boundary) in a future. To move the boundary we have to adapt the VirtualSpace used by the CodeHeaps to support "expanding into" another VirtualSpace as it is already implemented in class PSVirtualSpace (::expand_into) used by parallel scavenge GC. Having this we can define two adjacent VirtualSpaces for the profiled and non-profiled heaps, one of which grows high to low, and move the boundary in case one is full. Similar functionality is implemented in class AdjoiningVirtualSpaces (also used by the parallel scavenge GC). The current design of the code cache shouldn't be affected much. I will look into this more thoroughly and implement the missing functionality in VirtualSpace and CodeHeap. > Whole print code is this: > > + warning("CodeHeap for %s is full. Compilation for these methods has > been delayed.", CodeCache::get_heap_name(code_**blob_type)); > > + warning("Try increasing the code cache size using > -XX:ReservedCodeCacheSize="); > > You print specific code code heap name in first message (I agree with > Christian that name are not good). You need to additionally print > corresponding flag in next message because increasing ReservedCodeCacheSize > will not help to NonProfiled heap if you don't increase > NonProfiledCodeHeapSize. > Done (names were already changed in the last webrev). > About changes in sweeper.cpp. > I think you accidentally removed collection of freed_memory in > sweep_code_cache(). > Right, I reverted that. > And you can simplify the code (no need for external loop while > (_current_type <=) ) if you move "while (_current_method == NULL ..." > inside inner loop after "_current_nmethod = next". > Done. Didn't notice that, thanks for the remark. Regards, Tobias > thanks, >> Vladimir >> >> 2013/10/4 Christian Thalinger > christian.thalinger@**oracle.com >> >> >> >> Some general comments: >> >> Don't use T1, T2, ? to name the tiers because SPARC processors are >> named like this. It's confusing. Use tier 1, >> tier 2, ? instead. The compilation policies actually talk about tier >> levels... >> >> >> I changed the names of the code heaps and comments accordingly. >> >> I was hoping that we can have a more loose definition of the code >> heaps. So we can easily add more. What this >> patch does is a good start but all the hardcoded values and fields >> need to go at a later point in time, in my opinion. >> >> >> To improve the adding of new heaps I completely removed the direct >> dependencies on code heaps from the serviceability >> agent, dtrace and the pstack library, especially the fields >> _heap_non_method, _heap_non_profiled and _heap_profiled >> fields in the code cache. The GrowableArray* is now the only >> field used to reference the code heaps. This >> allows adding new heaps to the cache without the need to adapt >> references. An exception is the dtrace ustack helper >> script (jhelper.d). Because the D language does not allow loops, one has >> to define a probe for each code heap. For now, >> the script supports up to 5 code heaps, but more can be added by simply >> adding new probes to the script (comment in line >> 183 in jhelper.d describes this). >> >> To summarize, if I want to add a new code heap to the cache, all I have >> to do is to >> - define a new CodeBlobType (and add it to IsMethodPredicate if it is a >> method type) >> - create the heap in CodeCache::initialize_heaps() and define default >> sizes >> [- define heap availability in CodeCache::heap_available] >> [- define the compilation level -> code blob type translation in >> CodeCache::get_code_blob_type] >> >> The last two steps are optional. CodeBlobs created with the new >> CodeBlobType are then allocated in the corresponding heap. >> >> I'm not completely sure what you mean with "hardcoded" values. Do you >> mean the default values for >> NonProfiledCodeHeapSize and ProfiledCodeHeapSize? Of course we could >> compute them implicitly as 1/3 and 2/3 of the >> ReservedCodeCacheSize (as it is now done if the user does not provide a >> value), without defining them as VM parameter, >> but otherwise we have to define default values for them. >> >> src/share/vm/code/codeBlob.**hpp: >> >> +// CodeBlob Types >> +// Used in the CodeCache to assign CodeBlobs to different CodeHeaps >> +enum CodeBlobType { >> + btMethodNoProfile = 0, // T1 and T4 methods (including native >> methods) >> + btMethodProfile = 1, // T2 and T3 methods with profile >> information >> + btNonMethod = 2 // Non-methods like Buffers, Adapters >> and Runtime Stubs >> +}; >> >> The bt prefix is already overloaded (e.g. BasicType). Generally >> speaking, I never liked the fact that enums don't >> have their name as scope. Maybe we can agree on doing something like >> this: >> >> struct CodeBlobType { >> enum Enum { >> NonMethod = 2 >> }; >> }; >> >> void foo() { >> int a = CodeBlobType::NonMethod; >> int b = (CodeBlobType::Enum) 1; >> } >> >> Or we move to C++11 :-) >> >> http://www.stroustrup.com/C++**11FAQ.html#enum >> >> >> Yes, it is probably more clear to include the scope. I followed your >> suggestion and changed it to a struct with an >> anonymous enum. >> >> src/share/vm/code/codeCache.**cpp: >> >> +#define FOR_ALL_HEAPS(index) for (int index = 0; index < >> _heaps->length(); ++index) >> >> I'm one of the people who started to hate macros (for various >> reasons). Although I see the point in defining these >> I'd rather go without them. Is there a way we can use STL vectors >> with our allocators? Or we could write our own >> iterator class which iterates either over GrowableArrays in general >> or the code heaps in particular. >> >> >> I perfectly agree with you that macros should be used only if necessary >> and to improve readability in special cases. I >> checked the option of using STL vectors but since the STL is not used in >> the code yet and I'm not sure if they can be >> used with the hotspot allocators, I think it is better to work with own >> iterator classes. I therefore defined the custom >> iterator classes GrowableArrayIterator and GrowableArrayFilterIterator. >> They implement the STL input iterator interface >> without actually inheriting from it (since #include seems not >> to work with solaris). The filter iterator is >> used to iterate only over those code heaps satisfying a given predicate, >> for example those heaps containing nmethods. >> This makes the code a lot more readable and reduces the number of macros. >> I think the remaining four macros, namely >> FOR_ALL_HEAPS and FOR_ALL_METHOD_HEAPS to iterate over the heaps and >> FOR_ALL_BLOBS and FOR_ALL_ALIVE_BLOBS to iterate >> over the blobs are justified, because they are simple (only declaring the >> iterators) and make the code more readable. >> >> src/share/vm/memory/heap.hpp: >> >> + const char* getName() const { return _name; } >> >> This should either be get_name() or name(). >> >> I renamed it to name(). >> >> Thanks! >> >> Best regards >> Tobias >> >> >> On 10/2/13 7:06 AM, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following change. >> >> bug: https://bugs.openjdk.java.net/**__browse/JDK-8015774< >> https://bugs.openjdk.java.**net/browse/JDK-8015774 >> > >> webrev: http://cr.openjdk.java.net/~__**anoll/8015774/webrev.00/ >> >> >> > >> >> This change implements support for multiple code heaps in the code >> cache. The interface of the code cache was changed accordingly and >> references from other components of the VM were adapted. This >> includes >> the indirect references from: >> - the Serviceability Agent: vmStructs and the Java code cache >> interface >> (sun.jvm.hotspot.code.__**CodeCache) >> >> - the dtrace ustack helper script (jhelper.d) >> - the pstack support library libjvm_db.c >> >> Currently the code cache contains the following three code heaps >> each of >> which contains CodeBlobs of a specific type: >> - Non-Profiled methods: nmethods that are not profiled, i.e., >> those >> compiled at tier 1 or 4 and native methods >> - Profiled methods: nmethods that are profiled, i.e., those >> compiled at >> tier 2 or 3 >> - Non-methods: Non-methods like Buffers, Adapters and Runtime >> Stubs >> >> By default, 2/3 of the ReservedCodeCacheSize is used for the >> non-profiled heap and 1/3 is used for the profiled heap. >> Experiments >> with a small code cache size have shown that this configuration >> performs >> best (see [1]). Sizes can be configured using the >> NonProfiledCodeHeapSize and ProfiledCodeHeapSize parameters. By >> now the >> non-method heap has a fixed size of 8mb. More tests have to be >> performed >> to determine reasonable default values for different build and >> runtime >> configurations. It would be also possible to add an additional >> heap for >> the CodeBlobs needed during VM startup (adapters, stubs, >> interpreter, >> ...) and use the non-method heap for non-method blobs allocated >> during >> runtime. >> >> The main benefit of this allocation is that functions operating on >> nmethods can now be optimized to only iterate over CodeBlobs on >> the >> nmethod heaps, avoiding a full scan of the code cache including >> the >> non-methods. Performance evaluation shows that this results in a >> great >> reduction of the sweeping time. Further it is now possible to >> extend the >> sweeper to selectively sweep nmethods of different compilation >> levels. >> Because it is more expensive to recompile a highly optimized >> method, it >> makes sense to first sweep those compiled at a lower level. >> Possible >> future optimizations may also include multithreaded sweeping and >> separation of nmethod code and metadata. >> >> The code was tested using Nashorn + Octane, DaCapo, SPECJvm2008 >> and jprt. >> >> Benchmark results: >> - [2] shows the score of the old and new version running Nashorn >> with >> the Octane benchmark at different code cache sizes (10 runs each, >> sizes >> < 32mb crash with the old version). An performance improvement of >> around >> 15% is reached. >> - [3] shows the sweep time of the NMethodSweeper during runs of >> the >> Octane benchmark with different code cache sizes (10 runs each). >> The >> time is greatly reduced with the new version. >> - [4] shows the time ratio (TOld / TNew - 1) of the DaCapo >> benchmarks >> with a code cache size of 64mb (30 runs with 20 warmups each). >> With the >> time differences being smaller than the confidence intervals it >> is not >> possible determine a difference between the two versions. >> - Multiple runs of the SPECJvm2008 benchmark with different code >> cache >> sizes did not show a difference between the two versions. This is >> probably due to the fact that not much code is compiled at runtime >> compared to Nashorn with the Octane benchmark. >> >> The error bars at each data point show the 95% confidence >> interval. >> >> [1] https://bugs.openjdk.java.net/**__secure/attachment/16372/__* >> *OctaneRatio.png >> > OctaneRatio.png >> > >> [2] >> https://bugs.openjdk.java.net/**__secure/attachment/16374/__** >> OctaneCCSizes_new.png >> > OctaneCCSizes_new.png >> > >> [3] >> https://bugs.openjdk.java.net/**__secure/attachment/16373/__** >> OctaneSweepTime_new.png >> > OctaneSweepTime_new.png >> > >> [4] >> https://bugs.openjdk.java.net/**__secure/attachment/16371/__** >> DaCapoCCSizes_64.png >> >> > DaCapoCCSizes_64.png >> > >> >> Thanks and best regards, >> >> Tobias >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131010/893cc90a/attachment-0001.html From tobi.hartmann at gmail.com Thu Oct 10 09:09:41 2013 From: tobi.hartmann at gmail.com (Tobias Hartmann) Date: Thu, 10 Oct 2013 18:09:41 +0200 Subject: RFR(S): 8025227: Add -XX: flag to print code cache sweeper statistics In-Reply-To: <5246B929.5010208@oracle.com> References: <5244A397.9000006@oracle.com> <5244B0B3.5020209@oracle.com> <5246B929.5010208@oracle.com> Message-ID: Hi, I just wanted to ask if my changes can be considered as reviewed now? Thanks! Regards, Tobias 2013/9/28 Albert Noll > Already done. > > Best, > Albert > > > On 28.09.2013 00:40, Christian Thalinger wrote: > > I've already pointed this out to Albert but before we can accept your > contributions you need to sign the OCA. See: > > http://openjdk.java.net/contribute/ > > On Sep 27, 2013, at 7:39 AM, Tobias Hartmann > wrote: > > Chris, Vladimir, thank you for your reviews. > I followed your suggestions and added other useful statistics. The output > now looks like this: > > Method flushing statistics: > Total sweep time: 152.649ms > Peak sweep time: 15.979ms > Peak sweep fraction time: 3.209ms > Total number of stack traversals: 25 > Total number of flushed methods: 1320 > Total size of flushed methods: 7188Kb > > I did not include the other values, because as Vladimir already said, > they are removed by 8020151. > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8025277/webrev.01/ > > Thanks again for your review. > > Regards, > Tobias > > > > > 2013/9/27 Vladimir Kozlov > >> I agree with Chris, we are collecting those counters anyway. I also like >> Chris's idea about collecting freed sizes. Note, some counters will be >> removed by 8020151 changes: >> >> http://cr.openjdk.java.net/~anoll/8020151/webrev.03/ >> >> Thanks, >> Vladimir >> >> >> On 9/26/13 2:13 PM, Chris Plummer wrote: >> >>> Hi Tobias, >>> >>> The one comment I would have is that the statistics you produce are all >>> timing related, but the option name implies you would get a bit more >>> than this. For example, maybe something like a count of the number of >>> methods flushed (and maybe total size). So I would suggest either rename >>> to PrintMethodFlushingTimingStatistics (and also rename the print >>> method), or add some other useful statistics to the output. Probably all >>> the counters located below the " Stat counters" comment are good >>> candidates. >>> >>> best regards, >>> >>> Chris >>> >>> On 9/25/13 12:20 AM, Tobias Hartmann wrote: >>> >>>> Hi, >>>> >>>> Please review the following small patch. >>>> >>>> bug:?https://bugs.openjdk.java.net/browse/JDK-8025277 >>>> webrev:?http://cr.openjdk.java.net/~anoll/8025277/webrev.00/ >>>> >>>> >>>> >>>> I added the diagnostic VM option?PrintMethodFlushingStatistics to >>>> print statistics about the NMethodSweeper (sweep times) on exit. This >>>> is useful to determine performance bottlenecks of applications that >>>> heavily compile code (e.g. nashorn). >>>> >>>> Thanks in advance! >>>> >>>> Best regards, >>>> Tobias >>>> >>>> >>>> By the way, I'm Tobias Hartmann, a student from Switzerland currently >>>> working on my Master Thesis "Code Cache Optimizations for Dynamically >>>> Compiled Languages" on supervision of Albert Noll. >>>> >>>> >>>> >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131010/bce58681/attachment.html From vladimir.kozlov at oracle.com Thu Oct 10 09:58:18 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 09:58:18 -0700 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <52569E63.20601@oracle.com> References: <5255D3DF.4090104@oracle.com> <52560301.2060700@oracle.com> <5256528B.5080709@oracle.com> <52569E63.20601@oracle.com> Message-ID: <5256DCAA.5070100@oracle.com> Niclas, Thank you for looking. The changes are good. Thanks, Vladimir On 10/10/13 5:32 AM, Niclas Adlertz wrote: > I couldn't find any place where it expects a 16bit value only. > > Here's an updated > webrev:http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev01/ > > Kind Regards, > Niclas Adlertz > > On 2013-10-10 09:08, Niclas Adlertz wrote: >> Hi Vladimir, thank you. >> >>> Can you use 0xFFFFF format? >> Sure, I can switch to hexadecimal format in the code. The new value >> already is 0xFFFFF (but in decimal representation). >> >>> It will *8 but it should be fine since we need a big number. >> Won't it be * 16? I meant it will be * 16, not doubled. Sorry for the >> confusion. >> >>> I am little worry that it (mask_size()) is used somewhere in a code >>> which expects 16bit value only. Could you look? >> I will look for uses of mask_size() to see if I can find uses where it >> needs 16bit. >> >> I will send out an updated webrev soon. >> >> Thanks. >> >> Kind Regards, >> Niclas Adlertz >> >> On 2013-10-10 03:29, Vladimir Kozlov wrote: >>> Can you use 0xFFFFF format? It will *8 but it should be fine since we >>> need a big number. >>> I am little worry that it (mask_size()) is used somewhere in a code >>> which expects 16bit value only. Could you look? >>> >>> Note for reviewers: >>> >>> lo_degree() { return degree() <= degrees_of_freedom(); } >>> degrees_of_freedom() { return mask_size() - _num_regs; } >>> degree() { return _eff_degree; } >>> uint _eff_degree; // Effective degree: Sum of neighbors _num_regs >>> >>> Thanks, >>> Vladimir >>> >>> On 10/9/13 3:08 PM, Niclas Adlertz wrote: >>>> Hi all, >>>> >>>> When compiling very big methods, in this particular case a method of >>>> 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still >>>> have lo_degree() == false. This because the _mask_size of 'l' can be at >>>> most 65535, at the same time 'l' is interfering with so many other live >>>> ranges that the value of _eff_degree becomes bigger than 65535. >>>> >>>> To solve this I've doubled that max value of _mask_size. >>>> Appreciate feedback on this. Should we increase it by more? Or find >>>> another solution for this? Or file a future enhancement bug to solve >>>> this in a cleaner way later on? >>>> >>>> (I've ran CTW + JPRT tests) >>>> >>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8011415 >>>> >>>> Kind Regards, >>>> Niclas Adlertz >> > From john.r.rose at oracle.com Thu Oct 10 09:47:54 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 10 Oct 2013 09:47:54 -0700 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5256C912.8010709@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> <5255D625.1090609@oracle.com> <5256C912.8010709@oracle.com> Message-ID: <9CE10F0C-7A50-42DE-AB3B-BF82FE11C280@oracle.com> On Oct 10, 2013, at 8:34 AM, Albert Noll wrote: > There is one thing I do not understand in the current implementation. What is the reason > that OSR nmethods are maintained in InstanceKlass and not in Method? > I do not see a reason but maybe I am missing something. The basic assumption in HotSpot before OSR is that each bytecode method has zero or one compiled versions. With OSR, we need multiple versions (for different entry points). Putting this in required an ad hoc data structure that had to be built on the side. See my earlier message for where I think the "sweet spot" is: A way to bind a specific method to zero or more versioned n-methods. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131010/77ac268c/attachment.html From vladimir.kozlov at oracle.com Thu Oct 10 10:06:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 10:06:32 -0700 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5256B4A8.4020302@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> Message-ID: <5256DE98.5090109@oracle.com> On 10/10/13 7:07 AM, Niclas Adlertz wrote: > Hi Roland, > >> Shouldn't we assert somewhere than _eff_degree doesn't become any >> bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? > There's nothing wrong about _eff_degree being bigger than > LRG_All_STACK_SIZE as long as we don't have a mask supporting stack > locations, but you are right that we could add asserts when setting > _eff_degree or adding to _eff_degree when the mask supports stack > positions. To have asserts is fine. > >> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? Downside is you have to add casts as Niclas did. Vladimir > That might be a good idea, I just followed the old standard. > > Thanks. > > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ > > Kind Regards, > Niclas Adlertz > > On 2013-10-10 14:41, Roland Westrelin wrote: >>> When compiling very big methods, in this particular case a method of >>> 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can >>> still have lo_degree() == false. This because the _mask_size of 'l' >>> can be at most 65535, at the same time 'l' is interfering with so >>> many other live ranges that the value of _eff_degree becomes bigger >>> than 65535. >> >> Shouldn't we assert somewhere than _eff_degree doesn't become any >> bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >> >> Roland. >> > From vladimir.kozlov at oracle.com Thu Oct 10 10:11:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 10:11:16 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <2BB25F0C-D73D-4EAB-9957-DBF7D394448C@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> <5255A412.1080901@oracle.com> <2635463E-4729-44A0-9AC3-7755E04CF726@oracle.com> <5255EC03.5090307@oracle.com> <2BB25F0C-D73D-4EAB-9957-DBF7D394448C@oracle.com> Message-ID: <5256DFB4.1060509@oracle.com> Looks good. Vladimir On 10/10/13 6:39 AM, Roland Westrelin wrote: > Here is a new webrev: > http://cr.openjdk.java.net/~roland/8026054/webrev.02/ > > Roland. > > On Oct 10, 2013, at 1:51 AM, Vladimir Kozlov wrote: > >> Suggested fix for profile_return_type() seems reasonable. Add comment why we do that. >> >> Thanks, >> Vladimir >> >> On 10/9/13 2:37 PM, Roland Westrelin wrote: >>> Thanks Vladimir for taking another look. See inlined. >>> >>> On Oct 9, 2013, at 8:44 PM, Vladimir Kozlov wrote: >>> >>>> On 10/9/13 9:18 AM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thanks for reviewing this. >>>>> >>>>>> Sorry, but I will not be able to debug this in 3 month :( TypeStackSlotEntries is already complex enough and you including return type cell into it (by using TypeEntriesAtCall) to avoid additional cell when no object return. >>>>>> >>>>>> Can we always have one separate cell for return value for CallTypeData and VirtualCallTypeData when arguments are profiling. I would prefer to have that cell always instead of complicated code which tries to calculate its presence. From what I understand when you profile only one argument TypeProfileArgsLimit=1 you will use additional cell for cells count even if no return will be recorded (if return type is not profiled cell count is not added in this case). It looks like the space usage will be the same as when you always generate cell for return type for this case (for 2 and more arguments you will get extra one but it is 3+1). I think it will simplify the code because you don't need to change TypeStackSlotEntries. >>>>>> >>>>>> So can you separate TypeStackSlotEntries and ReturnTypeEntry and don't use TypeEntriesAtCall?: >>>>>> >>>>>> class VirtualCallTypeData : public VirtualCallData { >>>>>> private: >>>>>> ! TypeStackSlotEntries _args; >>>>>> ! ReturnTypeEntry _ret; >>>>>> >>>>>> Yes, CallTypeData and VirtualCallTypeData will have more additional duplicated code. You can put some common code into TypeEntries (for example, compute_cell_count() is static). >>>>>> >>>>>> And TypeStackSlotEntries should be ArgTypeEntries because stack slot is just data used to record arguments types. >>>>> >>>>> ArgTypeEntries seems to imply it's only used for arguments. In the next change, it's used for parameters. That's why I named it TypeStackSlotEntries. >>>> >>>> I see, then may be CallTypeEntries. Again, we are not profiling stack slots. >>> >>> That would sound quite confusing if I indeed keep TypeEntriesAtCall. We are not profiling stack slots but we are keeping stack slots together with the profiling. The first profiling change is in the jprt queue so if the name is changed that will happen with this second change. >>> >>>> >>>>> >>>>> What about this: >>>>> http://cr.openjdk.java.net/~roland/8026054/webrev.01/ >>>>> ? >>>> >>>> It is better. About header_cell_count(), previous version was different. As I understand you always need cell_count cell to separate case when you have only 1 argument vs no profilable arguments but have ret type. Right? So my suggestion to have always ret_type cell will not help. >>> >>> Yes it's right. The previous version would not include a cell count if return value profiling was off and the upper bound on the number of arguments was 1. Then CallTypeData/VirtualCallTypeData would only exist for calls where we would have one and only one argument to profile. You're right that it's confusing and overkill to optimize for this rare case. >>> >>>> >>>> Another question. You execute arguments profiling in assembler only if tag is CallTypeData or VirtualCallTypeData. But you don't do such check for return_type profiling. Why? >>> >>> Thanks for spotting that. It's a bug. I used to only have the option to turn profiling for return values on and off. If it's on and a object is returned, we profile. Otherwise we don't. But with the current change, we can decide to profile only for JSR292 and in this case, it's not sufficient to find a returned value that is an object to know whether to profile or not. The problem is that the profiling code at the call moves the mdp right after the cells to do the profiling at the invoke (we may return to the interpreter after a deopt so it was I think easier to move the mdp past the current VirtualCallTypeData/CallTypeData rather than modify the deopt code to restore the mdp at the location where the return value must be done). I think the easiest way to fix this is to add this code: >>> >>> void InterpreterMacroAssembler::profile_return_type(Register mdp, Register ret, Register tmp) { >>> + assert_different_registers(mdp, ret, tmp, rsi); >>> if (ProfileInterpreter && MethodData::profile_return()) { >>> Label profile_continue, done; >>> >>> test_method_data_pointer(mdp, profile_continue); >>> >>> + if (MethodData::profile_return_jsr292_only()) { >>> + Label do_profile; >>> + cmpb(Address(rsi, 0), Bytecodes::_invokedynamic); >>> + jcc(Assembler::equal, do_profile); >>> + cmpb(Address(rsi, 0), Bytecodes::_invokehandle); >>> + jcc(Assembler::equal, do_profile); >>> + get_method(tmp); >>> + cmpb(Address(tmp, Method::intrinsic_id_offset_in_bytes()), vmIntrinsics::_compiledLambdaForm); >>> + jcc(Assembler::notEqual, profile_continue); >>> + >>> + bind(do_profile); >>> + } >>> + >>> Address mdo_ret_addr(mdp, -in_bytes(ReturnTypeEntry::size())); >>> mov(tmp, ret); >>> profile_obj_type(tmp, mdo_ret_addr); >>> >>> >>> >>>> >>>> About assembler. Why you need subl(tmp, 1) (there is no comment)? And why it is not done during stack_slot cell initialization? >>> >>> If you have a method with a single argument, it is at slot 0. Number of arguments is 1. 1 - 0 = 1 but the actual offset compared to sp is 1 - 0 - 1 = 0. >>> That's where the 1 is coming from. >>> >>>> >>>> About C1 code for ret profiling. I see only new code in c1_LIRGenerator.cpp which calls profile_arg_type() and no new assembler. Is it enough? >>> >>> It is. The code in c1_LIRAssembler_x86.cpp handles profiling of one object in all cases (arguments, return, parameters). LIRGenerator::profile_arg_type() generates a LIR instruction with this: >>> >>> __ profile_type(new LIR_Address(mdp, md_offset, T_METADATA), >>> value.result(), exact_klass, profiled_k, new_pointer_register(), not_null, exact_signature_k != NULL); >>> >>> that is later emitted with the code in c1_LIRAssembler_x86.cpp >>> >>> I'll send a new webrev tomorrow. >>> >>> Roland. >>> >>>> >>>> thanks, >>>> Vladimir >>>> >>>>> >>>>> I kept TypeEntriesAtCall only for the static methods but otherwise refactored as you suggested, I think. >>>>> This also includes Chris' feedback. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/8/13 9:22 AM, Roland Westrelin wrote: >>>>>>> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >>>>>>> >>>>>>> Follow up to 8023657: New type profiling points: arguments to call >>>>>>> >>>>>>> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >>>>>>> >>>>>>> The output of PrintMethodData is: >>>>>>> >>>>>>> 17 invokevirtual 3 >>>>>>> 16 bci: 17 VirtualCallData count(0) entries(1) >>>>>>> 'TestProfiling'(4744 1.00) >>>>>>> argument types 0: stack(1) 'TestProfiling$C' >>>>>>> 1: stack(2) 'TestProfiling$B' >>>>>>> return type 'TestProfiling$C' >>>>>>> >>>>>>> Roland. >>>>>>> >>>>> >>> > From roland.westrelin at oracle.com Thu Oct 10 10:35:13 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 Oct 2013 19:35:13 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <5256DFB4.1060509@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <525491D2.5070203@oracle.com> <5255A412.1080901@oracle.com> <2635463E-4729-44A0-9AC3-7755E04CF726@oracle.com> <5255EC03.5090307@oracle.com> <2BB25F0C-D73D-4EAB-9957-DBF7D394448C@oracle.com> <5256DFB4.1060509@oracle.com> Message-ID: > Looks good. Vladimir, Thanks for the review. Roland. From john.coomes at oracle.com Thu Oct 10 10:43:03 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:43:03 +0000 Subject: hg: hsx/hotspot-comp: 5 new changesets Message-ID: <20131010174304.687FB62F18@hg.openjdk.java.net> Changeset: feb4f2d97042 Author: ihse Date: 2013-10-03 11:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/feb4f2d97042 8008944: Correct typos Reviewed-by: tbell, erikj ! NewMakefile.gmk ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/makefiles/JavaCompilation.gmk Changeset: d23177734b28 Author: thurka Date: 2013-10-07 13:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/d23177734b28 8025920: webrev.ksh does not provide any details about changes in zip files Summary: Add support for diffs for zip files Reviewed-by: ksrini, chegar ! make/scripts/webrev.ksh Changeset: 9b102ab97693 Author: erikj Date: 2013-10-07 18:19 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/9b102ab97693 8005924: Make it possible to set both --with-user-release-suffix and --with-build-number Reviewed-by: ihse, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in Changeset: d086227bfc45 Author: katleman Date: 2013-10-08 13:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/d086227bfc45 Merge Changeset: 82a36c5c4eaf Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/82a36c5c4eaf Added tag jdk8-b111 for changeset d086227bfc45 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:43:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:43:29 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b111 for changeset 17ee0d3e97fd Message-ID: <20131010174340.0916562F1A@hg.openjdk.java.net> Changeset: a4622ff1462b Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/a4622ff1462b Added tag jdk8-b111 for changeset 17ee0d3e97fd ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:43:15 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:43:15 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b111 for changeset 85c1c94e7235 Message-ID: <20131010174317.C21E362F19@hg.openjdk.java.net> Changeset: d7e478820c56 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/d7e478820c56 Added tag jdk8-b111 for changeset 85c1c94e7235 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:43:58 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:43:58 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b111 for changeset 32edc7a2c866 Message-ID: <20131010174405.5466162F1B@hg.openjdk.java.net> Changeset: fc94ce4b899e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/fc94ce4b899e Added tag jdk8-b111 for changeset 32edc7a2c866 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:44:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:44:30 +0000 Subject: hg: hsx/hotspot-comp/jdk: 4 new changesets Message-ID: <20131010174709.5F2EC62F1C@hg.openjdk.java.net> Changeset: 88597d465e48 Author: ihse Date: 2013-10-01 15:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/88597d465e48 8016024: Remove solaris path from FillCacheFind Reviewed-by: erikj ! makefiles/Tools.gmk Changeset: 760af86b3f3f Author: erikj Date: 2013-10-03 11:27 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/760af86b3f3f 8024522: java.time packages missing from src.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 719befd87c7b Author: katleman Date: 2013-10-08 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/719befd87c7b Merge Changeset: 7af04d2d2139 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7af04d2d2139 Added tag jdk8-b111 for changeset 719befd87c7b ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:49:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:49:37 +0000 Subject: hg: hsx/hotspot-comp/nashorn: Added tag jdk8-b111 for changeset 75fd3486e584 Message-ID: <20131010174943.0948F62F1F@hg.openjdk.java.net> Changeset: fc2b6885e60e Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/nashorn/rev/fc2b6885e60e Added tag jdk8-b111 for changeset 75fd3486e584 ! .hgtags From john.coomes at oracle.com Thu Oct 10 10:48:51 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 10 Oct 2013 17:48:51 +0000 Subject: hg: hsx/hotspot-comp/langtools: Added tag jdk8-b111 for changeset af6244ba81b6 Message-ID: <20131010174911.C819462F1E@hg.openjdk.java.net> Changeset: a0e8fd2464d6 Author: cl Date: 2013-10-10 10:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a0e8fd2464d6 Added tag jdk8-b111 for changeset af6244ba81b6 ! .hgtags From roland.westrelin at oracle.com Thu Oct 10 10:50:12 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 10 Oct 2013 19:50:12 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5256B4A8.4020302@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> Message-ID: <26F473C8-6759-403E-A1A4-E190E91E0CA0@oracle.com> > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ That looks ok to me. Roland. From vladimir.kozlov at oracle.com Thu Oct 10 11:08:28 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 11:08:28 -0700 Subject: RFR(S): 8025227: Add -XX: flag to print code cache sweeper statistics In-Reply-To: References: <5244A397.9000006@oracle.com> <5244B0B3.5020209@oracle.com> <5246B929.5010208@oracle.com> Message-ID: <5256ED1C.9020102@oracle.com> On 10/10/13 9:09 AM, Tobias Hartmann wrote: > Hi, > > I just wanted to ask if my changes can be considered as reviewed now? Yes, it is reviewed. Thanks, Vladimir > > Thanks! > > Regards, > Tobias > > > 2013/9/28 Albert Noll > > > Already done. > > Best, > Albert > > > On 28.09.2013 00:40, Christian Thalinger wrote: >> I've already pointed this out to Albert but before we can accept >> your contributions you need to sign the OCA. See: >> >> http://openjdk.java.net/contribute/ >> >> On Sep 27, 2013, at 7:39 AM, Tobias Hartmann >> > wrote: >> >>> Chris, Vladimir, thank you for your reviews. >>> I followed your suggestions and added other useful statistics. >>> The output now looks like this: >>> >>> Method flushing statistics: >>> Total sweep time: 152.649ms >>> Peak sweep time: 15.979ms >>> Peak sweep fraction time: 3.209ms >>> Total number of stack traversals: 25 >>> Total number of flushed methods: 1320 >>> Total size of flushed methods: 7188Kb >>> >>> I did not include the other values, because as Vladimir already >>> said, they are removed by 8020151. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8025277/webrev.01/ >>> >>> >>> Thanks again for your review. >>> >>> Regards, >>> Tobias >>> >>> >>> >>> >>> 2013/9/27 Vladimir Kozlov >> > >>> >>> I agree with Chris, we are collecting those counters anyway. >>> I also like Chris's idea about collecting freed sizes. Note, >>> some counters will be removed by 8020151 changes: >>> >>> http://cr.openjdk.java.net/~anoll/8020151/webrev.03/ >>> >>> >>> Thanks, >>> Vladimir >>> >>> >>> On 9/26/13 2:13 PM, Chris Plummer wrote: >>> >>> Hi Tobias, >>> >>> The one comment I would have is that the statistics you >>> produce are all >>> timing related, but the option name implies you would get >>> a bit more >>> than this. For example, maybe something like a count of >>> the number of >>> methods flushed (and maybe total size). So I would >>> suggest either rename >>> to PrintMethodFlushingTimingStatistics (and also rename >>> the print >>> method), or add some other useful statistics to the >>> output. Probably all >>> the counters located below the " Stat counters" comment >>> are good candidates. >>> >>> best regards, >>> >>> Chris >>> >>> On 9/25/13 12:20 AM, Tobias Hartmann wrote: >>> >>> Hi, >>> >>> Please review the following small patch. >>> >>> bug:?https://bugs.openjdk.java.net/browse/JDK-8025277 >>> webrev:?http://cr.openjdk.java.net/~anoll/8025277/webrev.00/ >>> >>> >>> >>> >>> I added the diagnostic VM >>> option?PrintMethodFlushingStatistics to >>> print statistics about the NMethodSweeper (sweep >>> times) on exit. This >>> is useful to determine performance bottlenecks of >>> applications that >>> heavily compile code (e.g. nashorn). >>> >>> Thanks in advance! >>> >>> Best regards, >>> Tobias >>> >>> >>> By the way, I'm Tobias Hartmann, a student from >>> Switzerland currently >>> working on my Master Thesis "Code Cache Optimizations >>> for Dynamically >>> Compiled Languages" on supervision of Albert Noll. >>> >>> >>> >>> >> > > From vladimir.kozlov at oracle.com Thu Oct 10 11:47:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 11:47:42 -0700 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5256C912.8010709@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> <5255D625.1090609@oracle.com> <5256C912.8010709@oracle.com> Message-ID: <5256F64E.5050108@oracle.com> Albert, I don't think you should do such refactoring now. Runtime and Embedded will put you on "fire" for adding a field to Method class :) Lets do your original changes only for now. And do more complete solution suggested by John later for jdk9. File RFE. Thanks, Vladimir On 10/10/13 8:34 AM, Albert Noll wrote: > Vladimir, Chris, John, many thanks for your feedback. > > I'll run more tests to show that removing OSR methods in the sweeper is > stable (or not). > So far, I have not run into problems. > > @Chris, maybe you ran into 8024008 when you ran nashorn with a small > code cache size. > > There is one thing I do not understand in the current implementation. > What is the reason > that OSR nmethods are maintained in InstanceKlass and not in Method? > I do not see a reason but maybe I am missing something. > > Another thing I do not understand: When we remove an OSR method from the > list (in InstanceKlass), > we search for the max_comp level of all OSR nmethods of that class and > then set this max_level as > the max_level of the Method. Why would we set max_comp_level of Method X > to max_comp_level of > Method Y? > > I've an updated webrev, which moves the maintaining of the list of OSR > methods from InstanceKlass to > Method. This seems more logical to me. Moving the code to Method, also > fixes the problem (if it is a > problem) mentioned in the previous paragraph. > > Here is the webrev: > http://cr.openjdk.java.net/~anoll/8023191/webrev.01/ > > > Tests are still running but so far everything looks good. > Thanks in advance for your help. > > Best, > Albert > > On 10.10.2013 00:18, Vladimir Kozlov wrote: >> On 10/9/13 10:21 AM, Vladimir Kozlov wrote: >>> Albert, >>> >>> Changes are fine but you need more testing. >>> >>> Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests >>> with -Xcomp and without it). >>> >>> Also the bug report has link to test (jittest). Can you build and run it >>> too to see if it solves the problem with small codecache? It fills >>> codecache with osr nmethods. >>> >>> It is very delicate matter. There was a reason we did not remove OSR >>> nmethod until corresponding klass is unloaded (yes, deoptimization can >>> make it non-entrant). Unfortunately I don't remember it. May be John >>> know. Non of inline caches are pointing to OSR nmethods since it is >>> called only from Interpreter. There is transition phase at the start of >>> OSR nmethod when it calls runtime to convert interpreter frame to >>> compiled frame. And method has separate field for osr nmethods. >> >> I think I dig out the answer. >> >> First, the last statement in previous mail is wrong. The method object >> does not have reference to osr nmethods. Each java method can have >> several alive OSR nmethods for different bcis. Instead method's holder >> class has list of all OSR nmethods associated with all methods of this >> class. Each time we do osr lookup we go through this list. >> Since method does not have reference to OSR the original flushing >> (speculative disconnection) could not be implemented for OSR nmethods. >> >> Second. Originally osr nmethod were not cleaned up from codecache. >> Here is the comment and the code in >> nmethod::make_not_entrant_or_zombie() from long time ago: >> >> // Code for an on-stack-replacement nmethod is removed when a class >> gets unloaded. >> // They never become zombie/non-entrant, so the nmethod sweeper will >> never remove >> // them. Instead the entry_bci is set to InvalidOSREntryBci, so the >> osr nmethod >> // will never be used anymore. That the nmethods only gets removed >> when class unloading >> // happens, make life much simpler, since the nmethods are not just >> going to disappear >> // out of the blue. >> if (is_osr_only_method()) { >> if (osr_entry_bci() != InvalidOSREntryBci) { >> // only log this once >> log_state_change(state); >> } >> invalidate_osr_method(); >> return; >> } >> >> This code was changed by Tom for 5057818 4 years ago to allow cleanup >> unused OSR nmethods from codecache: >> >> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/032260830071 >> >> Third, I think those changes are not complete. >> nmethod::invalidate_osr_method() should check for _entry_bci == >> InvalidOSREntryBci to avoid lookup through osr list again after >> nmethod change from non_entrant to zombie (invalidate_osr_method() is >> called each time make_not_entrant_or_zombie() is called). May be other >> places. Note, when we process osr nmethod::_code should not be touched >> since it is pointing to normal compiled nmethod which could still be >> alive. >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/8/13 10:18 PM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I have a review for this small patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023191 >>>> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ >>>> >>>> >>>> Problem: OSR methods are not removed from code cache to free space. >>>> Solution: Remove OSR methods from code cache. OSR methods c an be made >>>> not-entrant and are then removed from the code cache >>>> likenon-OSR >>>> methods. Other parts in the code (e.g., >>>> deoptimization.cpp:1547) already make >>>> OSR methods not-entrant. >>>> >>>> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there >>>> is an impact on performance. >>>> >>>> Many thanks in advance, >>>> Albert > From albert.noll at oracle.com Thu Oct 10 12:46:10 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 10 Oct 2013 21:46:10 +0200 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <5256F64E.5050108@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> <5255D625.1090609@oracle.com> <5256C912.8010709@oracle.com> <5256F64E.5050108@oracle.com> Message-ID: <52570402.3010900@oracle.com> Sure, I was not aware that this is such a big deal. I'll run more tests and let you know. Best, Albert On 10.10.2013 20:47, Vladimir Kozlov wrote: > Albert, > > I don't think you should do such refactoring now. Runtime and Embedded > will put you on "fire" for adding a field to Method class :) > > Lets do your original changes only for now. And do more complete > solution suggested by John later for jdk9. File RFE. > > Thanks, > Vladimir > > On 10/10/13 8:34 AM, Albert Noll wrote: >> Vladimir, Chris, John, many thanks for your feedback. >> >> I'll run more tests to show that removing OSR methods in the sweeper is >> stable (or not). >> So far, I have not run into problems. >> >> @Chris, maybe you ran into 8024008 when you ran nashorn with a small >> code cache size. >> >> There is one thing I do not understand in the current implementation. >> What is the reason >> that OSR nmethods are maintained in InstanceKlass and not in Method? >> I do not see a reason but maybe I am missing something. >> >> Another thing I do not understand: When we remove an OSR method from the >> list (in InstanceKlass), >> we search for the max_comp level of all OSR nmethods of that class and >> then set this max_level as >> the max_level of the Method. Why would we set max_comp_level of Method X >> to max_comp_level of >> Method Y? >> >> I've an updated webrev, which moves the maintaining of the list of OSR >> methods from InstanceKlass to >> Method. This seems more logical to me. Moving the code to Method, also >> fixes the problem (if it is a >> problem) mentioned in the previous paragraph. >> >> Here is the webrev: >> http://cr.openjdk.java.net/~anoll/8023191/webrev.01/ >> >> >> Tests are still running but so far everything looks good. >> Thanks in advance for your help. >> >> Best, >> Albert >> >> On 10.10.2013 00:18, Vladimir Kozlov wrote: >>> On 10/9/13 10:21 AM, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> Changes are fine but you need more testing. >>>> >>>> Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk >>>> tests >>>> with -Xcomp and without it). >>>> >>>> Also the bug report has link to test (jittest). Can you build and >>>> run it >>>> too to see if it solves the problem with small codecache? It fills >>>> codecache with osr nmethods. >>>> >>>> It is very delicate matter. There was a reason we did not remove OSR >>>> nmethod until corresponding klass is unloaded (yes, deoptimization can >>>> make it non-entrant). Unfortunately I don't remember it. May be John >>>> know. Non of inline caches are pointing to OSR nmethods since it is >>>> called only from Interpreter. There is transition phase at the >>>> start of >>>> OSR nmethod when it calls runtime to convert interpreter frame to >>>> compiled frame. And method has separate field for osr nmethods. >>> >>> I think I dig out the answer. >>> >>> First, the last statement in previous mail is wrong. The method object >>> does not have reference to osr nmethods. Each java method can have >>> several alive OSR nmethods for different bcis. Instead method's holder >>> class has list of all OSR nmethods associated with all methods of this >>> class. Each time we do osr lookup we go through this list. >>> Since method does not have reference to OSR the original flushing >>> (speculative disconnection) could not be implemented for OSR nmethods. >>> >>> Second. Originally osr nmethod were not cleaned up from codecache. >>> Here is the comment and the code in >>> nmethod::make_not_entrant_or_zombie() from long time ago: >>> >>> // Code for an on-stack-replacement nmethod is removed when a class >>> gets unloaded. >>> // They never become zombie/non-entrant, so the nmethod sweeper will >>> never remove >>> // them. Instead the entry_bci is set to InvalidOSREntryBci, so the >>> osr nmethod >>> // will never be used anymore. That the nmethods only gets removed >>> when class unloading >>> // happens, make life much simpler, since the nmethods are not just >>> going to disappear >>> // out of the blue. >>> if (is_osr_only_method()) { >>> if (osr_entry_bci() != InvalidOSREntryBci) { >>> // only log this once >>> log_state_change(state); >>> } >>> invalidate_osr_method(); >>> return; >>> } >>> >>> This code was changed by Tom for 5057818 4 years ago to allow cleanup >>> unused OSR nmethods from codecache: >>> >>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/032260830071 >>> >>> Third, I think those changes are not complete. >>> nmethod::invalidate_osr_method() should check for _entry_bci == >>> InvalidOSREntryBci to avoid lookup through osr list again after >>> nmethod change from non_entrant to zombie (invalidate_osr_method() is >>> called each time make_not_entrant_or_zombie() is called). May be other >>> places. Note, when we process osr nmethod::_code should not be touched >>> since it is pointing to normal compiled nmethod which could still be >>> alive. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/8/13 10:18 PM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> could I have a review for this small patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023191 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ >>>>> >>>>> >>>>> Problem: OSR methods are not removed from code cache to free space. >>>>> Solution: Remove OSR methods from code cache. OSR methods c an be >>>>> made >>>>> not-entrant and are then removed from the code cache >>>>> likenon-OSR >>>>> methods. Other parts in the code (e.g., >>>>> deoptimization.cpp:1547) already make >>>>> OSR methods not-entrant. >>>>> >>>>> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if >>>>> there >>>>> is an impact on performance. >>>>> >>>>> Many thanks in advance, >>>>> Albert >> From christian.thalinger at oracle.com Thu Oct 10 14:24:33 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Oct 2013 14:24:33 -0700 Subject: RFR(M): 8023014: closed/com/oracle/jfr/compiler/CodeSweeperSweepNoFlushTest.java fails with HS crash In-Reply-To: <5254E2FA.1000602@oracle.com> References: <52434207.2080804@oracle.com> <52436843.6010008@oracle.com> <52445202.7010303@oracle.com> <524471E4.6060508@oracle.com> <524A797F.2010006@oracle.com> <524AF59C.3040908@oracle.com> <524BEBC2.4030202@oracle.com> <524C4EA8.1020109@oracle.com> <524D6A32.5080003@oracle.com> <524DEB5B.1060603@oracle.com> <5254E2FA.1000602@oracle.com> Message-ID: Looks good. On Oct 8, 2013, at 10:00 PM, Albert Noll wrote: > Hi Vladimir, hi Christian, > > thanks for looking at the patch. > @Christian: I fixed the issues you brought up. > @Vladimir: See comments inline: > > Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.05/ > > On 04.10.2013 00:10, Vladimir Kozlov wrote: >> c1_Compiler.cpp. Can you have next in header file since they are empty? And why you need them at all (C2Compiler does not have them)?: >> >> +Compiler::Compiler () {} >> +Compiler::~Compiler() {} >> > I need Compiler::Compiler() {}, otherwise I get the following error: > > Error: failed /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so, because /export/anoll/alt_export/jre/lib/amd64/server/libjvm.so: undefined symbol: _ZN8CompilerC1Ev > > +Compiler::~Compiler() {} can be removed. > >> I think we can keep compiler objects (Compiler and c2Compiler) since they should be very small. You can keep your comment in shutdown_compiler_runtime() but remove commented code. >> > Done. >> Indention in CompileQueue::delete_all(): >> >> } >> _first = NULL; >> } >> > Done. >> >> In should_perform_shutdown() the _compiler_state could be changed >> >> before other threads reach "if (comp->is_state_failed())" check in >> >> init_compiler_runtime(). >> > True. I added a function should_exit(), which returns true if the state >> > if failed, or shutting down. >> >> You actually don't need to change state to shutting_shown. This state is not checked anywhere (you removed waiting loop). The 'failed' state can stay until the last thread change it to shut_down. So you don't need new method should_exit(). >> >> Looking more on get_buffer_blob() == null case and I think you don't need special C1 check in init_compiler_runtime() because it will not reach it. Compiler::initialize() set state to 'failed' if buffer is NULL so the first condition in init_compiler_runtime() will be true. >> > I think we need this check, since compiler initialization can be successful and there is enough free > space in the code cache to allocate the buffer blob for the first couple of threads, but not for all threads. > The test specifically tests this exit path. > > Many thanks again, > Albert > >> The test is fine. At least we have something. >> >> Thanks, >> Vladimir >> >> On 10/3/13 5:59 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for looking at the patch. See comments inline. >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~anoll/8023014/webrev.04/ >>> >>> >>> On 02.10.2013 18:49, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> In disable_compilation_forever() the comment does not correspond to code. >>>> >>> I removed the comment. >>>> In should_perform_shutdown() the _compiler_state could be changed >>>> before other threads reach "if (comp->is_state_failed())" check in >>>> init_compiler_runtime(). >>> True. I added a function should_exit(), which returns true if the state >>> if failed, or shutting down. >>>> Yes, decrementing with lock is fine, you are right. >>>> >>>> The message should say why we do shutdown (no space to initialize >>>> compiler runtime): >>>> warning("Shutting down compiler >>>> >>> The warning messages are now: >>> - "Shutting down compiler %s (no space to run compiler)" or >>> - "Initialization of %s thread failed (no space to run compiler thread)" >>> if a C1 compiler thread fails to allocate memory. >>>> Please, explain what references: >>>> >>>> + // We could delete compiler runtimes also. However, >>>> + // there are references to the compiler runtime(s) >>>> + // (e.g., by nmethods) which then fail. This can be >>>> >>> Done. >>>> It would be nice to have regression test for this. >>> I added a regression test, which checks that compiler threads exit, if >>> there is not sufficient free code cache >>> to init all threads. Testing a failing initialization of C2 is tricky, >>> since a C2 initialization failure depends on the >>> scheduling of the compiler threads. >>> >>> Thanks again, >>> Albert >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/2/13 2:47 AM, Albert Noll wrote: >>>>> Hi Vladimir, >>>>> >>>>> thanks again for the feedback. I tested the patch as you proposed, >>>>> i.e., make sure that >>>>> the patch works if the C1 and/or C2 compiler fails to initialize. I >>>>> tested with up to 256 compiler >>>>> threads. >>>>> >>>>> To make sure that all compiler threads exit, I had to do additional >>>>> modifications in CompileQueue::get() >>>>> and the caller of this method. With these changes, one can also exit >>>>> compiler threads if -XX:-UseCodeCacheFlushing >>>>> is set, which is also contained in this webrev. >>>>> >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.03/ >>>>> >>>>> >>>>> See more comments inline: >>>>> >>>>> >>>>> On 01.10.2013 18:17, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> In general it looks good. Please, test it extensively with Tiered >>>>>> with codecache size enough to initialize one >>>>>> compiler but not an other to verify your code. >>>>>> >>>>> Done. >>>>>> I think you need to swap lock and decrement otherwise it will deadlock: >>>>>> >>>>>> +bool AbstractCompiler::should_perform_shutdown() { >>>>>> + MutexLocker only_one(CompileThread_lock); >>>>>> + _num_compiler_threads--; >>>>>> >>>>> I simplified this function. In fact it is fine if the last thread >>>>> (i.e., if _num_compiler_threads == 0) >>>>> does the shutdown. The while() statement is really not necessary. >>>>> However, we have to decrement >>>>> _num_compiler_threads when we hold the lock. Otherwise we are not >>>>> guaranteed to reach 0 >>>>> (-- is not atomic). >>>>> >>>>>> comp->set_shut_down(); and delete _compilers[0]; should be done by >>>>>> one thread I think. >>>>> Done. >>>>> >>>>>> >>>>>> Small note, you accidentally removed nl in c2compiler.cpp: >>>>>> >>>>>> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> +/* * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> >>>>>> >>>>> Fixed. >>>>> >>>>> Thanks again, >>>>> Albert >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/1/13 12:27 AM, Albert Noll wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> thanks again for looking at the patch. See comments inline: >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.02/ >>>>>>> >>>>>>> >>>>>>> On 26.09.2013 19:41, Vladimir Kozlov wrote: >>>>>>>> Albert, >>>>>>>> >>>>>>>> There is small window between check and set_state where state can >>>>>>>> became initialized or still be uninitialized: >>>>>>>> + if (!is_initialized()) { >>>>>>>> + set_state(failed); >>>>>>>> >>>>>>>> so you may hit assert in set_state(). >>>>>>>> >>>>>>>> I think you need to call set_state(failed) only when C1 runtime is >>>>>>>> initialized after lock: >>>>>>>> >>>>>>>> if (should_perform_init()) { >>>>>>>> if (buffer_blob == NULL) { >>>>>>>> set_state(failed); >>>>>>>> } else { >>>>>>>> init_c1_runtime(); >>>>>>>> set_state(initialized); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>> You are right. I adapted the patch according to your suggestion. >>>>>>> >>>>>>>> In this case it will match behavior for C2 which means that you >>>>>>>> need to shutdown compilation since you was not able to >>>>>>>> initialize compilation runtime. It will require more code to do >>>>>>>> proper shutdown not just exiting thread (free >>>>>>>> compilation queues, resetting flags). An it will be more >>>>>>>> complicated for Tiered case (I think we can use simple >>>>>>>> approach to shutdown all compilations even if only one Compiler is >>>>>>>> not initialized since it is rare case). >>>>>>>> >>>>>>> I added code to shut-down compilation. If compiler runtime >>>>>>> initialization fails, a flag is set which disables >>>>>>> compilation forever. In the current >>>>>>> version, all compilers are disabled if C1 and/or C2 runtime >>>>>>> initialization fails (also in case of tiered compilation). I >>>>>>> think this solution is fine for >>>>>>> now, since a compiler runtime initialization failure should not >>>>>>> happen in practice. If it ever turns out to be a >>>>>>> problem, i.e., it is required that we >>>>>>> we use one compiler if the other compiler failed to initialize, I >>>>>>> suggest we fix this in another bug. The current bug >>>>>>> appears only due to an artificial >>>>>>> setting of the code cache size. >>>>>>> >>>>>>> Compiler shut-down is performed by one thread. This thread waits >>>>>>> until all compiler threads have exited to compiler >>>>>>> loop. The thread then >>>>>>> deletes all tasks from the compile queue, deletes the compiler >>>>>>> objects, and sets the objects to NULL. >>>>>>> >>>>>>> Please let me know if you think this solution is fine, or if there >>>>>>> are other things that need to be considered. >>>>>>> The current version passed jprt. >>>>>>> >>>>>>> Many thanks again, >>>>>>> Albert >>>>>>> >>>>>>>> If C1 runtime was initialized but we was not able to allocate >>>>>>>> buffer for some threads your current code in >>>>>>>> compileBroker.cpp will handle such case. So you don't need to set >>>>>>>> state to 'failed'. >>>>>>>> >>>>>>>> thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/26/13 8:25 AM, Albert Noll wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> thanks for looking at the patch. >>>>>>>>> Here is the new webrev: >>>>>>>>> http://cr.openjdk.java.net/~anoll/8023014/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> See comments inline: >>>>>>>>> >>>>>>>>> On 26.09.2013 00:48, Vladimir Kozlov wrote: >>>>>>>>>> Thank you, Albert >>>>>>>>>> >>>>>>>>>> I would suggest to do TieredStartAtLevel changes separately, it >>>>>>>>>> is not >>>>>>>>>> related to this bug. >>>>>>>>>> >>>>>>>>> Done. >>>>>>>>>> Second, how we can guard the initialization with a field >>>>>>>>>> (_compiler_state and original _is_initialized) which is not static? >>>>>>>>>> >>>>>>>>>> You don't need separate local do_init in C*_Compiler.cpp since >>>>>>>>>> it is >>>>>>>>>> used only once: >>>>>>>>>> >>>>>>>>> Done. >>>>>>>>>> + if (should_perform_init()) { >>>>>>>>>> >>>>>>>>>> abstractCompiler.cpp: >>>>>>>>>> You removed ThreadInVMfromNative and ResetNoHandleMark from >>>>>>>>>> should_perform_init() and set_state(). Why? There is assert in >>>>>>>>>> check_prelock_state() called from Monitor::lock(): >>>>>>>>>> >>>>>>>>>> assert((!thread->is_Java_thread() || ((JavaThread >>>>>>>>>> *)thread)->thread_state() == _thread_in_vm) >>>>>>>>>> || rank() == Mutex::special, "wrong thread state for using >>>>>>>>>> locks"); >>>>>>>>>> >>>>>>>>>> Compiler threads are Java threads, so you should be in VM state >>>>>>>>>> when >>>>>>>>>> lock. How you did not hit this assert? >>>>>>>>>> >>>>>>>>> The state transition from native to VM (and ResetNoHandleMark) is >>>>>>>>> now in >>>>>>>>> compileBroker.cpp:1543. >>>>>>>>>> >>>>>>>>>> Typo in abstractCompiler.hpp 'methos': >>>>>>>>>> >>>>>>>>>> + // This method returns true for the first compiler thread that >>>>>>>>>> reaches that methos. >>>>>>>>>> >>>>>>>>>> It is not 'compiler object', it is 'compiler runtime' (yes it was >>>>>>>>>> before but it was not accurate, it could be mistaking for Compile >>>>>>>>>> object created for each compilation): >>>>>>>>>> >>>>>>>>>> + // This thread will initialize the compiler object. >>>>>>>>>> >>>>>>>>>> Swap lines (and use 'runtime' in the comment): >>>>>>>>>> >>>>>>>>>> ! bool is_initialized () { return _compiler_state == >>>>>>>>>> initialized; } >>>>>>>>>> ! // Get/set state of compiler objects >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> c2compiler.cpp: >>>>>>>>>> >>>>>>>>>> C2Compiler:: is not needed: >>>>>>>>>> >>>>>>>>>> + bool successful = C2Compiler::init_c2_runtime(); >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Fixed the issues above. >>>>>>>>>> Should we exit Compiler thread which failed local buffer allocation >>>>>>>>>> instead parking? Why keep resources allocated for it? >>>>>>>>>> >>>>>>>>> You are right, there is no reason the keep these threads around. >>>>>>>>> Compiler threads wo are not initialized correctly >>>>>>>>> now exit the VM. >>>>>>>>> >>>>>>>>> The patch is currently in west queue. >>>>>>>>> >>>>>>>>> Many thanks again, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 9/25/13 1:05 PM, Albert Noll wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> could I have a review for this patch? >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023014 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023014/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Problem: C1/C2 compiler initialization can fail if there is not >>>>>>>>>>> enough >>>>>>>>>>> memory in the code cache to generate all stubs. >>>>>>>>>>> This problem occurs only with a small code cache size. >>>>>>>>>>> >>>>>>>>>>> Solution: Check correctness of (parts of) C1/C2 initialization and >>>>>>>>>>> disable compiler (C1 and/or C2) if the compiler / thread >>>>>>>>>>> was not initialized correctly. >>>>>>>>>>> >>>>>>>>>>> Testing: jprt, test case, benchmarks >>>>>>>>>>> >>>>>>>>>>> This patch also contains a refactored version of compiler >>>>>>>>>>> object/thread >>>>>>>>>>> initialization. In the new version, a compiler object/thread is >>>>>>>>>>> initialized prior entering the main compiler loop. In the old >>>>>>>>>>> version, >>>>>>>>>>> the check if the compiler/thread is initialized was >>>>>>>>>>> done in the main compiler loop (and hence before every >>>>>>>>>>> compilation). >>>>>>>>>>> >>>>>>>>>>> To continue execution with a limited code cache size, the code >>>>>>>>>>> types >>>>>>>>>>> 'AdapterBlob' and 'MethodHandlesAdapterBlob' must >>>>>>>>>>> be 'critical' allocations in the code cache, i.e., they must >>>>>>>>>>> use space >>>>>>>>>>> reserved by CodeCacheMinimumFreeSpace. >>>>>>>>>>> >>>>>>>>>>> In addition I removed some unued code. >>>>>>>>>>> >>>>>>>>>>> Many thanks in advance for reviewing. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Albert >>>>>>>>> >>>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131010/eb370379/attachment-0001.html From christian.thalinger at oracle.com Thu Oct 10 14:37:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Oct 2013 14:37:14 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <5E3AFA1B-FA91-4FF1-A73E-45D82FBDF8F2@oracle.com> Message-ID: On Oct 9, 2013, at 8:46 AM, Roland Westrelin wrote: > Hi Chris, > > Thanks for reviewing this. > >> src/share/vm/c1/c1_GraphBuilder.cpp: >> >> + void profile_return_type(Value ret, ciMethod* callee, ciMethod* m = NULL, int bci = -1); >> >> +void GraphBuilder::profile_return_type(Value ret, ciMethod* callee, ciMethod* m, int invoke_bci) { >> + assert((m == NULL) == (invoke_bci < 0), "invalid method and invalid bci together"); >> + if (m == NULL) { >> + m = method(); >> + } >> + if (invoke_bci < 0) { >> + invoke_bci = bci(); >> + } >> >> Is there potentially a problem if somehow InvocationEntryBci or InvalidOSREntryBci are passed in: >> >> enum MethodCompilation { >> InvocationEntryBci = -1, // i.e., not a on-stack replacement compilation >> InvalidOSREntryBci = -2 >> }; >> >> ? > > You mean profile_return_type() being passed bci = InvocationEntryBci and overriding it? Passing InvocationEntryBci would be a bit problem here and I don't see how it can happen. Yeah, I'm pretty sure it doesn't happen but I wanted to bring it up. I think my point is maybe -1 is not the best default value here. > >> + int bci = invoke_bci; >> >> Why are you having a new variable here? > > There's another change coming on top of this one. I broke a big change in pieces to the best I could but some code may still look a bit strange. Thanks for spotting it. I'll get rid of bci. Got it. > >> >> + ciTypeEntriesAtCall* args_and_ret = data->is_CallTypeData() ? ((ciCallTypeData*)data)->args_and_ret() : ((ciVirtualCallTypeData*)data)->args_and_ret(); >> >> ! const TypeEntriesAtCall* args_and_ret() const { return &_args_and_ret; } >> >> I should've mentioned this in the previous review but can't we make args_and_ret() a virtual method? > > In what class? ProfileData? I don't know; I've lost track of the class hierarchy. If the class hierarchy is sane there must be a super class that's suitable. > Wouldn't that expose some implementation details at a level where they don't make much sense. Also on ci* side, there's no common root class and we probably don't want ci* stuff to leak in methodData.hpp. Why isn't there a common super class in ci? > >> src/share/vm/oops/methodData.cpp: >> >> 159 int TypeStackSlotEntries::compute_cell_count(Symbol* signature, int max) { >> 160 int args_count = 0; >> 161 ResourceMark rm; >> 162 SignatureStream ss(signature); >> 163 args_count += MIN2(ss.reference_parameter_count(), max); >> 164 return args_count * per_arg_cell_count; >> 165 } >> >> Why are you using args_count += now? Before you had: >> >> 164 ResourceMark rm; >> 165 SignatureStream ss(inv.signature()); >> 166 int args_count = MIN2(ss.reference_parameter_count(), max); > > Same as above. Will clean it up. > >> >> ! void TypeStackSlotEntries::post_initialize(Symbol* signature, bool has_receiver) { >> ResourceMark rm; >> + int start = 0; >> + ArgumentOffsetComputer aos(signature, _nb_entries-start); >> + aos.total(); >> + for (int i = start; i < _nb_entries; i++) { >> + set_stack_slot(i, aos.off_at(i-start) + (has_receiver ? 1 : 0)); >> + set_type(i, type_none()); >> + } >> + } >> >> I don't see start being changed. Any reason to have it in a local? If you want to keep it for clarity make it a const int. > > Again same as above. I can see a pattern here :-) > >> src/share/vm/oops/methodData.hpp: >> >> 753 protected: >> 754 const int _nb_entries; >> >> I'd advocate for not abbreviating to ambiguous letters. Use the word you wanted to use. > > Ok. > > Roland. > >> >> On Oct 8, 2013, at 9:22 AM, Roland Westrelin wrote: >> >>> http://cr.openjdk.java.net/~roland/8026054/webrev.00/ >>> >>> Follow up to 8023657: New type profiling points: arguments to call >>> >>> 8023657 introduced TypeStackSlotEntries to keep track of types of arguments. This change adds a couple more similar classes: TypeEntriesAtCall and ReturnTypeEntry which is maybe the confusing part of the change. ReturnTypeEntry keeps track of types of return values, TypeStackSlotEntries of types of arguments. In the next type profiling change, TypeStackSlotEntries will be used for parameter type profiling. TypeEntriesAtCall is ReturnTypeEntry + TypeStackSlotEntries to do the profiling at invokes. The number of cells needed at invokes is kept in TypeEntriesAtCall (to count cells for arguments and return value) and some methods in TypeStackSlotEntries were moved to TypeEntriesAtCall as a consequence. >>> >>> The output of PrintMethodData is: >>> >>> 17 invokevirtual 3 >>> 16 bci: 17 VirtualCallData count(0) entries(1) >>> 'TestProfiling'(4744 1.00) >>> argument types 0: stack(1) 'TestProfiling$C' >>> 1: stack(2) 'TestProfiling$B' >>> return type 'TestProfiling$C' >>> >>> Roland. >> > From igor.veresov at oracle.com Thu Oct 10 14:56:53 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 10 Oct 2013 14:56:53 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <525641C6.8030702@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> Message-ID: <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> Thanks for the review! On Oct 9, 2013, at 10:57 PM, Vladimir Kozlov wrote: > + // Find if any path from start_mem to any node is end_set has side effects. > typo ^ is -> in > yup > Can you use set() method instead visited <<= start_mem->_idx? It is the same but more easy to understand. > ok, and I've also added remove() to VectorSet for symmetry. > General note. Instead of checking memory between all possible combinations of append calls can you check only between final call toString and first call to StringBuffer? It should cover all. ok > > I think in product VM you can bailout immideately when you see store and loadstore. > That's a good point, added that. I moved the path printing for debugging in that branch as well - I'm not quite comfortable having different logic in debug in product. So the path printout is going to terminate with the found side effect node (store or loadstore). > Instead of next_edge + path you can use Node_Stack class specifically designed for such cases. > See example in PhaseCFG::schedule_early(). > That's really useful! I haven't noticed that data structure. Refactored the code to use it. > I think you need to assert assert for nodes you skip - closing } should be } else { assert() } to make sure you did not miss some nodes which affect memory. > ok I've updated the webrev in-place: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ igor > thanks, > Vladimir > > On 10/9/13 7:39 PM, Igor Veresov wrote: >> I've update the code a bit. I decided to share the arrays I use for traversal between the calls to path_has_side_effects(). >> >> On Oct 9, 2013, at 3:11 PM, Igor Veresov wrote: >> >>> String concat optimization optimization collapses the pattern >>> >>> StringBuffer x = new StringBuffer(); >>> x.append(y); >>> x.append(z); >>> x.toString(); >>> >>> into a single allocation of a string and forming the result directly. All possible deopts that may happen in the optimized code restart this pattern from the beginning (starting from the StringBuffer allocation). That means that the whole pattern must me side-effect free. Existing code verifies that the pattern is sound from the control flow point of view, but omits the memory flow verification. This leaves a possibility for a computation on an argument of append() to have side effects. The fix adds memory flow analysis to find the possibly offending stores. We iterate up the memory graph (doing DFS) finding all possible simple paths starting from an append call, until we see the next append call, or a StringBuffer constructor. Then we analyze the path to see if it contains side effects. The analysis is exponential, so we limit the number of iterations. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ >>> >>> Testing: eyeballing the graph, the failing tests, jprt >>> >>> igor >> From christian.thalinger at oracle.com Thu Oct 10 15:03:07 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Oct 2013 15:03:07 -0700 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5256B4A8.4020302@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> Message-ID: + static const uint LRG_All_STACK_SIZE = 0xFFFFF; // This mask size is used to tell that the mask of this LRG supports stack positions It looks odd to mix upper and lower case here. You tried to make it look like a macro but you didn't quite make it :-) Suggest since it's not a macro and it's a LRG class member to either use: static const uint AllStack_size = 0xFFFFF; or: static const uint ALL_STACK_SIZE = 0xFFFFF; I'd vote for the former. On Oct 10, 2013, at 7:07 AM, Niclas Adlertz wrote: > Hi Roland, > >> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? > There's nothing wrong about _eff_degree being bigger than LRG_All_STACK_SIZE as long as we don't have a mask supporting stack locations, but you are right that we could add asserts when setting _eff_degree or adding to _eff_degree when the mask supports stack positions. > >> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? > That might be a good idea, I just followed the old standard. > > Thanks. > > webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ > > Kind Regards, > Niclas Adlertz > > On 2013-10-10 14:41, Roland Westrelin wrote: >>> When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes bigger than 65535. >> >> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >> >> Roland. >> > From john.r.rose at oracle.com Thu Oct 10 15:04:48 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 10 Oct 2013 15:04:48 -0700 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <52570402.3010900@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> <5255D625.1090609@oracle.com> <5256C912.8010709@oracle.com> <5256F64E.5050108@oracle.com> <52570402.3010900@oracle.com> Message-ID: <62020050-D7F2-40A4-9E8C-778165315E01@oracle.com> To be complete, I am suggesting overloading the existing M::_code field not adding a new one, and not right now. -- John (on my iPhone) On Oct 10, 2013, at 12:46 PM, Albert Noll wrote: > Sure, > > I was not aware that this is such a big deal. I'll run more tests and let you know. > > Best, > Albert > > On 10.10.2013 20:47, Vladimir Kozlov wrote: >> Albert, >> >> I don't think you should do such refactoring now. Runtime and Embedded will put you on "fire" for adding a field to Method class :) >> >> Lets do your original changes only for now. And do more complete solution suggested by John later for jdk9. File RFE. >> >> Thanks, >> Vladimir >> >> On 10/10/13 8:34 AM, Albert Noll wrote: >>> Vladimir, Chris, John, many thanks for your feedback. >>> >>> I'll run more tests to show that removing OSR methods in the sweeper is >>> stable (or not). >>> So far, I have not run into problems. >>> >>> @Chris, maybe you ran into 8024008 when you ran nashorn with a small >>> code cache size. >>> >>> There is one thing I do not understand in the current implementation. >>> What is the reason >>> that OSR nmethods are maintained in InstanceKlass and not in Method? >>> I do not see a reason but maybe I am missing something. >>> >>> Another thing I do not understand: When we remove an OSR method from the >>> list (in InstanceKlass), >>> we search for the max_comp level of all OSR nmethods of that class and >>> then set this max_level as >>> the max_level of the Method. Why would we set max_comp_level of Method X >>> to max_comp_level of >>> Method Y? >>> >>> I've an updated webrev, which moves the maintaining of the list of OSR >>> methods from InstanceKlass to >>> Method. This seems more logical to me. Moving the code to Method, also >>> fixes the problem (if it is a >>> problem) mentioned in the previous paragraph. >>> >>> Here is the webrev: >>> http://cr.openjdk.java.net/~anoll/8023191/webrev.01/ >>> >>> >>> Tests are still running but so far everything looks good. >>> Thanks in advance for your help. >>> >>> Best, >>> Albert >>> >>> On 10.10.2013 00:18, Vladimir Kozlov wrote: >>>> On 10/9/13 10:21 AM, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> Changes are fine but you need more testing. >>>>> >>>>> Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests >>>>> with -Xcomp and without it). >>>>> >>>>> Also the bug report has link to test (jittest). Can you build and run it >>>>> too to see if it solves the problem with small codecache? It fills >>>>> codecache with osr nmethods. >>>>> >>>>> It is very delicate matter. There was a reason we did not remove OSR >>>>> nmethod until corresponding klass is unloaded (yes, deoptimization can >>>>> make it non-entrant). Unfortunately I don't remember it. May be John >>>>> know. Non of inline caches are pointing to OSR nmethods since it is >>>>> called only from Interpreter. There is transition phase at the start of >>>>> OSR nmethod when it calls runtime to convert interpreter frame to >>>>> compiled frame. And method has separate field for osr nmethods. >>>> >>>> I think I dig out the answer. >>>> >>>> First, the last statement in previous mail is wrong. The method object >>>> does not have reference to osr nmethods. Each java method can have >>>> several alive OSR nmethods for different bcis. Instead method's holder >>>> class has list of all OSR nmethods associated with all methods of this >>>> class. Each time we do osr lookup we go through this list. >>>> Since method does not have reference to OSR the original flushing >>>> (speculative disconnection) could not be implemented for OSR nmethods. >>>> >>>> Second. Originally osr nmethod were not cleaned up from codecache. >>>> Here is the comment and the code in >>>> nmethod::make_not_entrant_or_zombie() from long time ago: >>>> >>>> // Code for an on-stack-replacement nmethod is removed when a class >>>> gets unloaded. >>>> // They never become zombie/non-entrant, so the nmethod sweeper will >>>> never remove >>>> // them. Instead the entry_bci is set to InvalidOSREntryBci, so the >>>> osr nmethod >>>> // will never be used anymore. That the nmethods only gets removed >>>> when class unloading >>>> // happens, make life much simpler, since the nmethods are not just >>>> going to disappear >>>> // out of the blue. >>>> if (is_osr_only_method()) { >>>> if (osr_entry_bci() != InvalidOSREntryBci) { >>>> // only log this once >>>> log_state_change(state); >>>> } >>>> invalidate_osr_method(); >>>> return; >>>> } >>>> >>>> This code was changed by Tom for 5057818 4 years ago to allow cleanup >>>> unused OSR nmethods from codecache: >>>> >>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/032260830071 >>>> >>>> Third, I think those changes are not complete. >>>> nmethod::invalidate_osr_method() should check for _entry_bci == >>>> InvalidOSREntryBci to avoid lookup through osr list again after >>>> nmethod change from non_entrant to zombie (invalidate_osr_method() is >>>> called each time make_not_entrant_or_zombie() is called). May be other >>>> places. Note, when we process osr nmethod::_code should not be touched >>>> since it is pointing to normal compiled nmethod which could still be >>>> alive. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/8/13 10:18 PM, Albert Noll wrote: >>>>>> Hi, >>>>>> >>>>>> could I have a review for this small patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023191 >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ >>>>>> >>>>>> >>>>>> Problem: OSR methods are not removed from code cache to free space. >>>>>> Solution: Remove OSR methods from code cache. OSR methods c an be made >>>>>> not-entrant and are then removed from the code cache >>>>>> likenon-OSR >>>>>> methods. Other parts in the code (e.g., >>>>>> deoptimization.cpp:1547) already make >>>>>> OSR methods not-entrant. >>>>>> >>>>>> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there >>>>>> is an impact on performance. >>>>>> >>>>>> Many thanks in advance, >>>>>> Albert > From vladimir.kozlov at oracle.com Thu Oct 10 15:21:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 15:21:49 -0700 Subject: RFR(M) 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> Message-ID: <5257287D.8010301@oracle.com> Igor, You need to fix comment since there is no end_set now. Otherwise look good. Please, run hotspot jtreg tests and CTW. Thanks, Vladimir On 10/10/13 2:56 PM, Igor Veresov wrote: > Thanks for the review! > > On Oct 9, 2013, at 10:57 PM, Vladimir Kozlov wrote: > >> + // Find if any path from start_mem to any node is end_set has side effects. >> typo ^ is -> in >> > yup > >> Can you use set() method instead visited <<= start_mem->_idx? It is the same but more easy to understand. >> > > ok, and I've also added remove() to VectorSet for symmetry. > >> General note. Instead of checking memory between all possible combinations of append calls can you check only between final call toString and first call to StringBuffer? It should cover all. > > ok > >> >> I think in product VM you can bailout immideately when you see store and loadstore. >> > > That's a good point, added that. I moved the path printing for debugging in that branch as well - I'm not quite comfortable having different logic in debug in product. So the path printout is going to terminate with the found side effect node (store or loadstore). > >> Instead of next_edge + path you can use Node_Stack class specifically designed for such cases. >> See example in PhaseCFG::schedule_early(). >> > > That's really useful! I haven't noticed that data structure. Refactored the code to use it. > >> I think you need to assert assert for nodes you skip - closing } should be } else { assert() } to make sure you did not miss some nodes which affect memory. >> > > ok > > I've updated the webrev in-place: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ > > > igor > >> thanks, >> Vladimir >> >> On 10/9/13 7:39 PM, Igor Veresov wrote: >>> I've update the code a bit. I decided to share the arrays I use for traversal between the calls to path_has_side_effects(). >>> >>> On Oct 9, 2013, at 3:11 PM, Igor Veresov wrote: >>> >>>> String concat optimization optimization collapses the pattern >>>> >>>> StringBuffer x = new StringBuffer(); >>>> x.append(y); >>>> x.append(z); >>>> x.toString(); >>>> >>>> into a single allocation of a string and forming the result directly. All possible deopts that may happen in the optimized code restart this pattern from the beginning (starting from the StringBuffer allocation). That means that the whole pattern must me side-effect free. Existing code verifies that the pattern is sound from the control flow point of view, but omits the memory flow verification. This leaves a possibility for a computation on an argument of append() to have side effects. The fix adds memory flow analysis to find the possibly offending stores. We iterate up the memory graph (doing DFS) finding all possible simple paths starting from an append call, until we see the next append call, or a StringBuffer constructor. Then we analyze the path to see if it contains side effects. The analysis is exponential, so we limit the number of iterations. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ >>>> >>>> Testing: eyeballing the graph, the failing tests, jprt >>>> >>>> igor >>> > From christian.thalinger at oracle.com Thu Oct 10 16:03:22 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Oct 2013 16:03:22 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> Message-ID: <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> src/share/vm/opto/stringopts.cpp: + // No interesing paths Typo. Otherwise this looks good. On Oct 10, 2013, at 2:56 PM, Igor Veresov wrote: > Thanks for the review! > > On Oct 9, 2013, at 10:57 PM, Vladimir Kozlov wrote: > >> + // Find if any path from start_mem to any node is end_set has side effects. >> typo ^ is -> in >> > yup > >> Can you use set() method instead visited <<= start_mem->_idx? It is the same but more easy to understand. >> > > ok, and I've also added remove() to VectorSet for symmetry. > >> General note. Instead of checking memory between all possible combinations of append calls can you check only between final call toString and first call to StringBuffer? It should cover all. > > ok > >> >> I think in product VM you can bailout immideately when you see store and loadstore. >> > > That's a good point, added that. I moved the path printing for debugging in that branch as well - I'm not quite comfortable having different logic in debug in product. So the path printout is going to terminate with the found side effect node (store or loadstore). > >> Instead of next_edge + path you can use Node_Stack class specifically designed for such cases. >> See example in PhaseCFG::schedule_early(). >> > > That's really useful! I haven't noticed that data structure. Refactored the code to use it. > >> I think you need to assert assert for nodes you skip - closing } should be } else { assert() } to make sure you did not miss some nodes which affect memory. >> > > ok > > I've updated the webrev in-place: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ > > > igor > >> thanks, >> Vladimir >> >> On 10/9/13 7:39 PM, Igor Veresov wrote: >>> I've update the code a bit. I decided to share the arrays I use for traversal between the calls to path_has_side_effects(). >>> >>> On Oct 9, 2013, at 3:11 PM, Igor Veresov wrote: >>> >>>> String concat optimization optimization collapses the pattern >>>> >>>> StringBuffer x = new StringBuffer(); >>>> x.append(y); >>>> x.append(z); >>>> x.toString(); >>>> >>>> into a single allocation of a string and forming the result directly. All possible deopts that may happen in the optimized code restart this pattern from the beginning (starting from the StringBuffer allocation). That means that the whole pattern must me side-effect free. Existing code verifies that the pattern is sound from the control flow point of view, but omits the memory flow verification. This leaves a possibility for a computation on an argument of append() to have side effects. The fix adds memory flow analysis to find the possibly offending stores. We iterate up the memory graph (doing DFS) finding all possible simple paths starting from an append call, until we see the next append call, or a StringBuffer constructor. Then we analyze the path to see if it contains side effects. The analysis is exponential, so we limit the number of iterations. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev/ >>>> >>>> Testing: eyeballing the graph, the failing tests, jprt >>>> >>>> igor >>> > From roland.westrelin at oracle.com Thu Oct 10 14:58:56 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 10 Oct 2013 21:58:56 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8023657: New type profiling points: arguments to call Message-ID: <20131010215926.9E6F462F41@hg.openjdk.java.net> Changeset: d13d7aba8c12 Author: roland Date: 2013-10-09 16:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d13d7aba8c12 8023657: New type profiling points: arguments to call Summary: x86 interpreter and c1 type profiling for arguments at calls Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciKlass.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObjArrayKlass.hpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeArrayKlass.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp From vladimir.kozlov at oracle.com Thu Oct 10 17:13:02 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 17:13:02 -0700 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: References: <525456AF.7050602@oracle.com> <52565AA6.1010000@oracle.com> Message-ID: <5257428E.4090805@oracle.com> Thank you, Tobias I missed that code in *ThresholdPolicy.cpp files. It was clever hidden :) and your description of changes did not mentioned it. It looks fine but lets keep current code for now since we will need to rework it anyway when you do moving boundary. > I still think that it would be better to disable compilation for > CodeHeaps individually (as this was done implicitly by my > implementation), because we could still compile into the other heap. > Maybe this can be introduced in a future patch. Yes, I agree with you. You need to place "while (next == NULL" between next lines: _seen++; ! _current_nmethod = next; otherwise you will pass incorrect _current_type to process_nmethod(). > Done (names were already changed in the last webrev). I see next names which I was referenced: "Tier 1 and tier 4 methods" "Tier 2 and tier 3 methods" I would prefer to have names similar to flags: "non-profiling nmethods" "profiling nmethods" "nmethods" is "native methods" which we reference to compiled code. Thanks, Vladimir On 10/10/13 8:36 AM, Tobias Hartmann wrote: > Vladimir, thanks again for the quick review! > > Please find the new webrev at: > http://cr.openjdk.java.net/~anoll/8015774/webrev.02/ > > See comments inline: > > 2013/10/10 Vladimir Kozlov > > > > And you totally removed code in sweeper which enables compilation again. > > This is bad. PSR runs FA in VM environment only with few threads (2) > and with this C2 Compiler threads will continue consume resources > even when there are no space to store produced code. Output will be > stormed by "CodeHeap for %s is full." messages. > > It doesn't even do decay invocation counters because next code is > not executed: > if (!should_compile_new_jobs()) { > CompilationPolicy::policy()->__delay_compilation(method()); > return NULL; > } > > Next code is also not executed. As result you continue do only > partial sweeps when codecache (some heaps) is full: > > 266 if (!CompileBroker::should___compile_new_jobs()) { > 267 // If we have turned off compilations we might as well do > full sweeps > 268 // in order to reach the clean state faster. Otherwise the > sleeping compiler > 269 // threads will slow down sweeping. > 270 _invocations = 1; > 271 } > > > The "CodeHeap for %s is full warning" is printed only once for each > CodeHeap, so in fact we print less warnings than the old implementation > does. > Because we check in the common transition functions of the threshold > policies (SimpleThresholdPolicy::common and > AdvancedThresholdPolicy::common) if the CodeHeap for the next > compilation level is available and remain at the current level if it is > full, the compiler threads do not produce code if a heap is full: > > if (CodeCache::is_full(CodeCache::get_code_blob_type(next_level))) { > // The CodeHeap for next_level is full, stay at current level > return cur_level; > } > > They only consume resources to repeatedly check if the CodeHeap for the > next compilation level is now available. Benchmarking showed that this > does not negatively affect performance. You are right with the not > executed code parts and the partial sweeps. Although this can be adapted > easily I followed your suggestions and reverted the changes. As before, > compilation is now disabled as long as a code heap is full and enabled > after sweeping. > > I still think that it would be better to disable compilation for > CodeHeaps individually (as this was done implicitly by my > implementation), because we could still compile into the other heap. > Maybe this can be introduced in a future patch. > > I agree, this part is still a little bit unclear. This is partly > due to the fact that I'm still not sure how to set the > size of the non method heap. On my machine around 3.5Mb are > sufficient for all benchmarks (debug/product). The jprt > tests seem to need more, that's why it is temporarily set to > 8Mb. I have to evaluate that in more detail. Probably we > can set it depending on build/runtime settings and operating system. > > > [Non]ProfiledCodeHeapSize are already platform specific flags. You > don't need to do anything spacial. > > > Yes, I meant that I still have to figure out the specific values for > each platform. > > One option would be to create a new heap for all blobs needed by > the VM to startup. This heap size can be set to > CodeCacheMinimumUseSpace. All non method blobs created by the > running java application are then put into the non method > heap. > > > CodeCacheMinimumUseSpace is already used to run only Interpreter. > You can't change its meaning. You need to make sure your new code > allow to run with such size. > > I mean: > > size_t non_method_size = ReservedCodeCacheSize - > (ProfiledCodeHeapSize + NonProfiledCodeHeapSize); > > > I implemented it as you suggested. By default NonProfiledCodeHeapSize is > approximately ProfiledCodeHeapSize * 2. I will set the platform specific > default values such that the non_method_size is big enough to run the > interpreter (currently it is set to 4Mb). > > My question was: why you need Profiled heap for C1 and Zero? Because > this is what you get if COMPILER2 is not defined (Client or Zero VM). > > > You are perfectly right. The profiled heap is not needed if COMPILER2 is > not defined. I changed it accordingly. > > I'm not sure if I understood your point correctly. At the moment > we delay compilation for the corresponding compilation > level if a heap is full. In practice (at least for the > benchmarks I run) the second heap then fills up really fast. Your > suggestion to allocate CodeBlobs in another heap somehow > "breaks" the design, because the client of the CodeCache could > then encounter non profiled, e.g. C2 compiled, methods while > iterating over the profiled heap. This is not really a > problem at the moment, since no code relies on the fact that the > non profiled heap _only_ contains C2 methods (as long > as it contains only _methods_). > However, I think that the second suggestion to move the boundary > between the heaps is better. One could then increase > the non profiled heap and decrease the profiled heap size if the > first is full. Over time the non profiled heap would > probably grow, whereas the profiled heap would shrink. > > Because I suspect this to be another big change, I would however > suggest to implement this behavior with a second patch > and first finish the current changes. > > > Agree that it is for an other changes. But you need to design > current layout to allow to do that (move boundary) in a future. > > To move the boundary we have to adapt the VirtualSpace used by the > CodeHeaps to support "expanding into" another VirtualSpace as it is > already implemented in class PSVirtualSpace (::expand_into) used by > parallel scavenge GC. Having this we can define two adjacent > VirtualSpaces for the profiled and non-profiled heaps, one of which > grows high to low, and move the boundary in case one is full. Similar > functionality is implemented in class AdjoiningVirtualSpaces (also used > by the parallel scavenge GC). The current design of the code cache > shouldn't be affected much. > > I will look into this more thoroughly and implement the missing > functionality in VirtualSpace and CodeHeap. > > Whole print code is this: > > + warning("CodeHeap for %s is full. Compilation for these > methods has been delayed.", CodeCache::get_heap_name(code___blob_type)); > > + warning("Try increasing the code cache size using > -XX:ReservedCodeCacheSize="); > > You print specific code code heap name in first message (I agree > with Christian that name are not good). You need to additionally > print corresponding flag in next message because increasing > ReservedCodeCacheSize will not help to NonProfiled heap if you don't > increase NonProfiledCodeHeapSize. > > Done (names were already changed in the last webrev). > > About changes in sweeper.cpp. > I think you accidentally removed collection of freed_memory in > sweep_code_cache(). > > > Right, I reverted that. > > And you can simplify the code (no need for external loop while > (_current_type <=) ) if you move "while (_current_method == NULL > ..." inside inner loop after "_current_nmethod = next". > > > Done. Didn't notice that, thanks for the remark. > > > Regards, > Tobias > > thanks, > Vladimir > > 2013/10/4 Christian Thalinger > >> > > > Some general comments: > > Don't use T1, T2, ? to name the tiers because SPARC > processors are named like this. It's confusing. Use tier 1, > tier 2, ? instead. The compilation policies actually talk > about tier levels... > > > I changed the names of the code heaps and comments accordingly. > > I was hoping that we can have a more loose definition of > the code heaps. So we can easily add more. What this > patch does is a good start but all the hardcoded values and > fields need to go at a later point in time, in my opinion. > > > To improve the adding of new heaps I completely removed the > direct dependencies on code heaps from the serviceability > agent, dtrace and the pstack library, especially the fields > _heap_non_method, _heap_non_profiled and _heap_profiled > fields in the code cache. The GrowableArray* is now > the only field used to reference the code heaps. This > allows adding new heaps to the cache without the need to adapt > references. An exception is the dtrace ustack helper > script (jhelper.d). Because the D language does not allow loops, > one has to define a probe for each code heap. For now, > the script supports up to 5 code heaps, but more can be added by > simply adding new probes to the script (comment in line > 183 in jhelper.d describes this). > > To summarize, if I want to add a new code heap to the cache, all > I have to do is to > - define a new CodeBlobType (and add it to IsMethodPredicate if > it is a method type) > - create the heap in CodeCache::initialize_heaps() and define > default sizes > [- define heap availability in CodeCache::heap_available] > [- define the compilation level -> code blob type translation in > CodeCache::get_code_blob_type] > > The last two steps are optional. CodeBlobs created with the new > CodeBlobType are then allocated in the corresponding heap. > > I'm not completely sure what you mean with "hardcoded" values. > Do you mean the default values for > NonProfiledCodeHeapSize and ProfiledCodeHeapSize? Of course we > could compute them implicitly as 1/3 and 2/3 of the > ReservedCodeCacheSize (as it is now done if the user does not > provide a value), without defining them as VM parameter, > but otherwise we have to define default values for them. > > src/share/vm/code/codeBlob.__hpp: > > +// CodeBlob Types > +// Used in the CodeCache to assign CodeBlobs to different > CodeHeaps > +enum CodeBlobType { > + btMethodNoProfile = 0, // T1 and T4 methods > (including native methods) > + btMethodProfile = 1, // T2 and T3 methods with > profile information > + btNonMethod = 2 // Non-methods like Buffers, > Adapters and Runtime Stubs > +}; > > The bt prefix is already overloaded (e.g. BasicType). > Generally speaking, I never liked the fact that enums don't > have their name as scope. Maybe we can agree on doing > something like this: > > struct CodeBlobType { > enum Enum { > NonMethod = 2 > }; > }; > > void foo() { > int a = CodeBlobType::NonMethod; > int b = (CodeBlobType::Enum) 1; > } > > Or we move to C++11 :-) > > http://www.stroustrup.com/C++__11FAQ.html#enum > > > > Yes, it is probably more clear to include the scope. I followed > your suggestion and changed it to a struct with an > anonymous enum. > > src/share/vm/code/codeCache.__cpp: > > +#define FOR_ALL_HEAPS(index) for (int index = 0; index < > _heaps->length(); ++index) > > I'm one of the people who started to hate macros (for > various reasons). Although I see the point in defining these > I'd rather go without them. Is there a way we can use STL > vectors with our allocators? Or we could write our own > iterator class which iterates either over GrowableArrays in > general or the code heaps in particular. > > > I perfectly agree with you that macros should be used only if > necessary and to improve readability in special cases. I > checked the option of using STL vectors but since the STL is not > used in the code yet and I'm not sure if they can be > used with the hotspot allocators, I think it is better to work > with own iterator classes. I therefore defined the custom > iterator classes GrowableArrayIterator and > GrowableArrayFilterIterator. They implement the STL input > iterator interface > without actually inheriting from it (since #include > seems not to work with solaris). The filter iterator is > used to iterate only over those code heaps satisfying a given > predicate, for example those heaps containing nmethods. > This makes the code a lot more readable and reduces the number > of macros. I think the remaining four macros, namely > FOR_ALL_HEAPS and FOR_ALL_METHOD_HEAPS to iterate over the heaps > and FOR_ALL_BLOBS and FOR_ALL_ALIVE_BLOBS to iterate > over the blobs are justified, because they are simple (only > declaring the iterators) and make the code more readable. > > src/share/vm/memory/heap.hpp: > > + const char* getName() const { return _name; } > > This should either be get_name() or name(). > > I renamed it to name(). > > Thanks! > > Best regards > Tobias > > > On 10/2/13 7:06 AM, Tobias Hartmann wrote: > > Hi, > > please review the following change. > > bug: > https://bugs.openjdk.java.net/____browse/JDK-8015774 > > > > webrev: > http://cr.openjdk.java.net/~____anoll/8015774/webrev.00/ > > > > > > This change implements support for multiple code heaps > in the code > cache. The interface of the code cache was changed > accordingly and > references from other components of the VM were > adapted. This includes > the indirect references from: > - the Serviceability Agent: vmStructs and the Java code > cache interface > (sun.jvm.hotspot.code.____CodeCache) > > - the dtrace ustack helper script (jhelper.d) > - the pstack support library libjvm_db.c > > Currently the code cache contains the following three > code heaps each of > which contains CodeBlobs of a specific type: > - Non-Profiled methods: nmethods that are not profiled, > i.e., those > compiled at tier 1 or 4 and native methods > - Profiled methods: nmethods that are profiled, i.e., > those compiled at > tier 2 or 3 > - Non-methods: Non-methods like Buffers, Adapters and > Runtime Stubs > > By default, 2/3 of the ReservedCodeCacheSize is used > for the > non-profiled heap and 1/3 is used for the profiled > heap. Experiments > with a small code cache size have shown that this > configuration performs > best (see [1]). Sizes can be configured using the > NonProfiledCodeHeapSize and ProfiledCodeHeapSize > parameters. By now the > non-method heap has a fixed size of 8mb. More tests > have to be performed > to determine reasonable default values for different > build and runtime > configurations. It would be also possible to add an > additional heap for > the CodeBlobs needed during VM startup (adapters, > stubs, interpreter, > ...) and use the non-method heap for non-method blobs > allocated during > runtime. > > The main benefit of this allocation is that functions > operating on > nmethods can now be optimized to only iterate over > CodeBlobs on the > nmethod heaps, avoiding a full scan of the code cache > including the > non-methods. Performance evaluation shows that this > results in a great > reduction of the sweeping time. Further it is now > possible to extend the > sweeper to selectively sweep nmethods of different > compilation levels. > Because it is more expensive to recompile a highly > optimized method, it > makes sense to first sweep those compiled at a lower > level. Possible > future optimizations may also include multithreaded > sweeping and > separation of nmethod code and metadata. > > The code was tested using Nashorn + Octane, DaCapo, > SPECJvm2008 and jprt. > > Benchmark results: > - [2] shows the score of the old and new version > running Nashorn with > the Octane benchmark at different code cache sizes (10 > runs each, sizes > < 32mb crash with the old version). An performance > improvement of around > 15% is reached. > - [3] shows the sweep time of the NMethodSweeper during > runs of the > Octane benchmark with different code cache sizes (10 > runs each). The > time is greatly reduced with the new version. > - [4] shows the time ratio (TOld / TNew - 1) of the > DaCapo benchmarks > with a code cache size of 64mb (30 runs with 20 warmups > each). With the > time differences being smaller than the confidence > intervals it is not > possible determine a difference between the two versions. > - Multiple runs of the SPECJvm2008 benchmark with > different code cache > sizes did not show a difference between the two > versions. This is > probably due to the fact that not much code is compiled > at runtime > compared to Nashorn with the Octane benchmark. > > The error bars at each data point show the 95% > confidence interval. > > [1] > https://bugs.openjdk.java.net/____secure/attachment/16372/____OctaneRatio.png > > > > > [2] > https://bugs.openjdk.java.net/____secure/attachment/16374/____OctaneCCSizes_new.png > > > > > [3] > https://bugs.openjdk.java.net/____secure/attachment/16373/____OctaneSweepTime_new.png > > > > > [4] > https://bugs.openjdk.java.net/____secure/attachment/16371/____DaCapoCCSizes_64.png > > > > > > > Thanks and best regards, > > Tobias > > > From christian.thalinger at oracle.com Thu Oct 10 17:48:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Oct 2013 17:48:08 -0700 Subject: RFR (S): 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Message-ID: https://bugs.openjdk.java.net/browse/JDK-8005173 http://cr.openjdk.java.net/~twisti/8005173/webrev.00/ 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: The problem is that we don't clean the current exception oop and pc in OptoRuntime::handle_exception_C_helper before calling out to SharedRuntime::compute_compiled_exc_handler which call load classes and thus execute Java code. The corresponding code for C1 in exception_handler_for_pc_helper does that. Since the assert we are hitting in Runtime1::generate_handle_exception only exists on x86 we should also add it on the other platforms (or SPARC at least). From vladimir.kozlov at oracle.com Thu Oct 10 17:56:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2013 17:56:03 -0700 Subject: RFR (S): 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) In-Reply-To: References: Message-ID: <52574CA3.9030508@oracle.com> Looks good. Thanks, Vadimir On 10/10/13 5:48 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8005173 > http://cr.openjdk.java.net/~twisti/8005173/webrev.00/ > > 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) > Reviewed-by: > > The problem is that we don't clean the current exception oop and pc in OptoRuntime::handle_exception_C_helper before calling out to SharedRuntime::compute_compiled_exc_handler which call load classes and thus execute Java code. > > The corresponding code for C1 in exception_handler_for_pc_helper does that. > > Since the assert we are hitting in Runtime1::generate_handle_exception only exists on x86 we should also add it on the other platforms (or SPARC at least). > From igor.veresov at oracle.com Thu Oct 10 17:57:40 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 10 Oct 2013 17:57:40 -0700 Subject: RFR (S): 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) In-Reply-To: References: Message-ID: <46CBB480-BFA3-4435-B15B-F29817F27F4C@oracle.com> Looks good. igor On Oct 10, 2013, at 5:48 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8005173 > http://cr.openjdk.java.net/~twisti/8005173/webrev.00/ > > 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) > Reviewed-by: > > The problem is that we don't clean the current exception oop and pc in OptoRuntime::handle_exception_C_helper before calling out to SharedRuntime::compute_compiled_exc_handler which call load classes and thus execute Java code. > > The corresponding code for C1 in exception_handler_for_pc_helper does that. > > Since the assert we are hitting in Runtime1::generate_handle_exception only exists on x86 we should also add it on the other platforms (or SPARC at least). > From christian.thalinger at oracle.com Thu Oct 10 18:10:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 10 Oct 2013 18:10:02 -0700 Subject: RFR (S): 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) In-Reply-To: <46CBB480-BFA3-4435-B15B-F29817F27F4C@oracle.com> References: <46CBB480-BFA3-4435-B15B-F29817F27F4C@oracle.com> Message-ID: <3102441E-556E-4968-AEB6-76FE492342EB@oracle.com> Thank you, Igor and Vladimir. On Oct 10, 2013, at 5:57 PM, Igor Veresov wrote: > Looks good. > > igor > > On Oct 10, 2013, at 5:48 PM, Christian Thalinger wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8005173 >> http://cr.openjdk.java.net/~twisti/8005173/webrev.00/ >> >> 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) >> Reviewed-by: >> >> The problem is that we don't clean the current exception oop and pc in OptoRuntime::handle_exception_C_helper before calling out to SharedRuntime::compute_compiled_exc_handler which call load classes and thus execute Java code. >> >> The corresponding code for C1 in exception_handler_for_pc_helper does that. >> >> Since the assert we are hitting in Runtime1::generate_handle_exception only exists on x86 we should also add it on the other platforms (or SPARC at least). >> > From albert.noll at oracle.com Thu Oct 10 21:56:21 2013 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 11 Oct 2013 06:56:21 +0200 Subject: RFR (XXS): 8023191: OSR nmethods should be flushed to free space in CodeCache In-Reply-To: <62020050-D7F2-40A4-9E8C-778165315E01@oracle.com> References: <5254E72C.2050004@oracle.com> <5255908C.1080308@oracle.com> <5255D625.1090609@oracle.com> <5256C912.8010709@oracle.com> <5256F64E.5050108@oracle.com> <52570402.3010900@oracle.com> <62020050-D7F2-40A4-9E8C-778165315E01@oracle.com> Message-ID: <525784F5.90201@oracle.com> Thank you John, now I finally got it. I'll file an RFE as proposed by Vladimir. Best, Albert On 11.10.2013 00:04, John Rose wrote: > To be complete, I am suggesting overloading the existing M::_code field not adding a new one, and not right now. > > -- John (on my iPhone) > > On Oct 10, 2013, at 12:46 PM, Albert Noll wrote: > >> Sure, >> >> I was not aware that this is such a big deal. I'll run more tests and let you know. >> >> Best, >> Albert >> >> On 10.10.2013 20:47, Vladimir Kozlov wrote: >>> Albert, >>> >>> I don't think you should do such refactoring now. Runtime and Embedded will put you on "fire" for adding a field to Method class :) >>> >>> Lets do your original changes only for now. And do more complete solution suggested by John later for jdk9. File RFE. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/10/13 8:34 AM, Albert Noll wrote: >>>> Vladimir, Chris, John, many thanks for your feedback. >>>> >>>> I'll run more tests to show that removing OSR methods in the sweeper is >>>> stable (or not). >>>> So far, I have not run into problems. >>>> >>>> @Chris, maybe you ran into 8024008 when you ran nashorn with a small >>>> code cache size. >>>> >>>> There is one thing I do not understand in the current implementation. >>>> What is the reason >>>> that OSR nmethods are maintained in InstanceKlass and not in Method? >>>> I do not see a reason but maybe I am missing something. >>>> >>>> Another thing I do not understand: When we remove an OSR method from the >>>> list (in InstanceKlass), >>>> we search for the max_comp level of all OSR nmethods of that class and >>>> then set this max_level as >>>> the max_level of the Method. Why would we set max_comp_level of Method X >>>> to max_comp_level of >>>> Method Y? >>>> >>>> I've an updated webrev, which moves the maintaining of the list of OSR >>>> methods from InstanceKlass to >>>> Method. This seems more logical to me. Moving the code to Method, also >>>> fixes the problem (if it is a >>>> problem) mentioned in the previous paragraph. >>>> >>>> Here is the webrev: >>>> http://cr.openjdk.java.net/~anoll/8023191/webrev.01/ >>>> >>>> >>>> Tests are still running but so far everything looks good. >>>> Thanks in advance for your help. >>>> >>>> Best, >>>> Albert >>>> >>>> On 10.10.2013 00:18, Vladimir Kozlov wrote: >>>>> On 10/9/13 10:21 AM, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> Changes are fine but you need more testing. >>>>>> >>>>>> Run full CTW too and all jtreg tests from Hotspot and jdk (run jdk tests >>>>>> with -Xcomp and without it). >>>>>> >>>>>> Also the bug report has link to test (jittest). Can you build and run it >>>>>> too to see if it solves the problem with small codecache? It fills >>>>>> codecache with osr nmethods. >>>>>> >>>>>> It is very delicate matter. There was a reason we did not remove OSR >>>>>> nmethod until corresponding klass is unloaded (yes, deoptimization can >>>>>> make it non-entrant). Unfortunately I don't remember it. May be John >>>>>> know. Non of inline caches are pointing to OSR nmethods since it is >>>>>> called only from Interpreter. There is transition phase at the start of >>>>>> OSR nmethod when it calls runtime to convert interpreter frame to >>>>>> compiled frame. And method has separate field for osr nmethods. >>>>> I think I dig out the answer. >>>>> >>>>> First, the last statement in previous mail is wrong. The method object >>>>> does not have reference to osr nmethods. Each java method can have >>>>> several alive OSR nmethods for different bcis. Instead method's holder >>>>> class has list of all OSR nmethods associated with all methods of this >>>>> class. Each time we do osr lookup we go through this list. >>>>> Since method does not have reference to OSR the original flushing >>>>> (speculative disconnection) could not be implemented for OSR nmethods. >>>>> >>>>> Second. Originally osr nmethod were not cleaned up from codecache. >>>>> Here is the comment and the code in >>>>> nmethod::make_not_entrant_or_zombie() from long time ago: >>>>> >>>>> // Code for an on-stack-replacement nmethod is removed when a class >>>>> gets unloaded. >>>>> // They never become zombie/non-entrant, so the nmethod sweeper will >>>>> never remove >>>>> // them. Instead the entry_bci is set to InvalidOSREntryBci, so the >>>>> osr nmethod >>>>> // will never be used anymore. That the nmethods only gets removed >>>>> when class unloading >>>>> // happens, make life much simpler, since the nmethods are not just >>>>> going to disappear >>>>> // out of the blue. >>>>> if (is_osr_only_method()) { >>>>> if (osr_entry_bci() != InvalidOSREntryBci) { >>>>> // only log this once >>>>> log_state_change(state); >>>>> } >>>>> invalidate_osr_method(); >>>>> return; >>>>> } >>>>> >>>>> This code was changed by Tom for 5057818 4 years ago to allow cleanup >>>>> unused OSR nmethods from codecache: >>>>> >>>>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/032260830071 >>>>> >>>>> Third, I think those changes are not complete. >>>>> nmethod::invalidate_osr_method() should check for _entry_bci == >>>>> InvalidOSREntryBci to avoid lookup through osr list again after >>>>> nmethod change from non_entrant to zombie (invalidate_osr_method() is >>>>> called each time make_not_entrant_or_zombie() is called). May be other >>>>> places. Note, when we process osr nmethod::_code should not be touched >>>>> since it is pointing to normal compiled nmethod which could still be >>>>> alive. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/8/13 10:18 PM, Albert Noll wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could I have a review for this small patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023191 >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8023191/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Problem: OSR methods are not removed from code cache to free space. >>>>>>> Solution: Remove OSR methods from code cache. OSR methods c an be made >>>>>>> not-entrant and are then removed from the code cache >>>>>>> likenon-OSR >>>>>>> methods. Other parts in the code (e.g., >>>>>>> deoptimization.cpp:1547) already make >>>>>>> OSR methods not-entrant. >>>>>>> >>>>>>> Testing: Passed JPRT; I'll also run specjvm and nashorn to see if there >>>>>>> is an impact on performance. >>>>>>> >>>>>>> Many thanks in advance, >>>>>>> Albert From roland.westrelin at oracle.com Fri Oct 11 01:32:06 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 11 Oct 2013 10:32:06 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <5E3AFA1B-FA91-4FF1-A73E-45D82FBDF8F2@oracle.com> Message-ID: <92F5D03F-4BD1-4D43-B686-E77C4068F380@oracle.com> Hi Chris, >>> + ciTypeEntriesAtCall* args_and_ret = data->is_CallTypeData() ? ((ciCallTypeData*)data)->args_and_ret() : ((ciVirtualCallTypeData*)data)->args_and_ret(); >>> >>> ! const TypeEntriesAtCall* args_and_ret() const { return &_args_and_ret; } >>> >>> I should've mentioned this in the previous review but can't we make args_and_ret() a virtual method? >> >> In what class? ProfileData? > > I don't know; I've lost track of the class hierarchy. If the class hierarchy is sane there must be a super class that's suitable. > >> Wouldn't that expose some implementation details at a level where they don't make much sense. Also on ci* side, there's no common root class and we probably don't want ci* stuff to leak in methodData.hpp. > > Why isn't there a common super class in ci? The common class in ci is ProfileData. There are places where I test: data->is_CallTypeData() || data->is_VirtualCallTypeData() to find out whether type profiling is on. This one I could replace with a virtual method in ProfileData. is_profiling_types_at_call() maybe. Other candidates are: has_return() number_of_arguments() args_data_offset() What would they become if they were virtual methods in ProfileData? at_call_and_has_return()? has_return() doesn't make any sense in ProfileData because it is the common class for all profiling. There is no common class for calls. And then what about these: args() which returns a ciTypeStackSlotEntries* ret() which returns a ciReturnTypeEntry* They would need to be virtual in ProfileData but return objects from ci? That doesn't seem right. Or we could add static methods to TypeEntriesAtCall and hide the tests there: static bool has_return(ProfileData* data) { assert(data->is_profiling_types_at_call(), ""); return data->is_CallTypeData() ? ((ciCallTypeData*)data)->has_return() : ((ciVirtualCallTypeData*)data)->has_return(); } has_return() makes sense in the context of TypeEntriesAtCall. I don't think it does in ProfileData. Roland. From rickard.backman at oracle.com Fri Oct 11 04:04:58 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 11 Oct 2013 13:04:58 +0200 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <52530BFC.9040201@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> Message-ID: <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> Vladimir, Setting the control edge for addExact and then setting the control edge for everyone who depends on the result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: add rax, rdx jo ?. add rax, rax for java code: result = addExact(x, y) result += addExact(x, y) Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ Thanks /R On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: > Rickard, > > Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. > Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? > > Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? > > addExact(x,y) > addExact(x,y) > > Thanks, > Vladimir > > On 10/6/13 10:13 PM, Rickard B?ckman wrote: >> Vladimir, >> >> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >> uses of addExact this seems to be problematic. >> >> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >> >> Thank you >> /R >> >> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >> >>> Rickard, >>> >>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>> >>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>> >>> Vladimir >>> >>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>> Hi all, >>>> >>>> I would appreciate some reviews on this change. >>>> >>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>> assert(idx >= 0) failed: index should be set >>>> >>>> It seems that gcm would put the addExact in a different block then the jump. >>>> This change forces the producer of FlagsProjNode to be in the same block as >>>> the consumer. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>> >>>> Thanks >>>> /R >>>> >> From niclas.adlertz at oracle.com Fri Oct 11 04:21:25 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Fri, 11 Oct 2013 13:21:25 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> Message-ID: <5257DF35.6030904@oracle.com> Good catch :) Thanks Christian. I'll push this now. http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev03/ Kind Regards, Niclas Adlertz On 2013-10-11 00:03, Christian Thalinger wrote: > + static const uint LRG_All_STACK_SIZE = 0xFFFFF; // This mask size is used to tell that the mask of this LRG supports stack positions > > It looks odd to mix upper and lower case here. You tried to make it look like a macro but you didn't quite make it :-) > > Suggest since it's not a macro and it's a LRG class member to either use: > > static const uint AllStack_size = 0xFFFFF; > > or: > > static const uint ALL_STACK_SIZE = 0xFFFFF; > > I'd vote for the former. > > On Oct 10, 2013, at 7:07 AM, Niclas Adlertz wrote: > >> Hi Roland, >> >>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >> There's nothing wrong about _eff_degree being bigger than LRG_All_STACK_SIZE as long as we don't have a mask supporting stack locations, but you are right that we could add asserts when setting _eff_degree or adding to _eff_degree when the mask supports stack positions. >> >>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >> That might be a good idea, I just followed the old standard. >> >> Thanks. >> >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ >> >> Kind Regards, >> Niclas Adlertz >> >> On 2013-10-10 14:41, Roland Westrelin wrote: >>>> When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes bigger than 65535. >>> >>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >>> >>> Roland. >>> >> > From niclas.adlertz at oracle.com Fri Oct 11 04:23:44 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Fri, 11 Oct 2013 13:23:44 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <26F473C8-6759-403E-A1A4-E190E91E0CA0@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> <26F473C8-6759-403E-A1A4-E190E91E0CA0@oracle.com> Message-ID: <5257DFC0.2090800@oracle.com> Thank you Roland. Kind Regards, Niclas Adlertz On 2013-10-10 19:50, Roland Westrelin wrote: >> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ > > That looks ok to me. > > Roland. > From rickard.backman at oracle.com Fri Oct 11 04:53:49 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 11 Oct 2013 13:53:49 +0200 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> Message-ID: <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> Forgot to include a new test case. Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ /R On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: > Vladimir, > > Setting the control edge for addExact and then setting the control edge for everyone who depends on the > result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. > > GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: > > add rax, rdx > jo ?. > add rax, rax > > for java code: > > result = addExact(x, y) > result += addExact(x, y) > > Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ > > Thanks > /R > > On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: > >> Rickard, >> >> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >> >> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >> >> addExact(x,y) >> addExact(x,y) >> >> Thanks, >> Vladimir >> >> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>> Vladimir, >>> >>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>> uses of addExact this seems to be problematic. >>> >>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>> >>> Thank you >>> /R >>> >>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>> >>>> Rickard, >>>> >>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>> >>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>> >>>> Vladimir >>>> >>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>> Hi all, >>>>> >>>>> I would appreciate some reviews on this change. >>>>> >>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>> assert(idx >= 0) failed: index should be set >>>>> >>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>> the consumer. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>> >>>>> Thanks >>>>> /R >>>>> >>> > From rickard.backman at oracle.com Fri Oct 11 05:53:34 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 11 Oct 2013 14:53:34 +0200 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> Message-ID: <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> And someone pointed out that I don't need to have Verify.java in @compile. Updated: http://cr.openjdk.java.net/~rbackman/8025657.4/ Thanks /R On Oct 11, 2013, at 1:53 PM, Rickard B?ckman wrote: > Forgot to include a new test case. > > Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ > > /R > > On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: > >> Vladimir, >> >> Setting the control edge for addExact and then setting the control edge for everyone who depends on the >> result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. >> >> GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: >> >> add rax, rdx >> jo ?. >> add rax, rax >> >> for java code: >> >> result = addExact(x, y) >> result += addExact(x, y) >> >> Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ >> >> Thanks >> /R >> >> On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: >> >>> Rickard, >>> >>> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >>> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >>> >>> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >>> >>> addExact(x,y) >>> addExact(x,y) >>> >>> Thanks, >>> Vladimir >>> >>> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>>> Vladimir, >>>> >>>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>>> uses of addExact this seems to be problematic. >>>> >>>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>>> >>>> Thank you >>>> /R >>>> >>>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>>> >>>>> Rickard, >>>>> >>>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>>> >>>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>>> >>>>> Vladimir >>>>> >>>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>>> Hi all, >>>>>> >>>>>> I would appreciate some reviews on this change. >>>>>> >>>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>>> assert(idx >= 0) failed: index should be set >>>>>> >>>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>>> the consumer. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> >>>> >> > From tobi.hartmann at gmail.com Fri Oct 11 07:00:30 2013 From: tobi.hartmann at gmail.com (Tobias Hartmann) Date: Fri, 11 Oct 2013 16:00:30 +0200 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: <5257428E.4090805@oracle.com> References: <525456AF.7050602@oracle.com> <52565AA6.1010000@oracle.com> <5257428E.4090805@oracle.com> Message-ID: Thanks again for the review. I added a NonMethodCodeHeapSize flag, because it still wasn't clear what to do if the user increases or decreases the default ReservedCodeCacheSize, without specifying the sizes of the heaps individually. Now the default NonMethodCodeHeapSize is used and the remaining size is assigned 1/3 to the profiled heap and 2/3 to the non-profiled heap. Like this, it is more transparent because default values for all three heaps are available and can also be set by the user. I also added value checks to arguments.cpp. Please find the new webrev at: http://cr.openjdk.java.net/~anoll/8015774/webrev.03/ See comments inline: 2013/10/11 Vladimir Kozlov > > > You need to place "while (next == NULL" between next lines: > > _seen++; > ! _current_nmethod = next; > > otherwise you will pass incorrect _current_type to process_nmethod(). Done. I would prefer to have names similar to flags: > > "non-profiling nmethods" > "profiling nmethods" I changed the names to "Non-profiled nmethods" and "Profiled nmethods". Regards, Tobias > On 10/10/13 8:36 AM, Tobias Hartmann wrote: > >> Vladimir, thanks again for the quick review! >> >> Please find the new webrev at: >> http://cr.openjdk.java.net/~**anoll/8015774/webrev.02/ >> >> See comments inline: >> >> 2013/10/10 Vladimir Kozlov > >> >> >> >> >> And you totally removed code in sweeper which enables compilation >> again. >> >> This is bad. PSR runs FA in VM environment only with few threads (2) >> and with this C2 Compiler threads will continue consume resources >> even when there are no space to store produced code. Output will be >> stormed by "CodeHeap for %s is full." messages. >> >> It doesn't even do decay invocation counters because next code is >> not executed: >> if (!should_compile_new_jobs()) { >> CompilationPolicy::policy()->_**_delay_compilation(method()); >> >> return NULL; >> } >> >> Next code is also not executed. As result you continue do only >> partial sweeps when codecache (some heaps) is full: >> >> 266 if (!CompileBroker::should___**compile_new_jobs()) { >> >> 267 // If we have turned off compilations we might as well do >> full sweeps >> 268 // in order to reach the clean state faster. Otherwise the >> sleeping compiler >> 269 // threads will slow down sweeping. >> 270 _invocations = 1; >> 271 } >> >> >> The "CodeHeap for %s is full warning" is printed only once for each >> CodeHeap, so in fact we print less warnings than the old implementation >> does. >> Because we check in the common transition functions of the threshold >> policies (SimpleThresholdPolicy::common and >> AdvancedThresholdPolicy::**common) if the CodeHeap for the next >> compilation level is available and remain at the current level if it is >> full, the compiler threads do not produce code if a heap is full: >> >> if (CodeCache::is_full(CodeCache:**:get_code_blob_type(next_**level))) { >> // The CodeHeap for next_level is full, stay at current level >> return cur_level; >> } >> >> They only consume resources to repeatedly check if the CodeHeap for the >> next compilation level is now available. Benchmarking showed that this >> does not negatively affect performance. You are right with the not >> executed code parts and the partial sweeps. Although this can be adapted >> easily I followed your suggestions and reverted the changes. As before, >> compilation is now disabled as long as a code heap is full and enabled >> after sweeping. >> >> I still think that it would be better to disable compilation for >> CodeHeaps individually (as this was done implicitly by my >> implementation), because we could still compile into the other heap. >> Maybe this can be introduced in a future patch. >> >> I agree, this part is still a little bit unclear. This is partly >> due to the fact that I'm still not sure how to set the >> size of the non method heap. On my machine around 3.5Mb are >> sufficient for all benchmarks (debug/product). The jprt >> tests seem to need more, that's why it is temporarily set to >> 8Mb. I have to evaluate that in more detail. Probably we >> can set it depending on build/runtime settings and operating >> system. >> >> >> [Non]ProfiledCodeHeapSize are already platform specific flags. You >> don't need to do anything spacial. >> >> >> Yes, I meant that I still have to figure out the specific values for >> each platform. >> >> One option would be to create a new heap for all blobs needed by >> the VM to startup. This heap size can be set to >> CodeCacheMinimumUseSpace. All non method blobs created by the >> running java application are then put into the non method >> heap. >> >> >> CodeCacheMinimumUseSpace is already used to run only Interpreter. >> You can't change its meaning. You need to make sure your new code >> allow to run with such size. >> >> I mean: >> >> size_t non_method_size = ReservedCodeCacheSize - >> (ProfiledCodeHeapSize + NonProfiledCodeHeapSize); >> >> >> I implemented it as you suggested. By default NonProfiledCodeHeapSize is >> approximately ProfiledCodeHeapSize * 2. I will set the platform specific >> default values such that the non_method_size is big enough to run the >> interpreter (currently it is set to 4Mb). >> >> My question was: why you need Profiled heap for C1 and Zero? Because >> this is what you get if COMPILER2 is not defined (Client or Zero VM). >> >> >> You are perfectly right. The profiled heap is not needed if COMPILER2 is >> not defined. I changed it accordingly. >> >> I'm not sure if I understood your point correctly. At the moment >> we delay compilation for the corresponding compilation >> level if a heap is full. In practice (at least for the >> benchmarks I run) the second heap then fills up really fast. Your >> suggestion to allocate CodeBlobs in another heap somehow >> "breaks" the design, because the client of the CodeCache could >> then encounter non profiled, e.g. C2 compiled, methods while >> iterating over the profiled heap. This is not really a >> problem at the moment, since no code relies on the fact that the >> non profiled heap _only_ contains C2 methods (as long >> as it contains only _methods_). >> However, I think that the second suggestion to move the boundary >> between the heaps is better. One could then increase >> the non profiled heap and decrease the profiled heap size if the >> first is full. Over time the non profiled heap would >> probably grow, whereas the profiled heap would shrink. >> >> Because I suspect this to be another big change, I would however >> suggest to implement this behavior with a second patch >> and first finish the current changes. >> >> >> Agree that it is for an other changes. But you need to design >> current layout to allow to do that (move boundary) in a future. >> >> To move the boundary we have to adapt the VirtualSpace used by the >> CodeHeaps to support "expanding into" another VirtualSpace as it is >> already implemented in class PSVirtualSpace (::expand_into) used by >> parallel scavenge GC. Having this we can define two adjacent >> VirtualSpaces for the profiled and non-profiled heaps, one of which >> grows high to low, and move the boundary in case one is full. Similar >> functionality is implemented in class AdjoiningVirtualSpaces (also used >> by the parallel scavenge GC). The current design of the code cache >> shouldn't be affected much. >> >> I will look into this more thoroughly and implement the missing >> functionality in VirtualSpace and CodeHeap. >> >> Whole print code is this: >> >> + warning("CodeHeap for %s is full. Compilation for these >> methods has been delayed.", CodeCache::get_heap_name(code_** >> __blob_type)); >> >> >> + warning("Try increasing the code cache size using >> -XX:ReservedCodeCacheSize="); >> >> You print specific code code heap name in first message (I agree >> with Christian that name are not good). You need to additionally >> print corresponding flag in next message because increasing >> ReservedCodeCacheSize will not help to NonProfiled heap if you don't >> increase NonProfiledCodeHeapSize. >> >> Done (names were already changed in the last webrev). >> >> About changes in sweeper.cpp. >> I think you accidentally removed collection of freed_memory in >> sweep_code_cache(). >> >> >> Right, I reverted that. >> >> And you can simplify the code (no need for external loop while >> (_current_type <=) ) if you move "while (_current_method == NULL >> ..." inside inner loop after "_current_nmethod = next". >> >> >> Done. Didn't notice that, thanks for the remark. >> >> >> Regards, >> Tobias >> >> thanks, >> Vladimir >> >> 2013/10/4 Christian Thalinger > >> > >> >> >> >> >>> >> >> >> Some general comments: >> >> Don't use T1, T2, ? to name the tiers because SPARC >> processors are named like this. It's confusing. Use tier 1, >> tier 2, ? instead. The compilation policies actually talk >> about tier levels... >> >> >> I changed the names of the code heaps and comments accordingly. >> >> I was hoping that we can have a more loose definition of >> the code heaps. So we can easily add more. What this >> patch does is a good start but all the hardcoded values and >> fields need to go at a later point in time, in my opinion. >> >> >> To improve the adding of new heaps I completely removed the >> direct dependencies on code heaps from the serviceability >> agent, dtrace and the pstack library, especially the fields >> _heap_non_method, _heap_non_profiled and _heap_profiled >> fields in the code cache. The GrowableArray* is now >> the only field used to reference the code heaps. This >> allows adding new heaps to the cache without the need to adapt >> references. An exception is the dtrace ustack helper >> script (jhelper.d). Because the D language does not allow loops, >> one has to define a probe for each code heap. For now, >> the script supports up to 5 code heaps, but more can be added by >> simply adding new probes to the script (comment in line >> 183 in jhelper.d describes this). >> >> To summarize, if I want to add a new code heap to the cache, all >> I have to do is to >> - define a new CodeBlobType (and add it to IsMethodPredicate if >> it is a method type) >> - create the heap in CodeCache::initialize_heaps() and define >> default sizes >> [- define heap availability in CodeCache::heap_available] >> [- define the compilation level -> code blob type translation in >> CodeCache::get_code_blob_type] >> >> The last two steps are optional. CodeBlobs created with the new >> CodeBlobType are then allocated in the corresponding heap. >> >> I'm not completely sure what you mean with "hardcoded" values. >> Do you mean the default values for >> NonProfiledCodeHeapSize and ProfiledCodeHeapSize? Of course we >> could compute them implicitly as 1/3 and 2/3 of the >> ReservedCodeCacheSize (as it is now done if the user does not >> provide a value), without defining them as VM parameter, >> but otherwise we have to define default values for them. >> >> src/share/vm/code/codeBlob.__**hpp: >> >> >> +// CodeBlob Types >> +// Used in the CodeCache to assign CodeBlobs to different >> CodeHeaps >> +enum CodeBlobType { >> + btMethodNoProfile = 0, // T1 and T4 methods >> (including native methods) >> + btMethodProfile = 1, // T2 and T3 methods with >> profile information >> + btNonMethod = 2 // Non-methods like Buffers, >> Adapters and Runtime Stubs >> +}; >> >> The bt prefix is already overloaded (e.g. BasicType). >> Generally speaking, I never liked the fact that enums don't >> have their name as scope. Maybe we can agree on doing >> something like this: >> >> struct CodeBlobType { >> enum Enum { >> NonMethod = 2 >> }; >> }; >> >> void foo() { >> int a = CodeBlobType::NonMethod; >> int b = (CodeBlobType::Enum) 1; >> } >> >> Or we move to C++11 :-) >> >> http://www.stroustrup.com/C++_**_11FAQ.html#enum >> >> >> > >> >> >> Yes, it is probably more clear to include the scope. I followed >> your suggestion and changed it to a struct with an >> anonymous enum. >> >> src/share/vm/code/codeCache.__**cpp: >> >> >> +#define FOR_ALL_HEAPS(index) for (int index = 0; index < >> _heaps->length(); ++index) >> >> I'm one of the people who started to hate macros (for >> various reasons). Although I see the point in defining these >> I'd rather go without them. Is there a way we can use STL >> vectors with our allocators? Or we could write our own >> iterator class which iterates either over GrowableArrays in >> general or the code heaps in particular. >> >> >> I perfectly agree with you that macros should be used only if >> necessary and to improve readability in special cases. I >> checked the option of using STL vectors but since the STL is not >> used in the code yet and I'm not sure if they can be >> used with the hotspot allocators, I think it is better to work >> with own iterator classes. I therefore defined the custom >> iterator classes GrowableArrayIterator and >> GrowableArrayFilterIterator. They implement the STL input >> iterator interface >> without actually inheriting from it (since #include >> seems not to work with solaris). The filter iterator is >> used to iterate only over those code heaps satisfying a given >> predicate, for example those heaps containing nmethods. >> This makes the code a lot more readable and reduces the number >> of macros. I think the remaining four macros, namely >> FOR_ALL_HEAPS and FOR_ALL_METHOD_HEAPS to iterate over the heaps >> and FOR_ALL_BLOBS and FOR_ALL_ALIVE_BLOBS to iterate >> over the blobs are justified, because they are simple (only >> declaring the iterators) and make the code more readable. >> >> src/share/vm/memory/heap.hpp: >> >> + const char* getName() const { return _name; } >> >> This should either be get_name() or name(). >> >> I renamed it to name(). >> >> Thanks! >> >> Best regards >> Tobias >> >> >> On 10/2/13 7:06 AM, Tobias Hartmann wrote: >> >> Hi, >> >> please review the following change. >> >> bug: >> https://bugs.openjdk.java.net/**____browse/JDK-8015774 >> >> > >> > >> >> >> webrev: >> http://cr.openjdk.java.net/~__**__anoll/8015774/webrev.00/ >> >> > >> >> >> > _anoll/8015774/webrev.00/ >> >> >> >> >> This change implements support for multiple code heaps >> in the code >> cache. The interface of the code cache was changed >> accordingly and >> references from other components of the VM were >> adapted. This includes >> the indirect references from: >> - the Serviceability Agent: vmStructs and the Java code >> cache interface >> (sun.jvm.hotspot.code.____**CodeCache) >> >> >> - the dtrace ustack helper script (jhelper.d) >> - the pstack support library libjvm_db.c >> >> Currently the code cache contains the following three >> code heaps each of >> which contains CodeBlobs of a specific type: >> - Non-Profiled methods: nmethods that are not profiled, >> i.e., those >> compiled at tier 1 or 4 and native methods >> - Profiled methods: nmethods that are profiled, i.e., >> those compiled at >> tier 2 or 3 >> - Non-methods: Non-methods like Buffers, Adapters and >> Runtime Stubs >> >> By default, 2/3 of the ReservedCodeCacheSize is used >> for the >> non-profiled heap and 1/3 is used for the profiled >> heap. Experiments >> with a small code cache size have shown that this >> configuration performs >> best (see [1]). Sizes can be configured using the >> NonProfiledCodeHeapSize and ProfiledCodeHeapSize >> parameters. By now the >> non-method heap has a fixed size of 8mb. More tests >> have to be performed >> to determine reasonable default values for different >> build and runtime >> configurations. It would be also possible to add an >> additional heap for >> the CodeBlobs needed during VM startup (adapters, >> stubs, interpreter, >> ...) and use the non-method heap for non-method blobs >> allocated during >> runtime. >> >> The main benefit of this allocation is that functions >> operating on >> nmethods can now be optimized to only iterate over >> CodeBlobs on the >> nmethod heaps, avoiding a full scan of the code cache >> including the >> non-methods. Performance evaluation shows that this >> results in a great >> reduction of the sweeping time. Further it is now >> possible to extend the >> sweeper to selectively sweep nmethods of different >> compilation levels. >> Because it is more expensive to recompile a highly >> optimized method, it >> makes sense to first sweep those compiled at a lower >> level. Possible >> future optimizations may also include multithreaded >> sweeping and >> separation of nmethod code and metadata. >> >> The code was tested using Nashorn + Octane, DaCapo, >> SPECJvm2008 and jprt. >> >> Benchmark results: >> - [2] shows the score of the old and new version >> running Nashorn with >> the Octane benchmark at different code cache sizes (10 >> runs each, sizes >> < 32mb crash with the old version). An performance >> improvement of around >> 15% is reached. >> - [3] shows the sweep time of the NMethodSweeper during >> runs of the >> Octane benchmark with different code cache sizes (10 >> runs each). The >> time is greatly reduced with the new version. >> - [4] shows the time ratio (TOld / TNew - 1) of the >> DaCapo benchmarks >> with a code cache size of 64mb (30 runs with 20 warmups >> each). With the >> time differences being smaller than the confidence >> intervals it is not >> possible determine a difference between the two versions. >> - Multiple runs of the SPECJvm2008 benchmark with >> different code cache >> sizes did not show a difference between the two >> versions. This is >> probably due to the fact that not much code is compiled >> at runtime >> compared to Nashorn with the Octane benchmark. >> >> The error bars at each data point show the 95% >> confidence interval. >> >> [1] >> https://bugs.openjdk.java.net/**____secure/attachment/16372/__** >> __OctaneRatio.png >> > __OctaneRatio.png >> > >> >> > OctaneRatio.png >> > OctaneRatio.png >> >> >> [2] >> https://bugs.openjdk.java.net/**____secure/attachment/16374/__** >> __OctaneCCSizes_new.png >> > __OctaneCCSizes_new.png >> > >> >> > OctaneCCSizes_new.png >> > OctaneCCSizes_new.png >> >> >> [3] >> https://bugs.openjdk.java.net/**____secure/attachment/16373/__** >> __OctaneSweepTime_new.png >> > __OctaneSweepTime_new.png >> > >> >> > OctaneSweepTime_new.png >> > OctaneSweepTime_new.png >> >> >> [4] >> https://bugs.openjdk.java.net/**____secure/attachment/16371/__** >> __DaCapoCCSizes_64.png >> > __DaCapoCCSizes_64.png >> > >> >> >> > DaCapoCCSizes_64.png >> >> > DaCapoCCSizes_64.png >> >> >> >> Thanks and best regards, >> >> Tobias >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131011/5c483ac2/attachment-0001.html From vladimir.kozlov at oracle.com Fri Oct 11 08:58:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Oct 2013 08:58:17 -0700 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5257DF35.6030904@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> <5257DF35.6030904@oracle.com> Message-ID: <52582019.70105@oracle.com> Good. Thanks, Vladimir On 10/11/13 4:21 AM, Niclas Adlertz wrote: > Good catch :) > Thanks Christian. I'll push this now. > > http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev03/ > > Kind Regards, > Niclas Adlertz > > On 2013-10-11 00:03, Christian Thalinger wrote: >> + static const uint LRG_All_STACK_SIZE = 0xFFFFF; // This mask size is used to tell that the mask of this LRG >> supports stack positions >> >> It looks odd to mix upper and lower case here. You tried to make it look like a macro but you didn't quite make it :-) >> >> Suggest since it's not a macro and it's a LRG class member to either use: >> >> static const uint AllStack_size = 0xFFFFF; >> >> or: >> >> static const uint ALL_STACK_SIZE = 0xFFFFF; >> >> I'd vote for the former. >> >> On Oct 10, 2013, at 7:07 AM, Niclas Adlertz wrote: >> >>> Hi Roland, >>> >>>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root >>>> cause of the problem? >>> There's nothing wrong about _eff_degree being bigger than LRG_All_STACK_SIZE as long as we don't have a mask >>> supporting stack locations, but you are right that we could add asserts when setting _eff_degree or adding to >>> _eff_degree when the mask supports stack positions. >>> >>>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >>> That might be a good idea, I just followed the old standard. >>> >>> Thanks. >>> >>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> On 2013-10-10 14:41, Roland Westrelin wrote: >>>>> When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with >>>>> mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most >>>>> 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes >>>>> bigger than 65535. >>>> >>>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root >>>> cause of the problem? >>>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >>>> >>>> Roland. >>>> >>> >> > From vladimir.kozlov at oracle.com Fri Oct 11 10:30:17 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Oct 2013 10:30:17 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> Message-ID: <525835A9.6010709@oracle.com> Rickard, First about double addExact(). I was worried about FlagsProj will have two users so that flags->unique_out() will throw assert. But it looks like IfNode::Ideal eliminated second IfNode since inputs are the same. So it may be fine and we did not see failures like this in testing. About changes. I think they good. Can you add MathExactNode::iff_node() and use it instead of duplications? Thanks, Vladimir On 10/11/13 5:53 AM, Rickard B?ckman wrote: > And someone pointed out that I don't need to have Verify.java in @compile. > > Updated: http://cr.openjdk.java.net/~rbackman/8025657.4/ > > Thanks > /R > > On Oct 11, 2013, at 1:53 PM, Rickard B?ckman wrote: > >> Forgot to include a new test case. >> >> Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ >> >> /R >> >> On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: >> >>> Vladimir, >>> >>> Setting the control edge for addExact and then setting the control edge for everyone who depends on the >>> result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. >>> >>> GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: >>> >>> add rax, rdx >>> jo ?. >>> add rax, rax >>> >>> for java code: >>> >>> result = addExact(x, y) >>> result += addExact(x, y) >>> >>> Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ >>> >>> Thanks >>> /R >>> >>> On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: >>> >>>> Rickard, >>>> >>>> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >>>> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >>>> >>>> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >>>> >>>> addExact(x,y) >>>> addExact(x,y) >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>>>> Vladimir, >>>>> >>>>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>>>> uses of addExact this seems to be problematic. >>>>> >>>>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>>>> >>>>> Thank you >>>>> /R >>>>> >>>>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Rickard, >>>>>> >>>>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>>>> >>>>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>>>> >>>>>> Vladimir >>>>>> >>>>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I would appreciate some reviews on this change. >>>>>>> >>>>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>>>> assert(idx >= 0) failed: index should be set >>>>>>> >>>>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>>>> the consumer. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>>>> >>>>>>> Thanks >>>>>>> /R >>>>>>> >>>>> >>> >> > From christian.thalinger at oracle.com Fri Oct 11 10:33:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Oct 2013 10:33:38 -0700 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <92F5D03F-4BD1-4D43-B686-E77C4068F380@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <5E3AFA1B-FA91-4FF1-A73E-45D82FBDF8F2@oracle.com> <92F5D03F-4BD1-4D43-B686-E77C4068F380@oracle.com> Message-ID: <7D20645C-990F-4421-BAC3-3089E2ACD3AC@oracle.com> On Oct 11, 2013, at 1:32 AM, Roland Westrelin wrote: > Hi Chris, > >>>> + ciTypeEntriesAtCall* args_and_ret = data->is_CallTypeData() ? ((ciCallTypeData*)data)->args_and_ret() : ((ciVirtualCallTypeData*)data)->args_and_ret(); >>>> >>>> ! const TypeEntriesAtCall* args_and_ret() const { return &_args_and_ret; } >>>> >>>> I should've mentioned this in the previous review but can't we make args_and_ret() a virtual method? >>> >>> In what class? ProfileData? >> >> I don't know; I've lost track of the class hierarchy. If the class hierarchy is sane there must be a super class that's suitable. >> >>> Wouldn't that expose some implementation details at a level where they don't make much sense. Also on ci* side, there's no common root class and we probably don't want ci* stuff to leak in methodData.hpp. >> >> Why isn't there a common super class in ci? > > The common class in ci is ProfileData. > > There are places where I test: > data->is_CallTypeData() || data->is_VirtualCallTypeData() > to find out whether type profiling is on. This one I could replace with a virtual method in ProfileData. is_profiling_types_at_call() maybe. > > Other candidates are: > has_return() > number_of_arguments() > args_data_offset() > > What would they become if they were virtual methods in ProfileData? at_call_and_has_return()? has_return() doesn't make any sense in ProfileData because it is the common class for all profiling. There is no common class for calls. > > And then what about these: > args() which returns a ciTypeStackSlotEntries* > ret() which returns a ciReturnTypeEntry* > > They would need to be virtual in ProfileData but return objects from ci? That doesn't seem right. > > Or we could add static methods to TypeEntriesAtCall and hide the tests there: > > static bool has_return(ProfileData* data) { > assert(data->is_profiling_types_at_call(), ""); > return data->is_CallTypeData() ? ((ciCallTypeData*)data)->has_return() : ((ciVirtualCallTypeData*)data)->has_return(); > } > > has_return() makes sense in the context of TypeEntriesAtCall. I don't think it does in ProfileData. It seems we'd have to redesign the class hierarchy for virtual methods to work. Leave it as it is for now. Maybe we can think about it for 9. > > Roland. From vladimir.kozlov at oracle.com Fri Oct 11 10:38:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Oct 2013 10:38:07 -0700 Subject: RFR (L): 8015774: Add support for multiple code heaps In-Reply-To: References: <525456AF.7050602@oracle.com> <52565AA6.1010000@oracle.com> <5257428E.4090805@oracle.com> Message-ID: <5258377F.1070002@oracle.com> This looks acceptable. Thanks, Vladimir On 10/11/13 7:00 AM, Tobias Hartmann wrote: > Thanks again for the review. > > I added a NonMethodCodeHeapSize flag, because it still wasn't clear what > to do if the user increases or decreases the default > ReservedCodeCacheSize, without specifying the sizes of the heaps > individually. Now the default NonMethodCodeHeapSize is used and the > remaining size is assigned 1/3 to the profiled heap and 2/3 to the > non-profiled heap. Like this, it is more transparent because default > values for all three heaps are available and can also be set by the > user. I also added value checks to arguments.cpp. > > Please find the new webrev at: > http://cr.openjdk.java.net/~anoll/8015774/webrev.03/ > > See comments inline: > > 2013/10/11 Vladimir Kozlov > > > > You need to place "while (next == NULL" between next lines: > > _seen++; > ! _current_nmethod = next; > > otherwise you will pass incorrect _current_type to process_nmethod(). > > Done. > > I would prefer to have names similar to flags: > > "non-profiling nmethods" > "profiling nmethods" > > > I changed the names to "Non-profiled nmethods" and "Profiled nmethods". > > Regards, > Tobias > > > On 10/10/13 8:36 AM, Tobias Hartmann wrote: > > Vladimir, thanks again for the quick review! > > Please find the new webrev at: > http://cr.openjdk.java.net/~__anoll/8015774/webrev.02/ > > > See comments inline: > > 2013/10/10 Vladimir Kozlov > >> > > > > And you totally removed code in sweeper which enables > compilation again. > > This is bad. PSR runs FA in VM environment only with few > threads (2) > and with this C2 Compiler threads will continue consume > resources > even when there are no space to store produced code. Output > will be > stormed by "CodeHeap for %s is full." messages. > > It doesn't even do decay invocation counters because next > code is > not executed: > if (!should_compile_new_jobs()) { > > CompilationPolicy::policy()->____delay_compilation(method()); > > return NULL; > } > > Next code is also not executed. As result you continue do only > partial sweeps when codecache (some heaps) is full: > > 266 if (!CompileBroker::should_____compile_new_jobs()) { > > 267 // If we have turned off compilations we might as > well do > full sweeps > 268 // in order to reach the clean state faster. > Otherwise the > sleeping compiler > 269 // threads will slow down sweeping. > 270 _invocations = 1; > 271 } > > > The "CodeHeap for %s is full warning" is printed only once for each > CodeHeap, so in fact we print less warnings than the old > implementation > does. > Because we check in the common transition functions of the threshold > policies (SimpleThresholdPolicy::common and > AdvancedThresholdPolicy::__common) if the CodeHeap for the next > compilation level is available and remain at the current level > if it is > full, the compiler threads do not produce code if a heap is full: > > if > (CodeCache::is_full(CodeCache:__:get_code_blob_type(next___level))) > { > // The CodeHeap for next_level is full, stay at current level > return cur_level; > } > > They only consume resources to repeatedly check if the CodeHeap > for the > next compilation level is now available. Benchmarking showed > that this > does not negatively affect performance. You are right with the not > executed code parts and the partial sweeps. Although this can be > adapted > easily I followed your suggestions and reverted the changes. As > before, > compilation is now disabled as long as a code heap is full and > enabled > after sweeping. > > I still think that it would be better to disable compilation for > CodeHeaps individually (as this was done implicitly by my > implementation), because we could still compile into the other heap. > Maybe this can be introduced in a future patch. > > I agree, this part is still a little bit unclear. This > is partly > due to the fact that I'm still not sure how to set the > size of the non method heap. On my machine around 3.5Mb are > sufficient for all benchmarks (debug/product). The jprt > tests seem to need more, that's why it is temporarily > set to > 8Mb. I have to evaluate that in more detail. Probably we > can set it depending on build/runtime settings and > operating system. > > > [Non]ProfiledCodeHeapSize are already platform specific > flags. You > don't need to do anything spacial. > > > Yes, I meant that I still have to figure out the specific values for > each platform. > > One option would be to create a new heap for all blobs > needed by > the VM to startup. This heap size can be set to > CodeCacheMinimumUseSpace. All non method blobs created > by the > running java application are then put into the non method > heap. > > > CodeCacheMinimumUseSpace is already used to run only > Interpreter. > You can't change its meaning. You need to make sure your > new code > allow to run with such size. > > I mean: > > size_t non_method_size = ReservedCodeCacheSize - > (ProfiledCodeHeapSize + NonProfiledCodeHeapSize); > > > I implemented it as you suggested. By default > NonProfiledCodeHeapSize is > approximately ProfiledCodeHeapSize * 2. I will set the platform > specific > default values such that the non_method_size is big enough to > run the > interpreter (currently it is set to 4Mb). > > My question was: why you need Profiled heap for C1 and > Zero? Because > this is what you get if COMPILER2 is not defined (Client or > Zero VM). > > > You are perfectly right. The profiled heap is not needed if > COMPILER2 is > not defined. I changed it accordingly. > > I'm not sure if I understood your point correctly. At > the moment > we delay compilation for the corresponding compilation > level if a heap is full. In practice (at least for the > benchmarks I run) the second heap then fills up really > fast. Your > suggestion to allocate CodeBlobs in another heap somehow > "breaks" the design, because the client of the > CodeCache could > then encounter non profiled, e.g. C2 compiled, methods > while > iterating over the profiled heap. This is not really a > problem at the moment, since no code relies on the fact > that the > non profiled heap _only_ contains C2 methods (as long > as it contains only _methods_). > However, I think that the second suggestion to move the > boundary > between the heaps is better. One could then increase > the non profiled heap and decrease the profiled heap > size if the > first is full. Over time the non profiled heap would > probably grow, whereas the profiled heap would shrink. > > Because I suspect this to be another big change, I > would however > suggest to implement this behavior with a second patch > and first finish the current changes. > > > Agree that it is for an other changes. But you need to design > current layout to allow to do that (move boundary) in a future. > > To move the boundary we have to adapt the VirtualSpace used by the > CodeHeaps to support "expanding into" another VirtualSpace as it is > already implemented in class PSVirtualSpace (::expand_into) used by > parallel scavenge GC. Having this we can define two adjacent > VirtualSpaces for the profiled and non-profiled heaps, one of which > grows high to low, and move the boundary in case one is full. > Similar > functionality is implemented in class AdjoiningVirtualSpaces > (also used > by the parallel scavenge GC). The current design of the code cache > shouldn't be affected much. > > I will look into this more thoroughly and implement the missing > functionality in VirtualSpace and CodeHeap. > > Whole print code is this: > > + warning("CodeHeap for %s is full. Compilation for these > methods has been delayed.", > CodeCache::get_heap_name(code_____blob_type)); > > > + warning("Try increasing the code cache size using > -XX:ReservedCodeCacheSize="); > > You print specific code code heap name in first message (I > agree > with Christian that name are not good). You need to > additionally > print corresponding flag in next message because increasing > ReservedCodeCacheSize will not help to NonProfiled heap if > you don't > increase NonProfiledCodeHeapSize. > > Done (names were already changed in the last webrev). > > About changes in sweeper.cpp. > I think you accidentally removed collection of freed_memory in > sweep_code_cache(). > > > Right, I reverted that. > > And you can simplify the code (no need for external loop while > (_current_type <=) ) if you move "while (_current_method == > NULL > ..." inside inner loop after "_current_nmethod = next". > > > Done. Didn't notice that, thanks for the remark. > > > Regards, > Tobias > > thanks, > Vladimir > > 2013/10/4 Christian Thalinger > > > ____oracle.com > > >>> > > > Some general comments: > > Don't use T1, T2, ? to name the tiers because SPARC > processors are named like this. It's confusing. Use > tier 1, > tier 2, ? instead. The compilation policies > actually talk > about tier levels... > > > I changed the names of the code heaps and comments > accordingly. > > I was hoping that we can have a more loose > definition of > the code heaps. So we can easily add more. What this > patch does is a good start but all the hardcoded > values and > fields need to go at a later point in time, in my opinion. > > > To improve the adding of new heaps I completely removed the > direct dependencies on code heaps from the serviceability > agent, dtrace and the pstack library, especially the fields > _heap_non_method, _heap_non_profiled and _heap_profiled > fields in the code cache. The GrowableArray* > is now > the only field used to reference the code heaps. This > allows adding new heaps to the cache without the need > to adapt > references. An exception is the dtrace ustack helper > script (jhelper.d). Because the D language does not > allow loops, > one has to define a probe for each code heap. For now, > the script supports up to 5 code heaps, but more can be > added by > simply adding new probes to the script (comment in line > 183 in jhelper.d describes this). > > To summarize, if I want to add a new code heap to the > cache, all > I have to do is to > - define a new CodeBlobType (and add it to > IsMethodPredicate if > it is a method type) > - create the heap in CodeCache::initialize_heaps() and > define > default sizes > [- define heap availability in CodeCache::heap_available] > [- define the compilation level -> code blob type > translation in > CodeCache::get_code_blob_type] > > The last two steps are optional. CodeBlobs created with > the new > CodeBlobType are then allocated in the corresponding heap. > > I'm not completely sure what you mean with "hardcoded" > values. > Do you mean the default values for > NonProfiledCodeHeapSize and ProfiledCodeHeapSize? Of > course we > could compute them implicitly as 1/3 and 2/3 of the > ReservedCodeCacheSize (as it is now done if the user > does not > provide a value), without defining them as VM parameter, > but otherwise we have to define default values for them. > > src/share/vm/code/codeBlob.____hpp: > > > +// CodeBlob Types > +// Used in the CodeCache to assign CodeBlobs to > different > CodeHeaps > +enum CodeBlobType { > + btMethodNoProfile = 0, // T1 and T4 methods > (including native methods) > + btMethodProfile = 1, // T2 and T3 > methods with > profile information > + btNonMethod = 2 // Non-methods like > Buffers, > Adapters and Runtime Stubs > +}; > > The bt prefix is already overloaded (e.g. BasicType). > Generally speaking, I never liked the fact that enums > don't > have their name as scope. Maybe we can agree on doing > something like this: > > struct CodeBlobType { > enum Enum { > NonMethod = 2 > }; > }; > > void foo() { > int a = CodeBlobType::NonMethod; > int b = (CodeBlobType::Enum) 1; > } > > Or we move to C++11 :-) > > http://www.stroustrup.com/C++____11FAQ.html#enum > > > > > > > Yes, it is probably more clear to include the scope. I > followed > your suggestion and changed it to a struct with an > anonymous enum. > > src/share/vm/code/codeCache.____cpp: > > > +#define FOR_ALL_HEAPS(index) for (int index = 0; > index < > _heaps->length(); ++index) > > I'm one of the people who started to hate macros (for > various reasons). Although I see the point in defining > these > I'd rather go without them. Is there a way we can > use STL > vectors with our allocators? Or we could write our own > iterator class which iterates either over > GrowableArrays in > general or the code heaps in particular. > > > I perfectly agree with you that macros should be used > only if > necessary and to improve readability in special cases. I > checked the option of using STL vectors but since the > STL is not > used in the code yet and I'm not sure if they can be > used with the hotspot allocators, I think it is better > to work > with own iterator classes. I therefore defined the custom > iterator classes GrowableArrayIterator and > GrowableArrayFilterIterator. They implement the STL input > iterator interface > without actually inheriting from it (since #include > > seems not to work with solaris). The filter iterator is > used to iterate only over those code heaps satisfying a > given > predicate, for example those heaps containing nmethods. > This makes the code a lot more readable and reduces the > number > of macros. I think the remaining four macros, namely > FOR_ALL_HEAPS and FOR_ALL_METHOD_HEAPS to iterate over > the heaps > and FOR_ALL_BLOBS and FOR_ALL_ALIVE_BLOBS to iterate > over the blobs are justified, because they are simple (only > declaring the iterators) and make the code more readable. > > src/share/vm/memory/heap.hpp: > > + const char* getName() const { return _name; } > > This should either be get_name() or name(). > > I renamed it to name(). > > Thanks! > > Best regards > Tobias > > > On 10/2/13 7:06 AM, Tobias Hartmann wrote: > > Hi, > > please review the following change. > > bug: > https://bugs.openjdk.java.net/______browse/JDK-8015774 > > > > >> > webrev: > http://cr.openjdk.java.net/~______anoll/8015774/webrev.00/ > > > > > > > > > >> > > This change implements support for multiple > code heaps > in the code > cache. The interface of the code cache was changed > accordingly and > references from other components of the VM were > adapted. This includes > the indirect references from: > - the Serviceability Agent: vmStructs and the > Java code > cache interface > (sun.jvm.hotspot.code.______CodeCache) > > > - the dtrace ustack helper script (jhelper.d) > - the pstack support library libjvm_db.c > > Currently the code cache contains the > following three > code heaps each of > which contains CodeBlobs of a specific type: > - Non-Profiled methods: nmethods that are not > profiled, > i.e., those > compiled at tier 1 or 4 and native methods > - Profiled methods: nmethods that are > profiled, i.e., > those compiled at > tier 2 or 3 > - Non-methods: Non-methods like Buffers, > Adapters and > Runtime Stubs > > By default, 2/3 of the ReservedCodeCacheSize > is used > for the > non-profiled heap and 1/3 is used for the profiled > heap. Experiments > with a small code cache size have shown that this > configuration performs > best (see [1]). Sizes can be configured using the > NonProfiledCodeHeapSize and ProfiledCodeHeapSize > parameters. By now the > non-method heap has a fixed size of 8mb. More > tests > have to be performed > to determine reasonable default values for > different > build and runtime > configurations. It would be also possible to > add an > additional heap for > the CodeBlobs needed during VM startup (adapters, > stubs, interpreter, > ...) and use the non-method heap for > non-method blobs > allocated during > runtime. > > The main benefit of this allocation is that > functions > operating on > nmethods can now be optimized to only iterate over > CodeBlobs on the > nmethod heaps, avoiding a full scan of the > code cache > including the > non-methods. Performance evaluation shows that > this > results in a great > reduction of the sweeping time. Further it is now > possible to extend the > sweeper to selectively sweep nmethods of different > compilation levels. > Because it is more expensive to recompile a highly > optimized method, it > makes sense to first sweep those compiled at a > lower > level. Possible > future optimizations may also include > multithreaded > sweeping and > separation of nmethod code and metadata. > > The code was tested using Nashorn + Octane, > DaCapo, > SPECJvm2008 and jprt. > > Benchmark results: > - [2] shows the score of the old and new version > running Nashorn with > the Octane benchmark at different code cache > sizes (10 > runs each, sizes > < 32mb crash with the old version). An performance > improvement of around > 15% is reached. > - [3] shows the sweep time of the > NMethodSweeper during > runs of the > Octane benchmark with different code cache > sizes (10 > runs each). The > time is greatly reduced with the new version. > - [4] shows the time ratio (TOld / TNew - 1) > of the > DaCapo benchmarks > with a code cache size of 64mb (30 runs with > 20 warmups > each). With the > time differences being smaller than the confidence > intervals it is not > possible determine a difference between the > two versions. > - Multiple runs of the SPECJvm2008 benchmark with > different code cache > sizes did not show a difference between the two > versions. This is > probably due to the fact that not much code is > compiled > at runtime > compared to Nashorn with the Octane benchmark. > > The error bars at each data point show the 95% > confidence interval. > > [1] > https://bugs.openjdk.java.net/______secure/attachment/16372/______OctaneRatio.png > > > > > > > > >> > [2] > https://bugs.openjdk.java.net/______secure/attachment/16374/______OctaneCCSizes_new.png > > > > > > > > >> > [3] > https://bugs.openjdk.java.net/______secure/attachment/16373/______OctaneSweepTime_new.png > > > > > > > > >> > [4] > https://bugs.openjdk.java.net/______secure/attachment/16371/______DaCapoCCSizes_64.png > > > > > > > > > > >> > > Thanks and best regards, > > Tobias > > > > From roland.westrelin at oracle.com Fri Oct 11 10:40:22 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 11 Oct 2013 19:40:22 +0200 Subject: RFR(L) 8026054: New type profiling points: type of return values at calls In-Reply-To: <7D20645C-990F-4421-BAC3-3089E2ACD3AC@oracle.com> References: <6408A42B-61B5-494B-8DD8-CA6C88E11464@oracle.com> <5E3AFA1B-FA91-4FF1-A73E-45D82FBDF8F2@oracle.com> <92F5D03F-4BD1-4D43-B686-E77C4068F380@oracle.com> <7D20645C-990F-4421-BAC3-3089E2ACD3AC@oracle.com> Message-ID: <84AADC40-EB2D-4598-8016-5046F12F2419@oracle.com> > It seems we'd have to redesign the class hierarchy for virtual methods to work. Leave it as it is for now. Maybe we can think about it for 9. Ok. Thanks for looking at this. Roland. From christian.thalinger at oracle.com Fri Oct 11 11:03:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Oct 2013 11:03:25 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <525835A9.6010709@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> <525835A9.6010709@oracle.com> Message-ID: On Oct 11, 2013, at 10:30 AM, Vladimir Kozlov wrote: > Rickard, > > First about double addExact(). I was worried about FlagsProj will have two users so that flags->unique_out() will throw assert. But it looks like IfNode::Ideal eliminated second IfNode since inputs are the same. So it may be fine and we did not see failures like this in testing. > > About changes. I think they good. Can you add MathExactNode::iff_node() and use it instead of duplications? Perhaps also MathExactNode::bool_node() since you need that one too. > > Thanks, > Vladimir > > On 10/11/13 5:53 AM, Rickard B?ckman wrote: >> And someone pointed out that I don't need to have Verify.java in @compile. >> >> Updated: http://cr.openjdk.java.net/~rbackman/8025657.4/ >> >> Thanks >> /R >> >> On Oct 11, 2013, at 1:53 PM, Rickard B?ckman wrote: >> >>> Forgot to include a new test case. >>> >>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ >>> >>> /R >>> >>> On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: >>> >>>> Vladimir, >>>> >>>> Setting the control edge for addExact and then setting the control edge for everyone who depends on the >>>> result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. >>>> >>>> GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: >>>> >>>> add rax, rdx >>>> jo ?. >>>> add rax, rax >>>> >>>> for java code: >>>> >>>> result = addExact(x, y) >>>> result += addExact(x, y) >>>> >>>> Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ >>>> >>>> Thanks >>>> /R >>>> >>>> On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: >>>> >>>>> Rickard, >>>>> >>>>> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >>>>> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >>>>> >>>>> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >>>>> >>>>> addExact(x,y) >>>>> addExact(x,y) >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>>>>> Vladimir, >>>>>> >>>>>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>>>>> uses of addExact this seems to be problematic. >>>>>> >>>>>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>>>>> >>>>>> Thank you >>>>>> /R >>>>>> >>>>>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Rickard, >>>>>>> >>>>>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>>>>> >>>>>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I would appreciate some reviews on this change. >>>>>>>> >>>>>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>>>>> assert(idx >= 0) failed: index should be set >>>>>>>> >>>>>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>>>>> the consumer. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>>>>> >>>>>>>> Thanks >>>>>>>> /R >>>>>>>> >>>>>> >>>> >>> >> From christian.thalinger at oracle.com Fri Oct 11 11:04:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Oct 2013 11:04:38 -0700 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <5257DF35.6030904@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> <5257DF35.6030904@oracle.com> Message-ID: <6F4047B3-D534-4E18-B0A6-9C6F4C1A9F3B@oracle.com> On Oct 11, 2013, at 4:21 AM, Niclas Adlertz wrote: > Good catch :) > Thanks Christian. I'll push this now. You forgot to change the assert message: + assert(!_mask.is_AllStack() || (_mask.is_AllStack() && lo_degree()), "_eff_degree can't be bigger than LRG_All_STACK_SIZE - _num_regs if the mask supports stack registers"); > > http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev03/ > > Kind Regards, > Niclas Adlertz > > On 2013-10-11 00:03, Christian Thalinger wrote: >> + static const uint LRG_All_STACK_SIZE = 0xFFFFF; // This mask size is used to tell that the mask of this LRG supports stack positions >> >> It looks odd to mix upper and lower case here. You tried to make it look like a macro but you didn't quite make it :-) >> >> Suggest since it's not a macro and it's a LRG class member to either use: >> >> static const uint AllStack_size = 0xFFFFF; >> >> or: >> >> static const uint ALL_STACK_SIZE = 0xFFFFF; >> >> I'd vote for the former. >> >> On Oct 10, 2013, at 7:07 AM, Niclas Adlertz wrote: >> >>> Hi Roland, >>> >>>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >>> There's nothing wrong about _eff_degree being bigger than LRG_All_STACK_SIZE as long as we don't have a mask supporting stack locations, but you are right that we could add asserts when setting _eff_degree or adding to _eff_degree when the mask supports stack positions. >>> >>>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >>> That might be a good idea, I just followed the old standard. >>> >>> Thanks. >>> >>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> On 2013-10-10 14:41, Roland Westrelin wrote: >>>>> When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes bigger than 65535. >>>> >>>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >>>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >>>> >>>> Roland. >>>> >>> >> > From christian.thalinger at oracle.com Fri Oct 11 18:23:21 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 12 Oct 2013 01:23:21 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Message-ID: <20131012012327.C418862FC1@hg.openjdk.java.net> Changeset: 8b80b262e501 Author: twisti Date: 2013-10-11 10:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b80b262e501 8005173: assert(false) failed: DEBUG MESSAGE: exception oop must be empty (macroAssembler_x86.cpp:625) Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/thread.hpp From niclas.adlertz at oracle.com Fri Oct 11 19:48:50 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Sat, 12 Oct 2013 02:48:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 3 new changesets Message-ID: <20131012024859.59A9962FCB@hg.openjdk.java.net> Changeset: d8a449d2f5b2 Author: adlertz Date: 2013-10-11 13:10 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d8a449d2f5b2 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: Summary: Increased the LRG AllStack mask size since the previous size was not big enough when compiling huge methods (60k+ nodes) Reviewed-by: kvn, roland, twisti ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/ifg.cpp Changeset: 2348b2726e1d Author: adlertz Date: 2013-10-11 19:16 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2348b2726e1d Merge Changeset: dd2cf1d1248b Author: adlertz Date: 2013-10-12 01:29 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dd2cf1d1248b Merge From david.r.chase at oracle.com Fri Oct 11 21:59:18 2013 From: david.r.chase at oracle.com (David Chase) Date: Sat, 12 Oct 2013 00:59:18 -0400 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump Message-ID: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8026124 This is almost certainly a duplicate of 8025221 . Webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.00/ Problem: Executing this Javascript var path = new java.io.File("/Users/jfdenise").toPath(); path.toString(); caused an assertion failure and crash. Cause was MemberName constructor (JDK side) passing a boolean java.nio.file.Path.equals(java.lang.Object) method reference into CallInfo::CallInfo (Hotspot side). The code did not expect to see an interface-owned reference to an object method (i.e., a vtable reference) and failed an assertion. Fix: detect this case, assert that the method matches the corresponding vtable-indexed method in Object, continue as a virtual dispatch. Testing: failing code now passes jtreg of jdk/lambda java/lang/invoke java/util/stream defmeth ute vm.quick.testlist in progress (A/B testing) jprt of hotspot in progress Is there any good and easy Nashorn testing? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131012/b71e2e2e/signature.asc From christian.thalinger at oracle.com Fri Oct 11 22:56:09 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Oct 2013 22:56:09 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> Message-ID: + } else if (resolved_method -> has_vtable_index()) { + assert(object_resolved_method->name() == resolved_method -> name(), "Method names should match"); + assert(object_resolved_method->signature() == resolved_method -> signature(), "Method signatures should match"); Can you please remove the spaces before and after "->"? On Oct 11, 2013, at 9:59 PM, David Chase wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8026124 > This is almost certainly a duplicate of 8025221 . > > Webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.00/ > > Problem: > Executing this Javascript > > var path = new java.io.File("/Users/jfdenise").toPath(); > path.toString(); > > caused an assertion failure and crash. > Cause was MemberName constructor (JDK side) passing a > > boolean java.nio.file.Path.equals(java.lang.Object) > > method reference into CallInfo::CallInfo (Hotspot side). The > code did not expect to see an interface-owned reference to > an object method (i.e., a vtable reference) and failed an assertion. > > > Fix: detect this case, assert that the method matches the > corresponding vtable-indexed method in Object, continue > as a virtual dispatch. > > Testing: > failing code now passes > jtreg of jdk/lambda java/lang/invoke java/util/stream > defmeth > > ute vm.quick.testlist in progress (A/B testing) > jprt of hotspot in progress > > Is there any good and easy Nashorn testing? > > From christian.thalinger at oracle.com Fri Oct 11 22:59:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 11 Oct 2013 22:59:29 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> Message-ID: On Oct 11, 2013, at 10:56 PM, Christian Thalinger wrote: > + } else if (resolved_method -> has_vtable_index()) { > > + assert(object_resolved_method->name() == resolved_method -> name(), "Method names should match"); > + assert(object_resolved_method->signature() == resolved_method -> signature(), "Method signatures should match"); One more thing: since you were complaining about uninformative assertions can you make them print the names and signatures when they fail? > > Can you please remove the spaces before and after "->"? > > On Oct 11, 2013, at 9:59 PM, David Chase wrote: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8026124 >> This is almost certainly a duplicate of 8025221 . >> >> Webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.00/ >> >> Problem: >> Executing this Javascript >> >> var path = new java.io.File("/Users/jfdenise").toPath(); >> path.toString(); >> >> caused an assertion failure and crash. >> Cause was MemberName constructor (JDK side) passing a >> >> boolean java.nio.file.Path.equals(java.lang.Object) >> >> method reference into CallInfo::CallInfo (Hotspot side). The >> code did not expect to see an interface-owned reference to >> an object method (i.e., a vtable reference) and failed an assertion. >> >> >> Fix: detect this case, assert that the method matches the >> corresponding vtable-indexed method in Object, continue >> as a virtual dispatch. >> >> Testing: >> failing code now passes >> jtreg of jdk/lambda java/lang/invoke java/util/stream >> defmeth >> >> ute vm.quick.testlist in progress (A/B testing) >> jprt of hotspot in progress >> >> Is there any good and easy Nashorn testing? >> >> > From christian.thalinger at oracle.com Sat Oct 12 00:09:44 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 12 Oct 2013 07:09:44 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131012070956.9F64262FD1@hg.openjdk.java.net> Changeset: 469216acdb28 Author: anoll Date: 2013-10-10 15:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/469216acdb28 8023014: CodeSweeperSweepNoFlushTest.java fails with HS crash Summary: Ensure ensure correct initialization of compiler runtime Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_Compiler.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/compiler/abstractCompiler.cpp ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkCompiler.hpp + test/compiler/startup/SmallCodeCacheStartup.java Changeset: ed2c74787eb5 Author: twisti Date: 2013-10-11 19:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ed2c74787eb5 Merge From john.r.rose at oracle.com Sat Oct 12 00:12:39 2013 From: john.r.rose at oracle.com (John Rose) Date: Sat, 12 Oct 2013 00:12:39 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> Message-ID: <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> On Oct 11, 2013, at 9:59 PM, David Chase wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8026124 > This is almost certainly a duplicate of 8025221 . > > Webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.00/ > > Problem: > Executing this Javascript > > var path = new java.io.File("/Users/jfdenise").toPath(); > path.toString(); > > caused an assertion failure and crash. > Cause was MemberName constructor (JDK side) passing a > > boolean java.nio.file.Path.equals(java.lang.Object) > > method reference into CallInfo::CallInfo (Hotspot side). The > code did not expect to see an interface-owned reference to > an object method (i.e., a vtable reference) and failed an assertion. The new check looks good. (Except for the extra spaces around "->" like Chris said.) > Fix: detect this case, assert that the method matches the > corresponding vtable-indexed method in Object, continue > as a virtual dispatch. > > Testing: > failing code now passes > jtreg of jdk/lambda java/lang/invoke java/util/stream > defmeth > > ute vm.quick.testlist in progress (A/B testing) > jprt of hotspot in progress > > Is there any good and easy Nashorn testing? Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? ? John From roland.westrelin at oracle.com Sat Oct 12 05:55:35 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Sat, 12 Oct 2013 12:55:35 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026054: New type profiling points: type of return values at calls Message-ID: <20131012125542.DC6C262FD5@hg.openjdk.java.net> Changeset: ce0cc25bc5e2 Author: roland Date: 2013-10-12 12:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ce0cc25bc5e2 8026054: New type profiling points: type of return values at calls Summary: x86 interpreter and c1 type profiling for return values at calls Reviewed-by: kvn, twisti ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_RangeCheckElimination.hpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp From david.r.chase at oracle.com Sat Oct 12 07:03:40 2013 From: david.r.chase at oracle.com (David Chase) Date: Sat, 12 Oct 2013 10:03:40 -0400 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> Message-ID: On 2013-10-12, at 3:12 AM, John Rose wrote: > > Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? Except that this is in the hotspot hierarchy, so that's the wrong tests. The other problem I have with this is that I don't entirely understand the packaging requirements for test classes shared by several tests in subdirectories -- I have from time to time experienced test harness failures of the form "java.lang.SecurityException: Prohibited package name: java.util.stream" and until I understand the cause, I'm reluctant to stray from what has worked in the past, which is a top-level collection of test classes in a subdirectory. David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131012/984c6ba6/signature-0001.asc From david.r.chase at oracle.com Sat Oct 12 08:35:29 2013 From: david.r.chase at oracle.com (David Chase) Date: Sat, 12 Oct 2013 11:35:29 -0400 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> Message-ID: <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> New webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.01/ Fixed " -> " Made assertions fail more informatively. Tested failure printing (inserted "false && ", recompiled and ran). Added test (uses Javascript from bug report). David On 2013-10-12, at 10:03 AM, David Chase wrote: > > On 2013-10-12, at 3:12 AM, John Rose wrote: >> >> Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? > > Except that this is in the hotspot hierarchy, so that's the wrong tests. > > The other problem I have with this is that I don't entirely understand the packaging requirements for test classes shared by several tests in subdirectories -- I have from time to time experienced test harness failures of the form > "java.lang.SecurityException: Prohibited package name: java.util.stream" > and until I understand the cause, I'm reluctant to stray from what has worked in the past, > which is a top-level collection of test classes in a subdirectory. > > David > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131012/abbbbb51/signature.asc From christian.thalinger at oracle.com Sat Oct 12 09:55:04 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sat, 12 Oct 2013 09:55:04 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> Message-ID: On Oct 12, 2013, at 8:35 AM, David Chase wrote: > New webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.01/ > > Fixed " -> " > Made assertions fail more informatively. Nice. Only a suggestion but since the debug code spans already 8 lines maybe ditch DEBUG_ONLY and use an #ifdef ASSERT around all that stuff. You don't have to do it. Looks good. > Tested failure printing (inserted "false && ", recompiled and ran). > Added test (uses Javascript from bug report). > > David > > > On 2013-10-12, at 10:03 AM, David Chase wrote: > >> >> On 2013-10-12, at 3:12 AM, John Rose wrote: >>> >>> Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? >> >> Except that this is in the hotspot hierarchy, so that's the wrong tests. >> >> The other problem I have with this is that I don't entirely understand the packaging requirements for test classes shared by several tests in subdirectories -- I have from time to time experienced test harness failures of the form >> "java.lang.SecurityException: Prohibited package name: java.util.stream" >> and until I understand the cause, I'm reluctant to stray from what has worked in the past, >> which is a top-level collection of test classes in a subdirectory. >> >> David >> > From vladimir.kozlov at oracle.com Sat Oct 12 10:40:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 12 Oct 2013 10:40:12 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> Message-ID: <5259897C.6090103@oracle.com> On 10/12/13 9:55 AM, Christian Thalinger wrote: > > On Oct 12, 2013, at 8:35 AM, David Chase wrote: > >> New webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.01/ >> >> Fixed " -> " You missed one in condition. >> Made assertions fail more informatively. > > Nice. Only a suggestion but since the debug code spans already 8 lines maybe ditch DEBUG_ONLY and use an #ifdef ASSERT around all that stuff. You don't have to do it. +1 for #ifdef ASSERT You don't need @compile line in the test: * @compile CreatesInterfaceDotEqualsCallInfo.java Thanks, Vladimir > > Looks good. > >> Tested failure printing (inserted "false && ", recompiled and ran). >> Added test (uses Javascript from bug report). >> >> David >> >> >> On 2013-10-12, at 10:03 AM, David Chase wrote: >> >>> >>> On 2013-10-12, at 3:12 AM, John Rose wrote: >>>> >>>> Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? >>> >>> Except that this is in the hotspot hierarchy, so that's the wrong tests. >>> >>> The other problem I have with this is that I don't entirely understand the packaging requirements for test classes shared by several tests in subdirectories -- I have from time to time experienced test harness failures of the form >>> "java.lang.SecurityException: Prohibited package name: java.util.stream" >>> and until I understand the cause, I'm reluctant to stray from what has worked in the past, >>> which is a top-level collection of test classes in a subdirectory. >>> >>> David >>> >> > From david.r.chase at oracle.com Sat Oct 12 14:28:33 2013 From: david.r.chase at oracle.com (David Chase) Date: Sat, 12 Oct 2013 17:28:33 -0400 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: <5259897C.6090103@oracle.com> References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> <5259897C.6090103@oracle.com> Message-ID: Additional fixes applied: http://cr.openjdk.java.net/~drchase/8026124/webrev.02/ On 2013-10-12, at 1:40 PM, Vladimir Kozlov wrote: > On 10/12/13 9:55 AM, Christian Thalinger wrote: >> >> On Oct 12, 2013, at 8:35 AM, David Chase wrote: >> >>> New webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.01/ >>> >>> Fixed " -> " > > You missed one in condition. > >>> Made assertions fail more informatively. >> >> Nice. Only a suggestion but since the debug code spans already 8 lines maybe ditch DEBUG_ONLY and use an #ifdef ASSERT around all that stuff. You don't have to do it. > > +1 for #ifdef ASSERT > > You don't need @compile line in the test: > > * @compile CreatesInterfaceDotEqualsCallInfo.java > > Thanks, > Vladimir > >> >> Looks good. >> >>> Tested failure printing (inserted "false && ", recompiled and ran). >>> Added test (uses Javascript from bug report). >>> >>> David >>> >>> >>> On 2013-10-12, at 10:03 AM, David Chase wrote: >>> >>>> >>>> On 2013-10-12, at 3:12 AM, John Rose wrote: >>>>> >>>>> Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? >>>> >>>> Except that this is in the hotspot hierarchy, so that's the wrong tests. >>>> >>>> The other problem I have with this is that I don't entirely understand the packaging requirements for test classes shared by several tests in subdirectories -- I have from time to time experienced test harness failures of the form >>>> "java.lang.SecurityException: Prohibited package name: java.util.stream" >>>> and until I understand the cause, I'm reluctant to stray from what has worked in the past, >>>> which is a top-level collection of test classes in a subdirectory. >>>> >>>> David >>>> >>> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131012/a8bb6296/signature.asc From roland.westrelin at oracle.com Sat Oct 12 14:31:31 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sat, 12 Oct 2013 23:31:31 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps Message-ID: The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. http://cr.openjdk.java.net/~roland/8024069/webrev.00/ Roland. From vladimir.kozlov at oracle.com Sat Oct 12 21:59:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 12 Oct 2013 21:59:24 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> <5259897C.6090103@oracle.com> Message-ID: <525A28AC.7030507@oracle.com> Good. Vladimir On 10/12/13 2:28 PM, David Chase wrote: > Additional fixes applied: > > http://cr.openjdk.java.net/~drchase/8026124/webrev.02/ > > On 2013-10-12, at 1:40 PM, Vladimir Kozlov wrote: > >> On 10/12/13 9:55 AM, Christian Thalinger wrote: >>> >>> On Oct 12, 2013, at 8:35 AM, David Chase wrote: >>> >>>> New webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.01/ >>>> >>>> Fixed " -> " >> >> You missed one in condition. >> >>>> Made assertions fail more informatively. >>> >>> Nice. Only a suggestion but since the debug code spans already 8 lines maybe ditch DEBUG_ONLY and use an #ifdef ASSERT around all that stuff. You don't have to do it. >> >> +1 for #ifdef ASSERT >> >> You don't need @compile line in the test: >> >> * @compile CreatesInterfaceDotEqualsCallInfo.java >> >> Thanks, >> Vladimir >> >>> >>> Looks good. >>> >>>> Tested failure printing (inserted "false && ", recompiled and ran). >>>> Added test (uses Javascript from bug report). >>>> >>>> David >>>> >>>> >>>> On 2013-10-12, at 10:03 AM, David Chase wrote: >>>> >>>>> >>>>> On 2013-10-12, at 3:12 AM, John Rose wrote: >>>>>> >>>>>> Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? >>>>> >>>>> Except that this is in the hotspot hierarchy, so that's the wrong tests. >>>>> >>>>> The other problem I have with this is that I don't entirely understand the packaging requirements for test classes shared by several tests in subdirectories -- I have from time to time experienced test harness failures of the form >>>>> "java.lang.SecurityException: Prohibited package name: java.util.stream" >>>>> and until I understand the cause, I'm reluctant to stray from what has worked in the past, >>>>> which is a top-level collection of test classes in a subdirectory. >>>>> >>>>> David >>>>> >>>> >>> > From igor.veresov at oracle.com Sun Oct 13 16:08:16 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sun, 13 Oct 2013 23:08:16 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 46 new changesets Message-ID: <20131013230957.19A5462FFA@hg.openjdk.java.net> Changeset: 5b3b75d9eb2f Author: coleenp Date: 2013-10-01 14:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5b3b75d9eb2f 8025570: Naked oop in test/serviceability/ParserTest Summary: Fix for two naked objArrayOop(s) oops causing test failure Reviewed-by: coleenp, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/prims/wbtestmethods/parserTests.cpp Changeset: f21415c32ca1 Author: coleenp Date: 2013-10-01 15:41 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f21415c32ca1 Merge Changeset: d574419c5372 Author: mseledtsov Date: 2013-10-02 15:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d574419c5372 8025671: Test name changed, test list not updated. Test6878713.sh Summary: Removed the obsolete test from the test group file Reviewed-by: sla, ctornqvi, dholmes ! test/TEST.groups Changeset: 931f105563c5 Author: coleenp Date: 2013-10-02 13:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/931f105563c5 8025569: -XX:+CheckUnhandledOops crashes on Windows Summary: Disable CHECK_UNHANDLED_OOPS in fastdebug builds for JDK 8 on WIndows 32 & 64 bit machines Reviewed-by: coleenp, ctornqvi, zgu Contributed-by: lois.foltan at oracle.com ! make/windows/makefiles/fastdebug.make Changeset: 6f73bc5df986 Author: coleenp Date: 2013-10-02 15:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6f73bc5df986 Merge Changeset: 2bd38d594b9a Author: dsamersoff Date: 2013-10-02 20:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2bd38d594b9a 8025283: Nits in os_bsd file breaks compilation of open hotspot Summary: Couple of nits in os_bsd.cpp brake compilation of open hotspot on non-apple platforms Reviewed-by: sla, sspitsyn ! src/os/bsd/vm/os_bsd.cpp Changeset: 9855f17334d8 Author: dsamersoff Date: 2013-10-03 01:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9855f17334d8 Merge Changeset: 5705c7ee6dd7 Author: dsamersoff Date: 2013-10-02 22:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5705c7ee6dd7 8025250: SA: Sync linux and bsd versions of ps_core file Summary: linux/ps_core.c and bsd/ps_core.c share most of code, but it has different formatting, comments etc. Reviewed-by: sla, minqi ! agent/src/os/bsd/ps_core.c ! agent/src/os/linux/ps_core.c Changeset: 7ae82c3a781a Author: dsamersoff Date: 2013-10-03 04:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ae82c3a781a Merge Changeset: faff125a1ead Author: dsamersoff Date: 2013-10-03 12:39 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/faff125a1ead 8022616: u4 should not be used as a type for thread_id Summary: Usage of u4 as a type for thread_id cause a compilation error on platform, where thread_id is a pointer Reviewed-by: sla, sspitsyn, minqi ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp Changeset: 07f8c2a453f8 Author: coleenp Date: 2013-10-03 18:53 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/07f8c2a453f8 8025238: nsk/jvmti/scenarios/bcinstr/BI04/bi04t002 crashed with SIGSEGV Summary: Redefined class in stack trace may not be found by method_idnum so handle null. Reviewed-by: sla, dcubed, sspitsyn ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 3374b92de2d9 Author: coleenp Date: 2013-10-03 18:50 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3374b92de2d9 8025004: -XX:+CheckUnhandledOops asserts for JDK 8 Solaris fastdebug binaries Summary: Remove unnecessary volatile keyword on stack locals within instanceKlass.cpp to work around Solaris Studio C++ compiler issue Reviewed-by: coleenp, dcubed Contributed-by: lois.foltan at oracle.com ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 3bf767171ea4 Author: coleenp Date: 2013-10-05 00:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3bf767171ea4 Merge Changeset: 675ffabf3798 Author: mikael Date: 2013-10-02 09:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/675ffabf3798 8024087: Remove dead JVM_{Get,Set}PrimitiveFieldValues functions Summary: The two functions were used to support JDK 1.3 but are no longer in use Reviewed-by: coleenp, ctornqvi, twisti, dsamersoff ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/nativeLookup.cpp Changeset: a1fd44b003c7 Author: coleenp Date: 2013-10-05 00:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a1fd44b003c7 Merge Changeset: 4212bfb33d76 Author: coleenp Date: 2013-10-05 03:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4212bfb33d76 Merge Changeset: 2720ab7a0d70 Author: ccheung Date: 2013-10-04 21:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2720ab7a0d70 Merge ! src/share/vm/prims/jvm.cpp Changeset: febab3a8f203 Author: erikj Date: 2013-10-04 12:45 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/febab3a8f203 8007446: Add /MP to cl.exe speeds up windows builds of OpenJDK. Reviewed-by: sla, ctornqvi ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: 763705f0fec3 Author: sla Date: 2013-10-04 13:01 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/763705f0fec3 8016845: SA is unable to use hsdis on windows Summary: Added sadis.c to the build to provide missing symbols in sawindbg.dll. Added code to use the correct hsdisXXX.dll filename on different windows platforms. Reviewed-by: sla, mgerdin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java ! make/windows/makefiles/sa.make Changeset: f9be370a7d54 Author: sla Date: 2013-10-05 15:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f9be370a7d54 8025922: JNI access to Strings need to check if the value field is non-null Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp Changeset: 8ef918538e22 Author: sla Date: 2013-10-04 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8ef918538e22 6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" Summary: Adds support for large(>4G) heap dumps in hprof format. Adds tests and updates testlibrary. Reviewed-by: sla, allwin Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! test/TEST.groups + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapProc.java + test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 9c63ad02c0a4 Author: sla Date: 2013-10-05 10:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9c63ad02c0a4 Merge Changeset: cc4f5f8d885e Author: mseledtsov Date: 2013-10-06 16:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cc4f5f8d885e 8023796: [TESTBUG] Add -XX:-TransmitErrorReport to runtime/6888954/vmerrors.sh Summary: added -XX:-TransmitErrorReport to the test Reviewed-by: stefank, ctornqvi ! test/runtime/6888954/vmerrors.sh ! test/runtime/memory/ReserveMemory.java Changeset: ac9cb1d5a202 Author: acorn Date: 2013-10-07 12:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ac9cb1d5a202 8009130: Lambda: Fix access controls, loader constraints. Summary: New default methods list with inherited superinterface methods Reviewed-by: minqi, sspitsyn, coleenp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/reflectionUtils.cpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 615d83933195 Author: dholmes Date: 2013-10-08 02:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/615d83933195 8026025: JVM_GetCallerClass allows Reflection.getCallerClass(int depth) to use Reviewed-by: alanb, dholmes, twisti Contributed-by: mandy.chung at oracle.com ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: c90e76575b03 Author: kevinw Date: 2013-10-08 09:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c90e76575b03 8019375: Internal symbol table size should be tunable. Reviewed-by: coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: ced68a57cdbd Author: kevinw Date: 2013-10-08 11:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ced68a57cdbd Merge Changeset: c72075c2883e Author: acorn Date: 2013-10-08 16:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c72075c2883e 8026022: Verifier: allow anon classes to invokespecial host class/intf methods. Reviewed-by: coleenp, bharadwaj ! src/share/vm/classfile/verifier.cpp Changeset: d25557d03ec0 Author: acorn Date: 2013-10-09 17:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d25557d03ec0 8026185: nsk/jvmit/GetMethodDeclaringClass/declcls001 failed Summary: Missed initialization. Thanks Coleen. Reviewed-by: coleenp, minqi ! src/share/vm/oops/instanceKlass.cpp Changeset: c01f4910f5f5 Author: ccheung Date: 2013-10-10 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c01f4910f5f5 Merge Changeset: 9b4d0569f2f4 Author: jwilhelm Date: 2013-10-03 21:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9b4d0569f2f4 8025852: Remove unnecessary setters in collector policy classes Summary: Use instance variables directly within the collector policy classes and remove unused setters. Reviewed-by: tschatzl, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp Changeset: 087f02e22fc2 Author: jwilhelm Date: 2013-10-04 22:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/087f02e22fc2 8025854: Use "young gen" instead of "eden" Summary: Changed a few descriptions and variable names to young gen. Reviewed-by: tschatzl, jcoomes ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 263f2c796d6c Author: stefank Date: 2013-10-05 10:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/263f2c796d6c 8024838: Significant slowdown due to transparent huge pages Summary: Don't turn on transparent huge pages (-XX:+UseTransparentHugePages) unless explicitly specified on the command line. This has the effect that large pages are never turned on Linux unless the user has explicitly enabled any of the large pages flags: -XX:+UseLargePages, -XX:+UseTransparentHugePages, -XX:+UseHugeTLBFS, and -XX:+UseSHM. Reviewed-by: jwilhelm, tschatzl, brutisso ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp + test/runtime/memory/LargePages/TestLargePagesFlags.java Changeset: 8618e0d7735b Author: stefank Date: 2013-10-05 08:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8618e0d7735b Merge Changeset: 04b18a42c2f3 Author: mgerdin Date: 2013-10-04 13:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/04b18a42c2f3 8025526: VirtualSpace should support per-instance disabling of large pages Summary: Add a new initialization function to VirtualSpace which allows the caller to override the max commit granularity. Reviewed-by: stefank, ehelin, tschatzl ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp Changeset: 69944b868a32 Author: mgerdin Date: 2013-10-08 17:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/69944b868a32 8014555: G1: Memory ordering problem with Conc refinement and card marking Summary: Add a StoreLoad barrier in the G1 post-barrier to fix a race with concurrent refinement. Also-reviewed-by: martin.doerr at sap.com Reviewed-by: iveresov, tschatzl, brutisso, roland, kvn ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/opto/graphKit.cpp Changeset: b4d8a3d4db73 Author: tamao Date: 2013-10-09 11:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b4d8a3d4db73 8010506: Typos and errors in descriptions of vm options in globals.hpp Summary: Fix typos and errors in descriptions of vm options in globals.hpp Reviewed-by: jmasa, jwilhelm ! src/share/vm/runtime/globals.hpp Changeset: 82af7d7a0128 Author: tschatzl Date: 2013-10-09 10:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/82af7d7a0128 8003420: NPG: make new GC root for pd_set Summary: Move protection domain oops from system dictionary entries into a seperate set; the system dictionary references entries in that set now. This allows fast iteration during non-classunloading garbage collection. Implementation based on initial prototype from Ioi Lam (iklam). Reviewed-by: coleenp, iklam + agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 85c1ca43713f Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/85c1ca43713f 8024547: MaxMetaspaceSize should limit the committed memory used by the metaspaces Reviewed-by: brutisso, jmasa, coleenp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: a6414751d537 Author: stefank Date: 2013-10-07 15:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a6414751d537 8025996: Track metaspace usage when metaspace is expanded Reviewed-by: coleenp, ehelin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/services/memoryService.hpp Changeset: aa6f2ea19d8f Author: jcoomes Date: 2013-10-11 08:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aa6f2ea19d8f Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 02d171a3b5d1 Author: cl Date: 2013-10-10 10:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/02d171a3b5d1 Added tag jdk8-b111 for changeset f6962730bbde ! .hgtags Changeset: 4a845c7a4638 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4a845c7a4638 Merge Changeset: 0ed9a90f45e1 Author: amurillo Date: 2013-10-11 13:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0ed9a90f45e1 Added tag hs25-b54 for changeset 4a845c7a4638 ! .hgtags Changeset: 7c26dced065e Author: amurillo Date: 2013-10-11 13:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7c26dced065e 8026265: new hotspot build - hs25-b55 Reviewed-by: jcoomes ! make/hotspot_version Changeset: f50418dfb1b7 Author: iveresov Date: 2013-10-13 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f50418dfb1b7 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh From albert.noll at oracle.com Sun Oct 13 23:23:41 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 14 Oct 2013 08:23:41 +0200 Subject: RFR(XXS): 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice Message-ID: <525B8DED.1080505@oracle.com> Hi, could I get reviews for this small patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8025740 Webrev: http://cr.openjdk.java.net/~anoll/8025740/webrev.00/ problem: 'java -XX:ReservedCodeCacheSize=2049m -version' gives the following output. > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. Solution: Remove duplicate check of ReservedCodeCacheSize from Arguments::check_gc_consistency(). Best, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131014/dbdfc25f/attachment.html From niclas.adlertz at oracle.com Sun Oct 13 23:40:38 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Mon, 14 Oct 2013 08:40:38 +0200 Subject: RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed: In-Reply-To: <6F4047B3-D534-4E18-B0A6-9C6F4C1A9F3B@oracle.com> References: <5255D3DF.4090104@oracle.com> <7AFF95CC-49B0-47B2-ACB9-2041A2A998BC@oracle.com> <5256B4A8.4020302@oracle.com> <5257DF35.6030904@oracle.com> <6F4047B3-D534-4E18-B0A6-9C6F4C1A9F3B@oracle.com> Message-ID: <525B91E6.4030202@oracle.com> Fixed. Thanks. Kind Regards, Niclas Adlertz On 2013-10-11 20:04, Christian Thalinger wrote: > > On Oct 11, 2013, at 4:21 AM, Niclas Adlertz wrote: > >> Good catch :) >> Thanks Christian. I'll push this now. > > You forgot to change the assert message: > > + assert(!_mask.is_AllStack() || (_mask.is_AllStack() && lo_degree()), "_eff_degree can't be bigger than LRG_All_STACK_SIZE - _num_regs if the mask supports stack registers"); > >> >> http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev03/ >> >> Kind Regards, >> Niclas Adlertz >> >> On 2013-10-11 00:03, Christian Thalinger wrote: >>> + static const uint LRG_All_STACK_SIZE = 0xFFFFF; // This mask size is used to tell that the mask of this LRG supports stack positions >>> >>> It looks odd to mix upper and lower case here. You tried to make it look like a macro but you didn't quite make it :-) >>> >>> Suggest since it's not a macro and it's a LRG class member to either use: >>> >>> static const uint AllStack_size = 0xFFFFF; >>> >>> or: >>> >>> static const uint ALL_STACK_SIZE = 0xFFFFF; >>> >>> I'd vote for the former. >>> >>> On Oct 10, 2013, at 7:07 AM, Niclas Adlertz wrote: >>> >>>> Hi Roland, >>>> >>>>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >>>> There's nothing wrong about _eff_degree being bigger than LRG_All_STACK_SIZE as long as we don't have a mask supporting stack locations, but you are right that we could add asserts when setting _eff_degree or adding to _eff_degree when the mask supports stack positions. >>>> >>>>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >>>> That might be a good idea, I just followed the old standard. >>>> >>>> Thanks. >>>> >>>> webrev: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev02/ >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> On 2013-10-10 14:41, Roland Westrelin wrote: >>>>>> When compiling very big methods, in this particular case a method of 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still have lo_degree() == false. This because the _mask_size of 'l' can be at most 65535, at the same time 'l' is interfering with so many other live ranges that the value of _eff_degree becomes bigger than 65535. >>>>> >>>>> Shouldn't we assert somewhere than _eff_degree doesn't become any bigger than LRG_All_STACK_SIZE if that's the root cause of the problem? >>>>> Also, wouldn't a const int LRG_All_STACK_SIZE be better than a macro? >>>>> >>>>> Roland. >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Oct 14 00:14:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 00:14:53 -0700 Subject: RFR(XXS): 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice In-Reply-To: <525B8DED.1080505@oracle.com> References: <525B8DED.1080505@oracle.com> Message-ID: <525B99ED.3020102@oracle.com> Good. Vladimir On 10/13/13 11:23 PM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025740 > Webrev: http://cr.openjdk.java.net/~anoll/8025740/webrev.00/ > > problem: 'java -XX:ReservedCodeCacheSize=2049m -version' gives the following output. > > > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. > > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. > > Solution: Remove duplicate check of ReservedCodeCacheSize from Arguments::check_gc_consistency(). > > > Best, > Albert > From albert.noll at oracle.com Mon Oct 14 00:27:13 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 14 Oct 2013 09:27:13 +0200 Subject: RFR(XXS): 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice In-Reply-To: <525B99ED.3020102@oracle.com> References: <525B8DED.1080505@oracle.com> <525B99ED.3020102@oracle.com> Message-ID: <525B9CD1.7090600@oracle.com> Thank you, Vladimir. Best, Albert On 14.10.2013 09:14, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/13/13 11:23 PM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025740 >> Webrev: http://cr.openjdk.java.net/~anoll/8025740/webrev.00/ >> >> >> problem: 'java -XX:ReservedCodeCacheSize=2049m -version' gives the >> following output. >> >> > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. >> > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. >> >> Solution: Remove duplicate check of ReservedCodeCacheSize from >> Arguments::check_gc_consistency(). >> >> >> Best, >> Albert >> From rickard.backman at oracle.com Mon Oct 14 00:44:25 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Mon, 14 Oct 2013 09:44:25 +0200 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> <525835A9.6010709@oracle.com> Message-ID: <2F63C163-0D4A-4BF3-9F2D-572E6C335537@oracle.com> Christian & Vladimir, I added both: http://cr.openjdk.java.net/~rbackman/8025657.5/webrev/ Thanks /R On Oct 11, 2013, at 8:03 PM, Christian Thalinger wrote: > > On Oct 11, 2013, at 10:30 AM, Vladimir Kozlov wrote: > >> Rickard, >> >> First about double addExact(). I was worried about FlagsProj will have two users so that flags->unique_out() will throw assert. But it looks like IfNode::Ideal eliminated second IfNode since inputs are the same. So it may be fine and we did not see failures like this in testing. >> >> About changes. I think they good. Can you add MathExactNode::iff_node() and use it instead of duplications? > > Perhaps also MathExactNode::bool_node() since you need that one too. > >> >> Thanks, >> Vladimir >> >> On 10/11/13 5:53 AM, Rickard B?ckman wrote: >>> And someone pointed out that I don't need to have Verify.java in @compile. >>> >>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.4/ >>> >>> Thanks >>> /R >>> >>> On Oct 11, 2013, at 1:53 PM, Rickard B?ckman wrote: >>> >>>> Forgot to include a new test case. >>>> >>>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ >>>> >>>> /R >>>> >>>> On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: >>>> >>>>> Vladimir, >>>>> >>>>> Setting the control edge for addExact and then setting the control edge for everyone who depends on the >>>>> result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. >>>>> >>>>> GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: >>>>> >>>>> add rax, rdx >>>>> jo ?. >>>>> add rax, rax >>>>> >>>>> for java code: >>>>> >>>>> result = addExact(x, y) >>>>> result += addExact(x, y) >>>>> >>>>> Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ >>>>> >>>>> Thanks >>>>> /R >>>>> >>>>> On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: >>>>> >>>>>> Rickard, >>>>>> >>>>>> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >>>>>> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >>>>>> >>>>>> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >>>>>> >>>>>> addExact(x,y) >>>>>> addExact(x,y) >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>>>>>> uses of addExact this seems to be problematic. >>>>>>> >>>>>>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>>>>>> >>>>>>> Thank you >>>>>>> /R >>>>>>> >>>>>>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> Rickard, >>>>>>>> >>>>>>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>>>>>> >>>>>>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I would appreciate some reviews on this change. >>>>>>>>> >>>>>>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>>>>>> assert(idx >= 0) failed: index should be set >>>>>>>>> >>>>>>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>>>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>>>>>> the consumer. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> /R >>>>>>>>> >>>>>>> >>>>> >>>> >>> > From roland.westrelin at oracle.com Mon Oct 14 04:59:13 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 Oct 2013 13:59:13 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods Message-ID: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> The last of the series of new type profiling points. http://cr.openjdk.java.net/~roland/8026251/webrev.00/ The output of PrintMethodData is: TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; interpreter_invocation_count: 5000 invocation_counter: 5000 backedge_counter: 0 mdo size: 444 bytes parameter types 0: stack(0) 'TestProfiling' 1: stack(1) 'TestProfiling$A' Roland. From vladimir.kozlov at oracle.com Mon Oct 14 09:15:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 09:15:32 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <2F63C163-0D4A-4BF3-9F2D-572E6C335537@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> <525835A9.6010709@oracle.com> <2F63C163-0D4A-4BF3-9F2D-572E6C335537@oracle.com> Message-ID: <525C18A4.2070906@oracle.com> Looks good. Thanks, Vladimir On 10/14/13 12:44 AM, Rickard B?ckman wrote: > Christian & Vladimir, > > I added both: http://cr.openjdk.java.net/~rbackman/8025657.5/webrev/ > > Thanks > /R > > On Oct 11, 2013, at 8:03 PM, Christian Thalinger wrote: > >> >> On Oct 11, 2013, at 10:30 AM, Vladimir Kozlov wrote: >> >>> Rickard, >>> >>> First about double addExact(). I was worried about FlagsProj will have two users so that flags->unique_out() will throw assert. But it looks like IfNode::Ideal eliminated second IfNode since inputs are the same. So it may be fine and we did not see failures like this in testing. >>> >>> About changes. I think they good. Can you add MathExactNode::iff_node() and use it instead of duplications? >> >> Perhaps also MathExactNode::bool_node() since you need that one too. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/11/13 5:53 AM, Rickard B?ckman wrote: >>>> And someone pointed out that I don't need to have Verify.java in @compile. >>>> >>>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.4/ >>>> >>>> Thanks >>>> /R >>>> >>>> On Oct 11, 2013, at 1:53 PM, Rickard B?ckman wrote: >>>> >>>>> Forgot to include a new test case. >>>>> >>>>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ >>>>> >>>>> /R >>>>> >>>>> On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: >>>>> >>>>>> Vladimir, >>>>>> >>>>>> Setting the control edge for addExact and then setting the control edge for everyone who depends on the >>>>>> result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. >>>>>> >>>>>> GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: >>>>>> >>>>>> add rax, rdx >>>>>> jo ?. >>>>>> add rax, rax >>>>>> >>>>>> for java code: >>>>>> >>>>>> result = addExact(x, y) >>>>>> result += addExact(x, y) >>>>>> >>>>>> Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> >>>>>> On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Rickard, >>>>>>> >>>>>>> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >>>>>>> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >>>>>>> >>>>>>> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >>>>>>> >>>>>>> addExact(x,y) >>>>>>> addExact(x,y) >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>>>>>>> Vladimir, >>>>>>>> >>>>>>>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>>>>>>> uses of addExact this seems to be problematic. >>>>>>>> >>>>>>>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>>>>>>> >>>>>>>> Thank you >>>>>>>> /R >>>>>>>> >>>>>>>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Rickard, >>>>>>>>> >>>>>>>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>>>>>>> >>>>>>>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I would appreciate some reviews on this change. >>>>>>>>>> >>>>>>>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>>>>>>> assert(idx >= 0) failed: index should be set >>>>>>>>>> >>>>>>>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>>>>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>>>>>>> the consumer. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /R >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> > From roland.westrelin at oracle.com Mon Oct 14 09:50:43 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 Oct 2013 18:50:43 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> Message-ID: A new webrev for this one: http://cr.openjdk.java.net/~roland/8026251/webrev.01/ I added a bug fix for: ciCallTypeData::translate_type_data_from() which should really be ciCallTypeData::translate_from. That bug prevents the profiling types at a static call from being translated to ciKlass'es when ciMethodData is created. Roland. On Oct 14, 2013, at 1:59 PM, Roland Westrelin wrote: > The last of the series of new type profiling points. > > http://cr.openjdk.java.net/~roland/8026251/webrev.00/ > > The output of PrintMethodData is: > > TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; > interpreter_invocation_count: 5000 > invocation_counter: 5000 > backedge_counter: 0 > mdo size: 444 bytes > > parameter types 0: stack(0) 'TestProfiling' > 1: stack(1) 'TestProfiling$A' > > Roland. From vladimir.x.ivanov at oracle.com Mon Oct 14 10:13:44 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Oct 2013 21:13:44 +0400 Subject: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Message-ID: <525C2648.9080302@oracle.com> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/ 89 lines changed: 82 ins; 0 del; 7 mod C1 inlining is implemented in a depth-first fashion as a recursion. During compilation of lambda forms @ForceInline annotation is used extensively to force inlining of generated methods. For a long chain of method handles, inlining of methods marked w/ @ForceInline can overflow a stack and crashes VM. I chose a conservative way to fix the problem and set a limit on maximum inlining depth for methods marked @ForceInline. Having it set to 100: - no crash observed anymore w/ C1 - no inline bailouts due to MaxForceInlineLevel reached on octane benchmarks For ordinary methods the limit(MaxInlineLevel) is much lower and set to 9. Also, to improve regression test (to considerably speed it up by avoiding separate compilation of intermediate lambda forms code) I changed behavior of inline command to force inlining of a method when it is excluded from compilation. Example: -XX:CompileCommand=compileonly,DeepInliningTest,m2 -XX:CompileCommand=inline,java/lang/invoke*,* Before: DeepInliningTest::m2 (10 bytes) @ 3 java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13 bytes) excluded by CompilerOracle @ 6 java.lang.Boolean::booleanValue (5 bytes) excluded by CompilerOracle After: DeepInliningTest::m2 (10 bytes) @ 3 java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13 bytes) force inline by annotation @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation @ 11 java.lang.invoke.MethodHandle::type (5 bytes) not compilable (disabled) @ 25 java.lang.invoke.Invokers::newWrongMethodTypeException (36 bytes) force inline by CompileOracle @ 8 java.lang.StringBuilder:: (7 bytes) excluded by CompilerOracle ... @ 9 java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes) force inline by annotation @ 5 java.lang.invoke.LambdaForm$MH/1072601481::convert (22 bytes) force inline by annotation ... Testing: regression test, octane, JPRT (in progress) Best regards, Vladimir Ivanov JBS: https://bugs.openjdk.java.net/browse/JDK-8012941 From vladimir.kozlov at oracle.com Mon Oct 14 10:36:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 10:36:37 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> Message-ID: <525C2BA5.7010100@oracle.com> Roland, I wish you added more comments to the code. Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? methodData.cpp Rename args_cell to params_cell: + int args_cell = ParametersTypeData::compute_cell_count(method()); + if (args_cell > 0) { Thanks, Vladimir On 10/14/13 4:59 AM, Roland Westrelin wrote: > The last of the series of new type profiling points. > > http://cr.openjdk.java.net/~roland/8026251/webrev.00/ > > The output of PrintMethodData is: > > TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; > interpreter_invocation_count: 5000 > invocation_counter: 5000 > backedge_counter: 0 > mdo size: 444 bytes > > parameter types 0: stack(0) 'TestProfiling' > 1: stack(1) 'TestProfiling$A' > > Roland. > From vladimir.kozlov at oracle.com Mon Oct 14 10:52:57 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 10:52:57 -0700 Subject: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow In-Reply-To: <525C2648.9080302@oracle.com> References: <525C2648.9080302@oracle.com> Message-ID: <525C2F79.2060207@oracle.com> Why C2 is not affected? Did it bailout inlining early? 100 could be not enough but reasonable. I don't like changing inlining behavior for excluded methods. You need to do special case explicitly for CompileOnly. And do it as separate fix. thanks, Vladimir On 10/14/13 10:13 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/ > 89 lines changed: 82 ins; 0 del; 7 mod > > C1 inlining is implemented in a depth-first fashion as a recursion. > During compilation of lambda forms @ForceInline annotation is used > extensively to force inlining of generated methods. For a long chain of > method handles, inlining of methods marked w/ @ForceInline can overflow > a stack and crashes VM. > > I chose a conservative way to fix the problem and set a limit on maximum > inlining depth for methods marked @ForceInline. > > Having it set to 100: > - no crash observed anymore w/ C1 > - no inline bailouts due to MaxForceInlineLevel reached on octane > benchmarks > > For ordinary methods the limit(MaxInlineLevel) is much lower and set to 9. > > Also, to improve regression test (to considerably speed it up by > avoiding separate compilation of intermediate lambda forms code) I > changed behavior of inline command to force inlining of a method when it > is excluded from compilation. > > Example: > > -XX:CompileCommand=compileonly,DeepInliningTest,m2 > -XX:CompileCommand=inline,java/lang/invoke*,* > > Before: > DeepInliningTest::m2 (10 bytes) > @ 3 java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13 > bytes) excluded by CompilerOracle > @ 6 java.lang.Boolean::booleanValue (5 bytes) excluded by > CompilerOracle > > After: > DeepInliningTest::m2 (10 bytes) > @ 3 java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13 > bytes) force inline by annotation > @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force > inline by annotation > @ 11 java.lang.invoke.MethodHandle::type (5 bytes) not > compilable (disabled) > @ 25 java.lang.invoke.Invokers::newWrongMethodTypeException (36 > bytes) force inline by CompileOracle > @ 8 java.lang.StringBuilder:: (7 bytes) excluded by > CompilerOracle > ... > @ 9 java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes) > force inline by annotation > @ 5 java.lang.invoke.LambdaForm$MH/1072601481::convert (22 > bytes) force inline by annotation > ... > > Testing: regression test, octane, JPRT (in progress) > > Best regards, > Vladimir Ivanov > > JBS: https://bugs.openjdk.java.net/browse/JDK-8012941 From vladimir.kozlov at oracle.com Mon Oct 14 11:10:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 11:10:24 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <525C2BA5.7010100@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> Message-ID: <525C3390.2030609@oracle.com> On 10/14/13 10:36 AM, Vladimir Kozlov wrote: > Roland, > > I wish you added more comments to the code. > > Assembler. mdp points to array_len cell so your TypeStackSlotEntries > access is off by 1. I'm taking this back because array_start_off_set is taking into account by ParametersTypeData::type_offset() etc. Comments!!! Vladimir > > c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? > Why profiling parameter affects number of profiled arguments? > > methodData.cpp Rename args_cell to params_cell: > > + int args_cell = ParametersTypeData::compute_cell_count(method()); > + if (args_cell > 0) { > > Thanks, > Vladimir > > On 10/14/13 4:59 AM, Roland Westrelin wrote: >> The last of the series of new type profiling points. >> >> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >> >> The output of PrintMethodData is: >> >> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >> >> interpreter_invocation_count: 5000 >> invocation_counter: 5000 >> backedge_counter: 0 >> mdo size: 444 bytes >> >> parameter types 0: stack(0) 'TestProfiling' >> 1: stack(1) 'TestProfiling$A' >> >> Roland. >> From christian.thalinger at oracle.com Mon Oct 14 11:19:50 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 11:19:50 -0700 Subject: RFR (XXS): 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Message-ID: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8026376 http://cr.openjdk.java.net/~twisti/8026376/webrev.00/ 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: It made me suspicious that only the second assert fired (the exception pc check) and not the first one (the exception oop check). I checked all the places where JavaThread::exception_oop_offset() was used to clear the exception oop to see if we also clear the exception pc. In the deopt blob we have such a case. On x86 we clear both but on SPARC we don't. Added the missing null-store instruction makes the test case pass. Reading the exception pc is not really required but I've added it for completeness. From christian.thalinger at oracle.com Mon Oct 14 11:26:32 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 11:26:32 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <2F63C163-0D4A-4BF3-9F2D-572E6C335537@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> <525835A9.6010709@oracle.com> <2F63C163-0D4A-4BF3-9F2D-572E6C335537@oracle.com> Message-ID: Looks good. On Oct 14, 2013, at 12:44 AM, Rickard B?ckman wrote: > Christian & Vladimir, > > I added both: http://cr.openjdk.java.net/~rbackman/8025657.5/webrev/ > > Thanks > /R > > On Oct 11, 2013, at 8:03 PM, Christian Thalinger wrote: > >> >> On Oct 11, 2013, at 10:30 AM, Vladimir Kozlov wrote: >> >>> Rickard, >>> >>> First about double addExact(). I was worried about FlagsProj will have two users so that flags->unique_out() will throw assert. But it looks like IfNode::Ideal eliminated second IfNode since inputs are the same. So it may be fine and we did not see failures like this in testing. >>> >>> About changes. I think they good. Can you add MathExactNode::iff_node() and use it instead of duplications? >> >> Perhaps also MathExactNode::bool_node() since you need that one too. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/11/13 5:53 AM, Rickard B?ckman wrote: >>>> And someone pointed out that I don't need to have Verify.java in @compile. >>>> >>>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.4/ >>>> >>>> Thanks >>>> /R >>>> >>>> On Oct 11, 2013, at 1:53 PM, Rickard B?ckman wrote: >>>> >>>>> Forgot to include a new test case. >>>>> >>>>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ >>>>> >>>>> /R >>>>> >>>>> On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: >>>>> >>>>>> Vladimir, >>>>>> >>>>>> Setting the control edge for addExact and then setting the control edge for everyone who depends on the >>>>>> result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. >>>>>> >>>>>> GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: >>>>>> >>>>>> add rax, rdx >>>>>> jo ?. >>>>>> add rax, rax >>>>>> >>>>>> for java code: >>>>>> >>>>>> result = addExact(x, y) >>>>>> result += addExact(x, y) >>>>>> >>>>>> Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> >>>>>> On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Rickard, >>>>>>> >>>>>>> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >>>>>>> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >>>>>>> >>>>>>> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >>>>>>> >>>>>>> addExact(x,y) >>>>>>> addExact(x,y) >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>>>>>>> Vladimir, >>>>>>>> >>>>>>>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>>>>>>> uses of addExact this seems to be problematic. >>>>>>>> >>>>>>>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>>>>>>> >>>>>>>> Thank you >>>>>>>> /R >>>>>>>> >>>>>>>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Rickard, >>>>>>>>> >>>>>>>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>>>>>>> >>>>>>>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I would appreciate some reviews on this change. >>>>>>>>>> >>>>>>>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>>>>>>> assert(idx >= 0) failed: index should be set >>>>>>>>>> >>>>>>>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>>>>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>>>>>>> the consumer. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /R >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> > From christian.thalinger at oracle.com Mon Oct 14 11:27:26 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 11:27:26 -0700 Subject: RFR(XXS): 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice In-Reply-To: <525B8DED.1080505@oracle.com> References: <525B8DED.1080505@oracle.com> Message-ID: Looks good. On Oct 13, 2013, at 11:23 PM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8025740 > Webrev: http://cr.openjdk.java.net/~anoll/8025740/webrev.00/ > > problem: 'java -XX:ReservedCodeCacheSize=2049m -version' gives the following output. > > > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. > > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. > > Solution: Remove duplicate check of ReservedCodeCacheSize from Arguments::check_gc_consistency(). > > > Best, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131014/0277e9e0/attachment-0001.html From christian.thalinger at oracle.com Mon Oct 14 11:28:37 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 11:28:37 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> <5259897C.6090103@oracle.com> Message-ID: <41B0AAE3-E40A-42D4-B113-A1F6EF2BEBB2@oracle.com> Looks good (except the indent of the #ifdef). On Oct 12, 2013, at 2:28 PM, David Chase wrote: > Additional fixes applied: > > http://cr.openjdk.java.net/~drchase/8026124/webrev.02/ > > On 2013-10-12, at 1:40 PM, Vladimir Kozlov wrote: > >> On 10/12/13 9:55 AM, Christian Thalinger wrote: >>> >>> On Oct 12, 2013, at 8:35 AM, David Chase wrote: >>> >>>> New webrev: http://cr.openjdk.java.net/~drchase/8026124/webrev.01/ >>>> >>>> Fixed " -> " >> >> You missed one in condition. >> >>>> Made assertions fail more informatively. >>> >>> Nice. Only a suggestion but since the debug code spans already 8 lines maybe ditch DEBUG_ONLY and use an #ifdef ASSERT around all that stuff. You don't have to do it. >> >> +1 for #ifdef ASSERT >> >> You don't need @compile line in the test: >> >> * @compile CreatesInterfaceDotEqualsCallInfo.java >> >> Thanks, >> Vladimir >> >>> >>> Looks good. >>> >>>> Tested failure printing (inserted "false && ", recompiled and ran). >>>> Added test (uses Javascript from bug report). >>>> >>>> David >>>> >>>> >>>> On 2013-10-12, at 10:03 AM, David Chase wrote: >>>> >>>>> >>>>> On 2013-10-12, at 3:12 AM, John Rose wrote: >>>>>> >>>>>> Your best bet might be asm. (I tried a few variations on the theme of TestIntfc::toString, including some emacs-ing of class files, but no luck.) Might I recommend a reusable BogoLoader in test/java/lang/invoke/? >>>>> >>>>> Except that this is in the hotspot hierarchy, so that's the wrong tests. >>>>> >>>>> The other problem I have with this is that I don't entirely understand the packaging requirements for test classes shared by several tests in subdirectories -- I have from time to time experienced test harness failures of the form >>>>> "java.lang.SecurityException: Prohibited package name: java.util.stream" >>>>> and until I understand the cause, I'm reluctant to stray from what has worked in the past, >>>>> which is a top-level collection of test classes in a subdirectory. >>>>> >>>>> David >>>>> >>>> >>> > From vladimir.x.ivanov at oracle.com Mon Oct 14 11:38:45 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Oct 2013 22:38:45 +0400 Subject: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow In-Reply-To: <525C2F79.2060207@oracle.com> References: <525C2648.9080302@oracle.com> <525C2F79.2060207@oracle.com> Message-ID: <525C3A35.3000606@oracle.com> On 10/14/13 9:52 PM, Vladimir Kozlov wrote: > Why C2 is not affected? Did it bailout inlining early? 8012941 is about C1. But C2 is also affected - it fails to delay inlining of @ForceInline methods in some situations (regression test fails with C2). I want to address it separately, since the strategy of the fix should be different. > 100 could be not enough but reasonable. In that case the performance will be suboptimal. For C1 it is acceptable. > I don't like changing inlining behavior for excluded methods. You need > to do special case explicitly for CompileOnly. And do it as separate fix. Ok. Will do. Removed regression test for now. It takes too much time to run. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8012941/webrev.01/ Best regards, Vladimir Ivanov > > thanks, > Vladimir > > On 10/14/13 10:13 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/ >> 89 lines changed: 82 ins; 0 del; 7 mod >> >> C1 inlining is implemented in a depth-first fashion as a recursion. >> During compilation of lambda forms @ForceInline annotation is used >> extensively to force inlining of generated methods. For a long chain of >> method handles, inlining of methods marked w/ @ForceInline can overflow >> a stack and crashes VM. >> >> I chose a conservative way to fix the problem and set a limit on maximum >> inlining depth for methods marked @ForceInline. >> >> Having it set to 100: >> - no crash observed anymore w/ C1 >> - no inline bailouts due to MaxForceInlineLevel reached on octane >> benchmarks >> >> For ordinary methods the limit(MaxInlineLevel) is much lower and set >> to 9. >> >> Also, to improve regression test (to considerably speed it up by >> avoiding separate compilation of intermediate lambda forms code) I >> changed behavior of inline command to force inlining of a method when it >> is excluded from compilation. >> >> Example: >> >> -XX:CompileCommand=compileonly,DeepInliningTest,m2 >> -XX:CompileCommand=inline,java/lang/invoke*,* >> >> Before: >> DeepInliningTest::m2 (10 bytes) >> @ 3 java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13 >> bytes) excluded by CompilerOracle >> @ 6 java.lang.Boolean::booleanValue (5 bytes) excluded by >> CompilerOracle >> >> After: >> DeepInliningTest::m2 (10 bytes) >> @ 3 java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13 >> bytes) force inline by annotation >> @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force >> inline by annotation >> @ 11 java.lang.invoke.MethodHandle::type (5 bytes) not >> compilable (disabled) >> @ 25 java.lang.invoke.Invokers::newWrongMethodTypeException (36 >> bytes) force inline by CompileOracle >> @ 8 java.lang.StringBuilder:: (7 bytes) excluded by >> CompilerOracle >> ... >> @ 9 java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes) >> force inline by annotation >> @ 5 java.lang.invoke.LambdaForm$MH/1072601481::convert (22 >> bytes) force inline by annotation >> ... >> >> Testing: regression test, octane, JPRT (in progress) >> >> Best regards, >> Vladimir Ivanov >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8012941 From christian.thalinger at oracle.com Mon Oct 14 11:42:46 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 11:42:46 -0700 Subject: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow In-Reply-To: <525C3A35.3000606@oracle.com> References: <525C2648.9080302@oracle.com> <525C2F79.2060207@oracle.com> <525C3A35.3000606@oracle.com> Message-ID: <21A94F81-7492-4B02-A1A6-43BBAA1B7769@oracle.com> Looks good. It's unfortunate that we have to add yet another product flag for this. On Oct 14, 2013, at 11:38 AM, Vladimir Ivanov wrote: > On 10/14/13 9:52 PM, Vladimir Kozlov wrote: >> Why C2 is not affected? Did it bailout inlining early? > 8012941 is about C1. But C2 is also affected - it fails to delay inlining of @ForceInline methods in some situations (regression test fails with C2). I want to address it separately, since the strategy of the fix should be different. > >> 100 could be not enough but reasonable. > In that case the performance will be suboptimal. For C1 it is acceptable. > >> I don't like changing inlining behavior for excluded methods. You need >> to do special case explicitly for CompileOnly. And do it as separate fix. > Ok. Will do. > Removed regression test for now. It takes too much time to run. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8012941/webrev.01/ > > Best regards, > Vladimir Ivanov >> >> thanks, >> Vladimir >> >> On 10/14/13 10:13 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/ >>> 89 lines changed: 82 ins; 0 del; 7 mod >>> >>> C1 inlining is implemented in a depth-first fashion as a recursion. >>> During compilation of lambda forms @ForceInline annotation is used >>> extensively to force inlining of generated methods. For a long chain of >>> method handles, inlining of methods marked w/ @ForceInline can overflow >>> a stack and crashes VM. >>> >>> I chose a conservative way to fix the problem and set a limit on maximum >>> inlining depth for methods marked @ForceInline. >>> >>> Having it set to 100: >>> - no crash observed anymore w/ C1 >>> - no inline bailouts due to MaxForceInlineLevel reached on octane >>> benchmarks >>> >>> For ordinary methods the limit(MaxInlineLevel) is much lower and set >>> to 9. >>> >>> Also, to improve regression test (to considerably speed it up by >>> avoiding separate compilation of intermediate lambda forms code) I >>> changed behavior of inline command to force inlining of a method when it >>> is excluded from compilation. >>> >>> Example: >>> >>> -XX:CompileCommand=compileonly,DeepInliningTest,m2 >>> -XX:CompileCommand=inline,java/lang/invoke*,* >>> >>> Before: >>> DeepInliningTest::m2 (10 bytes) >>> @ 3 java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13 >>> bytes) excluded by CompilerOracle >>> @ 6 java.lang.Boolean::booleanValue (5 bytes) excluded by >>> CompilerOracle >>> >>> After: >>> DeepInliningTest::m2 (10 bytes) >>> @ 3 java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13 >>> bytes) force inline by annotation >>> @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force >>> inline by annotation >>> @ 11 java.lang.invoke.MethodHandle::type (5 bytes) not >>> compilable (disabled) >>> @ 25 java.lang.invoke.Invokers::newWrongMethodTypeException (36 >>> bytes) force inline by CompileOracle >>> @ 8 java.lang.StringBuilder:: (7 bytes) excluded by >>> CompilerOracle >>> ... >>> @ 9 java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes) >>> force inline by annotation >>> @ 5 java.lang.invoke.LambdaForm$MH/1072601481::convert (22 >>> bytes) force inline by annotation >>> ... >>> >>> Testing: regression test, octane, JPRT (in progress) >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8012941 From vladimir.kozlov at oracle.com Mon Oct 14 11:43:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 11:43:32 -0700 Subject: RFR (XXS): 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set In-Reply-To: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> References: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> Message-ID: <525C3B54.4050308@oracle.com> Don't read exception pc since it is not needed. You may trash a value in that register. Thanks, Vladimir On 10/14/13 11:19 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8026376 > http://cr.openjdk.java.net/~twisti/8026376/webrev.00/ > > 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set > Reviewed-by: > > It made me suspicious that only the second assert fired (the exception pc check) and not the first one (the exception oop check). I checked all the places where JavaThread::exception_oop_offset() was used to clear the exception oop to see if we also clear the exception pc. > > In the deopt blob we have such a case. On x86 we clear both but on SPARC we don't. > > Added the missing null-store instruction makes the test case pass. > > Reading the exception pc is not really required but I've added it for completeness. > From vladimir.kozlov at oracle.com Mon Oct 14 11:47:21 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 11:47:21 -0700 Subject: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow In-Reply-To: <525C3A35.3000606@oracle.com> References: <525C2648.9080302@oracle.com> <525C2F79.2060207@oracle.com> <525C3A35.3000606@oracle.com> Message-ID: <525C3C39.1080502@oracle.com> On 10/14/13 11:38 AM, Vladimir Ivanov wrote: > On 10/14/13 9:52 PM, Vladimir Kozlov wrote: >> Why C2 is not affected? Did it bailout inlining early? > 8012941 is about C1. But C2 is also affected - it fails to delay > inlining of @ForceInline methods in some situations (regression test > fails with C2). I want to address it separately, since the strategy of > the fix should be different. Okay. >> 100 could be not enough but reasonable. > In that case the performance will be suboptimal. For C1 it is acceptable. Yes. > >> I don't like changing inlining behavior for excluded methods. You need >> to do special case explicitly for CompileOnly. And do it as separate fix. > Ok. Will do. > Removed regression test for now. It takes too much time to run. Point in the bug report that the test will be added later. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8012941/webrev.01/ Good. Vladimir > > Best regards, > Vladimir Ivanov >> >> thanks, >> Vladimir >> >> On 10/14/13 10:13 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/ >>> 89 lines changed: 82 ins; 0 del; 7 mod >>> >>> C1 inlining is implemented in a depth-first fashion as a recursion. >>> During compilation of lambda forms @ForceInline annotation is used >>> extensively to force inlining of generated methods. For a long chain of >>> method handles, inlining of methods marked w/ @ForceInline can overflow >>> a stack and crashes VM. >>> >>> I chose a conservative way to fix the problem and set a limit on maximum >>> inlining depth for methods marked @ForceInline. >>> >>> Having it set to 100: >>> - no crash observed anymore w/ C1 >>> - no inline bailouts due to MaxForceInlineLevel reached on octane >>> benchmarks >>> >>> For ordinary methods the limit(MaxInlineLevel) is much lower and set >>> to 9. >>> >>> Also, to improve regression test (to considerably speed it up by >>> avoiding separate compilation of intermediate lambda forms code) I >>> changed behavior of inline command to force inlining of a method when it >>> is excluded from compilation. >>> >>> Example: >>> >>> -XX:CompileCommand=compileonly,DeepInliningTest,m2 >>> -XX:CompileCommand=inline,java/lang/invoke*,* >>> >>> Before: >>> DeepInliningTest::m2 (10 bytes) >>> @ 3 java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13 >>> bytes) excluded by CompilerOracle >>> @ 6 java.lang.Boolean::booleanValue (5 bytes) excluded by >>> CompilerOracle >>> >>> After: >>> DeepInliningTest::m2 (10 bytes) >>> @ 3 java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13 >>> bytes) force inline by annotation >>> @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force >>> inline by annotation >>> @ 11 java.lang.invoke.MethodHandle::type (5 bytes) not >>> compilable (disabled) >>> @ 25 java.lang.invoke.Invokers::newWrongMethodTypeException (36 >>> bytes) force inline by CompileOracle >>> @ 8 java.lang.StringBuilder:: (7 bytes) excluded by >>> CompilerOracle >>> ... >>> @ 9 java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes) >>> force inline by annotation >>> @ 5 java.lang.invoke.LambdaForm$MH/1072601481::convert (22 >>> bytes) force inline by annotation >>> ... >>> >>> Testing: regression test, octane, JPRT (in progress) >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8012941 From david.r.chase at oracle.com Mon Oct 14 11:47:41 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 14 Oct 2013 14:47:41 -0400 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: <41B0AAE3-E40A-42D4-B113-A1F6EF2BEBB2@oracle.com> References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> <5259897C.6090103@oracle.com> <41B0AAE3-E40A-42D4-B113-A1F6EF2BEBB2@oracle.com> Message-ID: <55443EDC-5C8C-4764-B56D-924FDAB86315@oracle.com> What is the recommended indent of the #ifdef? I did look around, and I think the first example I found did not indent, so I copied that. David On 2013-10-14, at 2:28 PM, Christian Thalinger wrote: > Looks good (except the indent of the #ifdef). > > On Oct 12, 2013, at 2:28 PM, David Chase wrote: > >> Additional fixes applied: >> >> http://cr.openjdk.java.net/~drchase/8026124/webrev.02/ >> >> On 2013-10-12, at 1:40 PM, Vladimir Kozlov wrote: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131014/9e75826c/signature-0001.asc From igor.ignatyev at oracle.com Mon Oct 14 12:08:45 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 14 Oct 2013 23:08:45 +0400 Subject: RFR(XS) : 8023318 : compiler/whitebox tests timeout with enabled TieredCompilation Message-ID: <525C413D.3020205@oracle.com> Hi all, Please review patch: Problem: OSR test cases in 'compiler/whitebox/*' takes too much time w/ enabled TieredCompilation. Fix: 'BACKEDGE_THRESHOLD' was decreased to 150000 for TieredCompilation. This value is enough, because all tests run w/ '-XX:CompileCommand=compileonly,TestCase$Helper::*', so compilation queue is empty. webrev: http://cr.openjdk.java.net/~iignatyev/8023318/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8023318 testing: compiler/whitebox w/ default flags and w/ the same flags as in nightly -- Best regards, Igor Ignatyev From igor.ignatyev at oracle.com Mon Oct 14 12:12:05 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 14 Oct 2013 23:12:05 +0400 Subject: RFR(S) : 8026414 : [TESTBUG] Tests for Tiered/NonTiered levels Message-ID: <525C4205.1060404@oracle.com> Hi all, Please review patch: New tests for TieredCompilation were developed. Tests verify that only 4(1) level is used when Tiered is disabled and all otherwise. webrev: http://cr.openjdk.java.net/~iignatyev/8026414/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8026414 testing: compiler/tiered w/ default flags and w/ the same flags as in nightly -- Best regards, Igor Ignatyev From vladimir.x.ivanov at oracle.com Mon Oct 14 12:15:16 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Oct 2013 23:15:16 +0400 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Message-ID: <525C42C4.1090801@oracle.com> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ 7 lines changed: 5 ins; 1 del; 1 mod Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: assert(m.vminfoIsConsistent()); After that check, class redefinition is broken - it's still possible to invoke old version of a method. Analysis from Serguei: "The problem is here: oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& info) { . . . . . . . . m->method_holder()->add_member_name(m->method_idnum(), mname); return mname(); } The call to add_member_name() resets the member name at the index m->method_idnum(). After that one of the two member names with the same method_idnum() is out of the MNT and is not updated when the method is redefined." The fix is to check whether there's already a member name associated with the before creating a new one. Testing: failing test. Contributed-by: sspitsyn, vlivanov Best regards, Vladimir Ivanov JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 From vladimir.kozlov at oracle.com Mon Oct 14 12:28:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 12:28:53 -0700 Subject: RFR(XS) : 8023318 : compiler/whitebox tests timeout with enabled TieredCompilation In-Reply-To: <525C413D.3020205@oracle.com> References: <525C413D.3020205@oracle.com> Message-ID: <525C45F5.4010605@oracle.com> Good. Vladimir On 10/14/13 12:08 PM, Igor Ignatyev wrote: > Hi all, > > Please review patch: > > Problem: > OSR test cases in 'compiler/whitebox/*' takes too much time w/ enabled > TieredCompilation. > > Fix: > 'BACKEDGE_THRESHOLD' was decreased to 150000 for TieredCompilation. This > value is enough, because all tests run w/ > '-XX:CompileCommand=compileonly,TestCase$Helper::*', so compilation > queue is empty. > > webrev: http://cr.openjdk.java.net/~iignatyev/8023318/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8023318 > testing: compiler/whitebox w/ default flags and w/ the same flags as in > nightly From serguei.spitsyn at oracle.com Mon Oct 14 12:48:38 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 14 Oct 2013 12:48:38 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <525C42C4.1090801@oracle.com> References: <525C42C4.1090801@oracle.com> Message-ID: <525C4A96.1000706@oracle.com> The fix is good (if my opinion is counted here). Thanks, Serguei On 10/14/13 12:15 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ > 7 lines changed: 5 ins; 1 del; 1 mod > > Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: > assert(m.vminfoIsConsistent()); > > After that check, class redefinition is broken - it's still possible > to invoke old version of a method. > > Analysis from Serguei: > "The problem is here: > oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& info) { > . . . . . . . . > m->method_holder()->add_member_name(m->method_idnum(), mname); > > return mname(); > } > > The call to add_member_name() resets the member name at the index > m->method_idnum(). After that one of the two member names with the > same method_idnum() is out of the MNT and is not updated when the > method is redefined." > > The fix is to check whether there's already a member name associated > with the before creating a new one. > > Testing: failing test. > > Contributed-by: sspitsyn, vlivanov > > Best regards, > Vladimir Ivanov > > JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 From roland.westrelin at oracle.com Mon Oct 14 12:57:48 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 Oct 2013 21:57:48 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <525C2BA5.7010100@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> Message-ID: <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> Hi Vladimir, Thanks for the comments. > I wish you added more comments to the code. Do you want me to send another webrev? > > Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. > > c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. > methodData.cpp Rename args_cell to params_cell: > > + int args_cell = ParametersTypeData::compute_cell_count(method()); > + if (args_cell > 0) { Ok. Roland. > > Thanks, > Vladimir > > On 10/14/13 4:59 AM, Roland Westrelin wrote: >> The last of the series of new type profiling points. >> >> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >> >> The output of PrintMethodData is: >> >> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >> interpreter_invocation_count: 5000 >> invocation_counter: 5000 >> backedge_counter: 0 >> mdo size: 444 bytes >> >> parameter types 0: stack(0) 'TestProfiling' >> 1: stack(1) 'TestProfiling$A' >> >> Roland. >> From vladimir.kozlov at oracle.com Mon Oct 14 13:53:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 13:53:13 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> Message-ID: <525C59B9.9050705@oracle.com> On 10/14/13 12:57 PM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for the comments. > >> I wish you added more comments to the code. > > Do you want me to send another webrev? I would wait review from Christian before updating webrev. > >> >> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >> >> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? > > To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: arg = x->profiled_arg_at(i); Vladimir > >> methodData.cpp Rename args_cell to params_cell: >> >> + int args_cell = ParametersTypeData::compute_cell_count(method()); >> + if (args_cell > 0) { > > Ok. > > Roland. > >> >> Thanks, >> Vladimir >> >> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>> The last of the series of new type profiling points. >>> >>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>> >>> The output of PrintMethodData is: >>> >>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>> interpreter_invocation_count: 5000 >>> invocation_counter: 5000 >>> backedge_counter: 0 >>> mdo size: 444 bytes >>> >>> parameter types 0: stack(0) 'TestProfiling' >>> 1: stack(1) 'TestProfiling$A' >>> >>> Roland. >>> > From igor.veresov at oracle.com Mon Oct 14 13:57:42 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 14 Oct 2013 13:57:42 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> Message-ID: <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> Hi guys, I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ Testing: jtreg, CTW, the failing tests igor From christian.thalinger at oracle.com Mon Oct 14 14:12:17 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 14:12:17 -0700 Subject: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow In-Reply-To: <21A94F81-7492-4B02-A1A6-43BBAA1B7769@oracle.com> References: <525C2648.9080302@oracle.com> <525C2F79.2060207@oracle.com> <525C3A35.3000606@oracle.com> <21A94F81-7492-4B02-A1A6-43BBAA1B7769@oracle.com> Message-ID: On Oct 14, 2013, at 11:42 AM, Christian Thalinger wrote: > Looks good. It's unfortunate that we have to add yet another product flag for this. We talked about this product flag during lunch and we shouldn't add it. Can you make it a develop flag? > > On Oct 14, 2013, at 11:38 AM, Vladimir Ivanov wrote: > >> On 10/14/13 9:52 PM, Vladimir Kozlov wrote: >>> Why C2 is not affected? Did it bailout inlining early? >> 8012941 is about C1. But C2 is also affected - it fails to delay inlining of @ForceInline methods in some situations (regression test fails with C2). I want to address it separately, since the strategy of the fix should be different. >> >>> 100 could be not enough but reasonable. >> In that case the performance will be suboptimal. For C1 it is acceptable. >> >>> I don't like changing inlining behavior for excluded methods. You need >>> to do special case explicitly for CompileOnly. And do it as separate fix. >> Ok. Will do. >> Removed regression test for now. It takes too much time to run. >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.01/ >> >> Best regards, >> Vladimir Ivanov >>> >>> thanks, >>> Vladimir >>> >>> On 10/14/13 10:13 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/ >>>> 89 lines changed: 82 ins; 0 del; 7 mod >>>> >>>> C1 inlining is implemented in a depth-first fashion as a recursion. >>>> During compilation of lambda forms @ForceInline annotation is used >>>> extensively to force inlining of generated methods. For a long chain of >>>> method handles, inlining of methods marked w/ @ForceInline can overflow >>>> a stack and crashes VM. >>>> >>>> I chose a conservative way to fix the problem and set a limit on maximum >>>> inlining depth for methods marked @ForceInline. >>>> >>>> Having it set to 100: >>>> - no crash observed anymore w/ C1 >>>> - no inline bailouts due to MaxForceInlineLevel reached on octane >>>> benchmarks >>>> >>>> For ordinary methods the limit(MaxInlineLevel) is much lower and set >>>> to 9. >>>> >>>> Also, to improve regression test (to considerably speed it up by >>>> avoiding separate compilation of intermediate lambda forms code) I >>>> changed behavior of inline command to force inlining of a method when it >>>> is excluded from compilation. >>>> >>>> Example: >>>> >>>> -XX:CompileCommand=compileonly,DeepInliningTest,m2 >>>> -XX:CompileCommand=inline,java/lang/invoke*,* >>>> >>>> Before: >>>> DeepInliningTest::m2 (10 bytes) >>>> @ 3 java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13 >>>> bytes) excluded by CompilerOracle >>>> @ 6 java.lang.Boolean::booleanValue (5 bytes) excluded by >>>> CompilerOracle >>>> >>>> After: >>>> DeepInliningTest::m2 (10 bytes) >>>> @ 3 java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13 >>>> bytes) force inline by annotation >>>> @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force >>>> inline by annotation >>>> @ 11 java.lang.invoke.MethodHandle::type (5 bytes) not >>>> compilable (disabled) >>>> @ 25 java.lang.invoke.Invokers::newWrongMethodTypeException (36 >>>> bytes) force inline by CompileOracle >>>> @ 8 java.lang.StringBuilder:: (7 bytes) excluded by >>>> CompilerOracle >>>> ... >>>> @ 9 java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes) >>>> force inline by annotation >>>> @ 5 java.lang.invoke.LambdaForm$MH/1072601481::convert (22 >>>> bytes) force inline by annotation >>>> ... >>>> >>>> Testing: regression test, octane, JPRT (in progress) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8012941 > From christian.thalinger at oracle.com Mon Oct 14 14:15:04 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 14:15:04 -0700 Subject: RFR(S) : 8026124 : JSR-292 bug: java.nio.file.Path.toString cores dump In-Reply-To: <55443EDC-5C8C-4764-B56D-924FDAB86315@oracle.com> References: <3C2106B2-E746-426D-A9B3-B66A2F203ACE@oracle.com> <9AC87572-1573-4F1A-A19F-34DA3C60905C@oracle.com> <25A48DE7-3CF9-4743-AC6F-750F107ED28D@oracle.com> <5259897C.6090103@oracle.com> <41B0AAE3-E40A-42D4-B113-A1F6EF2BEBB2@oracle.com> <55443EDC-5C8C-4764-B56D-924FDAB86315@oracle.com> Message-ID: <3D141AAB-9DDA-49DF-AB42-15ADCABA4C45@oracle.com> But you have indent: + #ifdef ASSERT + // Ensure that this is really the case. The recommended way is: +#ifdef ASSERT + // Ensure that this is really the case. On Oct 14, 2013, at 11:47 AM, David Chase wrote: > What is the recommended indent of the #ifdef? I did look around, and I think the first example I found did not indent, so I copied that. > > David > > On 2013-10-14, at 2:28 PM, Christian Thalinger wrote: > >> Looks good (except the indent of the #ifdef). >> >> On Oct 12, 2013, at 2:28 PM, David Chase wrote: >> >>> Additional fixes applied: >>> >>> http://cr.openjdk.java.net/~drchase/8026124/webrev.02/ >>> >>> On 2013-10-12, at 1:40 PM, Vladimir Kozlov wrote: > From christian.thalinger at oracle.com Mon Oct 14 14:17:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 14:17:59 -0700 Subject: RFR (XXS): 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set In-Reply-To: <525C3B54.4050308@oracle.com> References: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> <525C3B54.4050308@oracle.com> Message-ID: <4C846B39-1039-470C-B4E5-384F34A2069E@oracle.com> The reason I've added it is because we do it on x86 but there are comments like this: // I think this is useless (throwing pc?) __ movptr(rdx, Address(rsp, RegisterSaver::rdx_offset_in_bytes())); So we either should read it everywhere or don't. On Oct 14, 2013, at 11:43 AM, Vladimir Kozlov wrote: > Don't read exception pc since it is not needed. You may trash a value in that register. > > Thanks, > Vladimir > > On 10/14/13 11:19 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8026376 >> http://cr.openjdk.java.net/~twisti/8026376/webrev.00/ >> >> 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set >> Reviewed-by: >> >> It made me suspicious that only the second assert fired (the exception pc check) and not the first one (the exception oop check). I checked all the places where JavaThread::exception_oop_offset() was used to clear the exception oop to see if we also clear the exception pc. >> >> In the deopt blob we have such a case. On x86 we clear both but on SPARC we don't. >> >> Added the missing null-store instruction makes the test case pass. >> >> Reading the exception pc is not really required but I've added it for completeness. >> From roland.westrelin at oracle.com Mon Oct 14 14:19:12 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 14 Oct 2013 23:19:12 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <525C59B9.9050705@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> Message-ID: <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: > On 10/14/13 12:57 PM, Roland Westrelin wrote: >> Hi Vladimir, >> >> Thanks for the comments. >> >>> I wish you added more comments to the code. >> >> Do you want me to send another webrev? > > I would wait review from Christian before updating webrev. > >> >>> >>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>> >>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >> >> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. > > Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: > > arg = x->profiled_arg_at(i); Yes. Roland. > > Vladimir > >> >>> methodData.cpp Rename args_cell to params_cell: >>> >>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>> + if (args_cell > 0) { >> >> Ok. >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>> The last of the series of new type profiling points. >>>> >>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>> >>>> The output of PrintMethodData is: >>>> >>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>> interpreter_invocation_count: 5000 >>>> invocation_counter: 5000 >>>> backedge_counter: 0 >>>> mdo size: 444 bytes >>>> >>>> parameter types 0: stack(0) 'TestProfiling' >>>> 1: stack(1) 'TestProfiling$A' >>>> >>>> Roland. >>>> >> From vladimir.x.ivanov at oracle.com Mon Oct 14 14:23:44 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 15 Oct 2013 01:23:44 +0400 Subject: RFR (XS): 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow In-Reply-To: References: <525C2648.9080302@oracle.com> <525C2F79.2060207@oracle.com> <525C3A35.3000606@oracle.com> <21A94F81-7492-4B02-A1A6-43BBAA1B7769@oracle.com> Message-ID: <525C60E0.1050802@oracle.com> No problem, I'll make it a develop flag. Vladimir, Chris, thank you for review. Best regards, Vladimir Ivanov On 10/15/13 1:12 AM, Christian Thalinger wrote: > > On Oct 14, 2013, at 11:42 AM, Christian Thalinger wrote: > >> Looks good. It's unfortunate that we have to add yet another product flag for this. > > We talked about this product flag during lunch and we shouldn't add it. Can you make it a develop flag? > >> >> On Oct 14, 2013, at 11:38 AM, Vladimir Ivanov wrote: >> >>> On 10/14/13 9:52 PM, Vladimir Kozlov wrote: >>>> Why C2 is not affected? Did it bailout inlining early? >>> 8012941 is about C1. But C2 is also affected - it fails to delay inlining of @ForceInline methods in some situations (regression test fails with C2). I want to address it separately, since the strategy of the fix should be different. >>> >>>> 100 could be not enough but reasonable. >>> In that case the performance will be suboptimal. For C1 it is acceptable. >>> >>>> I don't like changing inlining behavior for excluded methods. You need >>>> to do special case explicitly for CompileOnly. And do it as separate fix. >>> Ok. Will do. >>> Removed regression test for now. It takes too much time to run. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.01/ >>> >>> Best regards, >>> Vladimir Ivanov >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 10/14/13 10:13 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8012941/webrev.00/ >>>>> 89 lines changed: 82 ins; 0 del; 7 mod >>>>> >>>>> C1 inlining is implemented in a depth-first fashion as a recursion. >>>>> During compilation of lambda forms @ForceInline annotation is used >>>>> extensively to force inlining of generated methods. For a long chain of >>>>> method handles, inlining of methods marked w/ @ForceInline can overflow >>>>> a stack and crashes VM. >>>>> >>>>> I chose a conservative way to fix the problem and set a limit on maximum >>>>> inlining depth for methods marked @ForceInline. >>>>> >>>>> Having it set to 100: >>>>> - no crash observed anymore w/ C1 >>>>> - no inline bailouts due to MaxForceInlineLevel reached on octane >>>>> benchmarks >>>>> >>>>> For ordinary methods the limit(MaxInlineLevel) is much lower and set >>>>> to 9. >>>>> >>>>> Also, to improve regression test (to considerably speed it up by >>>>> avoiding separate compilation of intermediate lambda forms code) I >>>>> changed behavior of inline command to force inlining of a method when it >>>>> is excluded from compilation. >>>>> >>>>> Example: >>>>> >>>>> -XX:CompileCommand=compileonly,DeepInliningTest,m2 >>>>> -XX:CompileCommand=inline,java/lang/invoke*,* >>>>> >>>>> Before: >>>>> DeepInliningTest::m2 (10 bytes) >>>>> @ 3 java.lang.invoke.LambdaForm$MH/117244645::invokeExact_MT (13 >>>>> bytes) excluded by CompilerOracle >>>>> @ 6 java.lang.Boolean::booleanValue (5 bytes) excluded by >>>>> CompilerOracle >>>>> >>>>> After: >>>>> DeepInliningTest::m2 (10 bytes) >>>>> @ 3 java.lang.invoke.LambdaForm$MH/1459672753::invokeExact_MT (13 >>>>> bytes) force inline by annotation >>>>> @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force >>>>> inline by annotation >>>>> @ 11 java.lang.invoke.MethodHandle::type (5 bytes) not >>>>> compilable (disabled) >>>>> @ 25 java.lang.invoke.Invokers::newWrongMethodTypeException (36 >>>>> bytes) force inline by CompileOracle >>>>> @ 8 java.lang.StringBuilder:: (7 bytes) excluded by >>>>> CompilerOracle >>>>> ... >>>>> @ 9 java.lang.invoke.LambdaForm$MH/485041780::convert (21 bytes) >>>>> force inline by annotation >>>>> @ 5 java.lang.invoke.LambdaForm$MH/1072601481::convert (22 >>>>> bytes) force inline by annotation >>>>> ... >>>>> >>>>> Testing: regression test, octane, JPRT (in progress) >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8012941 >> > From vladimir.kozlov at oracle.com Mon Oct 14 14:39:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 14:39:54 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> Message-ID: <525C64AA.2040901@oracle.com> You don't need 'if()': + if (mem->is_MergeMem()) { + while (mem->is_MergeMem()) { Typo "the have" ("it is"?): + // now let it fall though, and see if the have a projection I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. Thanks, Vladimir On 10/14/13 1:57 PM, Igor Veresov wrote: > Hi guys, > > I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. > Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. > > Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ > > Testing: jtreg, CTW, the failing tests > > igor > > From vladimir.kozlov at oracle.com Mon Oct 14 14:59:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 14:59:48 -0700 Subject: RFR (XXS): 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set In-Reply-To: <4C846B39-1039-470C-B4E5-384F34A2069E@oracle.com> References: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> <525C3B54.4050308@oracle.com> <4C846B39-1039-470C-B4E5-384F34A2069E@oracle.com> Message-ID: <525C6954.50601@oracle.com> For the record. Christian and I discussed it and decided to remove 'exception pc' load in deopt_blob on all platforms in separate changes. First, it is broken in x86 code anyway (it is not saved in all paths in deopt_blob). Second, we return into Interpreter which know nothing (and don't care) about compiled code and it does not use this pc data. Thanks, Vladimir On 10/14/13 2:17 PM, Christian Thalinger wrote: > The reason I've added it is because we do it on x86 but there are comments like this: > > // I think this is useless (throwing pc?) > __ movptr(rdx, Address(rsp, RegisterSaver::rdx_offset_in_bytes())); > > So we either should read it everywhere or don't. > > On Oct 14, 2013, at 11:43 AM, Vladimir Kozlov wrote: > >> Don't read exception pc since it is not needed. You may trash a value in that register. >> >> Thanks, >> Vladimir >> >> On 10/14/13 11:19 AM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8026376 >>> http://cr.openjdk.java.net/~twisti/8026376/webrev.00/ >>> >>> 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set >>> Reviewed-by: >>> >>> It made me suspicious that only the second assert fired (the exception pc check) and not the first one (the exception oop check). I checked all the places where JavaThread::exception_oop_offset() was used to clear the exception oop to see if we also clear the exception pc. >>> >>> In the deopt blob we have such a case. On x86 we clear both but on SPARC we don't. >>> >>> Added the missing null-store instruction makes the test case pass. >>> >>> Reading the exception pc is not really required but I've added it for completeness. >>> > From vladimir.kozlov at oracle.com Mon Oct 14 16:10:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 16:10:35 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: References: Message-ID: <525C79EB.8040008@oracle.com> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: _inline_cg->generate(jvms, NULL); In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. And I don't understand where 1) requirement comes from. I am fine with moving is_uncommon_trap_*() mathods. Thanks, Vladimir On 10/12/13 2:31 PM, Roland Westrelin wrote: > The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. > > When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. > > http://cr.openjdk.java.net/~roland/8024069/webrev.00/ > > Roland. > From igor.veresov at oracle.com Mon Oct 14 17:38:47 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 14 Oct 2013 17:38:47 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <525C64AA.2040901@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> Message-ID: <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: > You don't need 'if()': > > + if (mem->is_MergeMem()) { > + while (mem->is_MergeMem()) { > ok > Typo "the have" ("it is"?): > > + // now let it fall though, and see if the have a projection > yup > I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. > Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. Thanks! igor > Thanks, > Vladimir > > On 10/14/13 1:57 PM, Igor Veresov wrote: >> Hi guys, >> >> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >> >> Testing: jtreg, CTW, the failing tests >> >> igor >> >> From christian.thalinger at oracle.com Mon Oct 14 17:40:59 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 14 Oct 2013 17:40:59 -0700 Subject: RFR (XXS): 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set In-Reply-To: <525C6954.50601@oracle.com> References: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> <525C3B54.4050308@oracle.com> <4C846B39-1039-470C-B4E5-384F34A2069E@oracle.com> <525C6954.50601@oracle.com> Message-ID: <057A3ED8-6EB4-4A61-A99E-7C1C7D0E0F23@oracle.com> On Oct 14, 2013, at 2:59 PM, Vladimir Kozlov wrote: > For the record. Christian and I discussed it and decided to remove 'exception pc' load in deopt_blob on all platforms in separate changes. First, it is broken in x86 code anyway (it is not saved in all paths in deopt_blob). Second, we return into Interpreter which know nothing (and don't care) about compiled code and it does not use this pc data. Right. So the fix is: diff -r f50418dfb1b7 src/cpu/sparc/vm/sharedRuntime_sparc.cpp --- a/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Sun Oct 13 13:22:24 2013 -0700 +++ b/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Mon Oct 14 17:35:02 2013 -0700 @@ -3581,6 +3581,7 @@ void SharedRuntime::generate_deopt_blob( // the pending exception will be picked up the interpreter. __ ld_ptr(G2_thread, in_bytes(JavaThread::exception_oop_offset()), Oexception); __ st_ptr(G0, G2_thread, in_bytes(JavaThread::exception_oop_offset())); + __ st_ptr(G0, G2_thread, in_bytes(JavaThread::exception_pc_offset())); __ bind(noException); // deallocate the deoptimization frame taking care to preserve the return values Will file a bug for removing the load on all architectures. > > Thanks, > Vladimir > > On 10/14/13 2:17 PM, Christian Thalinger wrote: >> The reason I've added it is because we do it on x86 but there are comments like this: >> >> // I think this is useless (throwing pc?) >> __ movptr(rdx, Address(rsp, RegisterSaver::rdx_offset_in_bytes())); >> >> So we either should read it everywhere or don't. >> >> On Oct 14, 2013, at 11:43 AM, Vladimir Kozlov wrote: >> >>> Don't read exception pc since it is not needed. You may trash a value in that register. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/14/13 11:19 AM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8026376 >>>> http://cr.openjdk.java.net/~twisti/8026376/webrev.00/ >>>> >>>> 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set >>>> Reviewed-by: >>>> >>>> It made me suspicious that only the second assert fired (the exception pc check) and not the first one (the exception oop check). I checked all the places where JavaThread::exception_oop_offset() was used to clear the exception oop to see if we also clear the exception pc. >>>> >>>> In the deopt blob we have such a case. On x86 we clear both but on SPARC we don't. >>>> >>>> Added the missing null-store instruction makes the test case pass. >>>> >>>> Reading the exception pc is not really required but I've added it for completeness. >>>> >> From vladimir.kozlov at oracle.com Mon Oct 14 17:45:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 14 Oct 2013 17:45:06 -0700 Subject: RFR (XXS): 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set In-Reply-To: <057A3ED8-6EB4-4A61-A99E-7C1C7D0E0F23@oracle.com> References: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> <525C3B54.4050308@oracle.com> <4C846B39-1039-470C-B4E5-384F34A2069E@oracle.com> <525C6954.50601@oracle.com> <057A3ED8-6EB4-4A61-A99E-7C1C7D0E0F23@oracle.com> Message-ID: <525C9012.9060105@oracle.com> On 10/14/13 5:40 PM, Christian Thalinger wrote: > > On Oct 14, 2013, at 2:59 PM, Vladimir Kozlov wrote: > >> For the record. Christian and I discussed it and decided to remove 'exception pc' load in deopt_blob on all platforms in separate changes. First, it is broken in x86 code anyway (it is not saved in all paths in deopt_blob). Second, we return into Interpreter which know nothing (and don't care) about compiled code and it does not use this pc data. > > Right. So the fix is: Good. Vladimir > > diff -r f50418dfb1b7 src/cpu/sparc/vm/sharedRuntime_sparc.cpp > --- a/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Sun Oct 13 13:22:24 2013 -0700 > +++ b/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Mon Oct 14 17:35:02 2013 -0700 > @@ -3581,6 +3581,7 @@ void SharedRuntime::generate_deopt_blob( > // the pending exception will be picked up the interpreter. > __ ld_ptr(G2_thread, in_bytes(JavaThread::exception_oop_offset()), Oexception); > __ st_ptr(G0, G2_thread, in_bytes(JavaThread::exception_oop_offset())); > + __ st_ptr(G0, G2_thread, in_bytes(JavaThread::exception_pc_offset())); > __ bind(noException); > > // deallocate the deoptimization frame taking care to preserve the return values > > Will file a bug for removing the load on all architectures. > >> >> Thanks, >> Vladimir >> >> On 10/14/13 2:17 PM, Christian Thalinger wrote: >>> The reason I've added it is because we do it on x86 but there are comments like this: >>> >>> // I think this is useless (throwing pc?) >>> __ movptr(rdx, Address(rsp, RegisterSaver::rdx_offset_in_bytes())); >>> >>> So we either should read it everywhere or don't. >>> >>> On Oct 14, 2013, at 11:43 AM, Vladimir Kozlov wrote: >>> >>>> Don't read exception pc since it is not needed. You may trash a value in that register. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/14/13 11:19 AM, Christian Thalinger wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8026376 >>>>> http://cr.openjdk.java.net/~twisti/8026376/webrev.00/ >>>>> >>>>> 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set >>>>> Reviewed-by: >>>>> >>>>> It made me suspicious that only the second assert fired (the exception pc check) and not the first one (the exception oop check). I checked all the places where JavaThread::exception_oop_offset() was used to clear the exception oop to see if we also clear the exception pc. >>>>> >>>>> In the deopt blob we have such a case. On x86 we clear both but on SPARC we don't. >>>>> >>>>> Added the missing null-store instruction makes the test case pass. >>>>> >>>>> Reading the exception pc is not really required but I've added it for completeness. >>>>> >>> > From christian.thalinger at oracle.com Mon Oct 14 22:05:22 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 15 Oct 2013 05:05:22 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Message-ID: <20131015050527.A7C2A623C6@hg.openjdk.java.net> Changeset: e504cd481ec0 Author: twisti Date: 2013-10-14 19:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e504cd481ec0 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set Reviewed-by: kvn ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp From albert.noll at oracle.com Mon Oct 14 23:37:40 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 15 Oct 2013 08:37:40 +0200 Subject: RFR(XXS): 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice In-Reply-To: References: <525B8DED.1080505@oracle.com> Message-ID: <525CE2B4.3000902@oracle.com> Thank you, Christian. Best, Albert On 14.10.2013 20:27, Christian Thalinger wrote: > Looks good. > > On Oct 13, 2013, at 11:23 PM, Albert Noll > wrote: > >> Hi, >> >> could I get reviews for this small patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8025740 >> Webrev: http://cr.openjdk.java.net/~anoll/8025740/webrev.00/ >> >> >> problem: 'java -XX:ReservedCodeCacheSize=2049m -version' gives the >> following output. >> >> > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. >> > Invalid ReservedCodeCacheSize=2049M. Must be at most 2048M. >> >> Solution: Remove duplicate check of ReservedCodeCacheSize from >> Arguments::check_gc_consistency(). >> >> >> Best, >> Albert >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131015/1e75ec90/attachment-0001.html From roland.westrelin at oracle.com Tue Oct 15 03:31:44 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 Oct 2013 12:31:44 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <525C79EB.8040008@oracle.com> References: <525C79EB.8040008@oracle.com> Message-ID: <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> Hi Vladimir, Thanks for reviewing this. > Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: > _inline_cg->generate(jvms, NULL); What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? > In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? You're right. We don't need to care about intrinsics. So in GraphKit::replace_in_map(). this: if (parser == NULL) { parser = parent_parser(); } is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. > Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. > > And I don't understand where 1) requirement comes from. If we have something like this: void m(A a) { if (some_condition) { B b = (B)a; } else { // some other stuff } } then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. Roland. > > I am fine with moving is_uncommon_trap_*() mathods. > > Thanks, > Vladimir > > On 10/12/13 2:31 PM, Roland Westrelin wrote: >> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >> >> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >> >> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >> >> Roland. >> From albert.noll at oracle.com Tue Oct 15 04:14:23 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 15 Oct 2013 13:14:23 +0200 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken Message-ID: <525D238F.2080501@oracle.com> Hi, could I have reviews for this small patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ Problem: This flag is broken. The reason is that adapters (gen_i2c_adapter()) that are generated during VM startup do not include the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is specified. StubRoutines::code2() is only allocated later during startup; consequently, code2() is NULL. As a result, the size of the generated adapter as well as the code itself does not mactch. Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. Note that this patch also fixes potential issues with -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also removes some unused field of VerifyAdapterSharing. Many thanks in advance, Albert ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131015/ca9c5829/attachment.html From roland.westrelin at oracle.com Tue Oct 15 08:18:16 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 Oct 2013 17:18:16 +0200 Subject: RFR (XXS): 8026376: assert(false) failed: DEBUG MESSAGE: exception pc already set In-Reply-To: <057A3ED8-6EB4-4A61-A99E-7C1C7D0E0F23@oracle.com> References: <5F4D3463-6C89-45C3-8EB5-9BA4A5247C4A@oracle.com> <525C3B54.4050308@oracle.com> <4C846B39-1039-470C-B4E5-384F34A2069E@oracle.com> <525C6954.50601@oracle.com> <057A3ED8-6EB4-4A61-A99E-7C1C7D0E0F23@oracle.com> Message-ID: > Right. So the fix is: > > diff -r f50418dfb1b7 src/cpu/sparc/vm/sharedRuntime_sparc.cpp > --- a/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Sun Oct 13 13:22:24 2013 -0700 > +++ b/src/cpu/sparc/vm/sharedRuntime_sparc.cpp Mon Oct 14 17:35:02 2013 -0700 > @@ -3581,6 +3581,7 @@ void SharedRuntime::generate_deopt_blob( > // the pending exception will be picked up the interpreter. > __ ld_ptr(G2_thread, in_bytes(JavaThread::exception_oop_offset()), Oexception); > __ st_ptr(G0, G2_thread, in_bytes(JavaThread::exception_oop_offset())); > + __ st_ptr(G0, G2_thread, in_bytes(JavaThread::exception_pc_offset())); > __ bind(noException); > > // deallocate the deoptimization frame taking care to preserve the return values That looks good to me. Roland. From christian.thalinger at oracle.com Tue Oct 15 10:23:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Oct 2013 10:23:45 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> Message-ID: On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: > > On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: > >> You don't need 'if()': >> >> + if (mem->is_MergeMem()) { >> + while (mem->is_MergeMem()) { >> > ok > >> Typo "the have" ("it is"?): >> >> + // now let it fall though, and see if the have a projection >> > yup "though" should be "through"? > >> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >> > > Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. > > Thanks! > igor > >> Thanks, >> Vladimir >> >> On 10/14/13 1:57 PM, Igor Veresov wrote: >>> Hi guys, >>> >>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>> >>> Testing: jtreg, CTW, the failing tests >>> >>> igor >>> >>> > From vladimir.kozlov at oracle.com Tue Oct 15 10:29:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 10:29:52 -0700 Subject: RFR(XS) 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 In-Reply-To: <2F63C163-0D4A-4BF3-9F2D-572E6C335537@oracle.com> References: <0D129F1B-F0D2-408E-918D-A4D1C0932152@oracle.com> <524F0F29.3070800@oracle.com> <52530BFC.9040201@oracle.com> <99538B19-F440-4662-8058-B07AAEA96ACD@oracle.com> <8AFB52A5-5C84-447C-99E8-6B8D8B08C8DB@oracle.com> <5DD8E629-F284-4BFB-A9D5-B04D4522A8B7@oracle.com> <525835A9.6010709@oracle.com> <2F63C163-0D4A-4BF3-9F2D-572E6C335537@oracle.com> Message-ID: <525D7B90.6060209@oracle.com> Good. (Sorry, I thought I reviewed this already) Vladimir On 10/14/13 12:44 AM, Rickard B?ckman wrote: > Christian & Vladimir, > > I added both: http://cr.openjdk.java.net/~rbackman/8025657.5/webrev/ > > Thanks > /R > > On Oct 11, 2013, at 8:03 PM, Christian Thalinger wrote: > >> >> On Oct 11, 2013, at 10:30 AM, Vladimir Kozlov wrote: >> >>> Rickard, >>> >>> First about double addExact(). I was worried about FlagsProj will have two users so that flags->unique_out() will throw assert. But it looks like IfNode::Ideal eliminated second IfNode since inputs are the same. So it may be fine and we did not see failures like this in testing. >>> >>> About changes. I think they good. Can you add MathExactNode::iff_node() and use it instead of duplications? >> >> Perhaps also MathExactNode::bool_node() since you need that one too. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/11/13 5:53 AM, Rickard B?ckman wrote: >>>> And someone pointed out that I don't need to have Verify.java in @compile. >>>> >>>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.4/ >>>> >>>> Thanks >>>> /R >>>> >>>> On Oct 11, 2013, at 1:53 PM, Rickard B?ckman wrote: >>>> >>>>> Forgot to include a new test case. >>>>> >>>>> Updated: http://cr.openjdk.java.net/~rbackman/8025657.3/ >>>>> >>>>> /R >>>>> >>>>> On Oct 11, 2013, at 1:04 PM, Rickard B?ckman wrote: >>>>> >>>>>> Vladimir, >>>>>> >>>>>> Setting the control edge for addExact and then setting the control edge for everyone who depends on the >>>>>> result from the addExact to the non throwing edge of the If that is consuming the flags from addExact makes the tests pass. No need to make the machnode pinned. Doing that only created more problems. >>>>>> >>>>>> GVN works fine since we have an uncommon trap. So GVN will replace the AddExact, Flags and ResultProj with those of the previous one. That produces code like: >>>>>> >>>>>> add rax, rdx >>>>>> jo ?. >>>>>> add rax, rax >>>>>> >>>>>> for java code: >>>>>> >>>>>> result = addExact(x, y) >>>>>> result += addExact(x, y) >>>>>> >>>>>> Here is an updated webrev: http://cr.openjdk.java.net/~rbackman/8025657.2/ >>>>>> >>>>>> Thanks >>>>>> /R >>>>>> >>>>>> On Oct 7, 2013, at 9:31 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> Rickard, >>>>>>> >>>>>>> Your code is correct. What I am trying to understand is it possible to make it more general and not just hack for mathExact. >>>>>>> Also if we set control edge to addExact node (for example, during final_graph_reshape). And make its machnode pinned (in adlc InstructForm::is_pinned()). Will current gcm code work then? >>>>>>> >>>>>>> Speaking of cotrol edge for these nodes. You allow gvn these nodes (you have hash() method). But is this correct? What happens for duplicated code when inputs are the same? >>>>>>> >>>>>>> addExact(x,y) >>>>>>> addExact(x,y) >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/6/13 10:13 PM, Rickard B?ckman wrote: >>>>>>>> Vladimir, >>>>>>>> >>>>>>>> both addExact and FlagsProj are in must_clone. It means they have to be close to use, but since there are 2 >>>>>>>> uses of addExact this seems to be problematic. >>>>>>>> >>>>>>>> The code in schedule_pinned_nodes takes the addExact and FlagsProj and schedules them into the same block as the jump on overflow. It seems correct to me. >>>>>>>> >>>>>>>> Thank you >>>>>>>> /R >>>>>>>> >>>>>>>> On Oct 4, 2013, at 8:55 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> Rickard, >>>>>>>>> >>>>>>>>> addExact, should in must_clone[] list since it produce flag (I think your original changes have it). With that it should be scheduled near use (see PhaseCFG::schedule_late()). The problem could be it has 2 uses. >>>>>>>>> >>>>>>>>> FlagsProj should be scheduled near consumer of the flag (since it is also in must_clone[]). Otherwise flags state could be changes by other instructions. So moving it to addExact block is wrong. It should be opposite: addExact should at the same block as FlagsProj and conditional jump. >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/4/13 4:35 AM, Rickard B?ckman wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I would appreciate some reviews on this change. >>>>>>>>>> >>>>>>>>>> On some machines when running with -XX:+DeoptimizeALot a test (test/compiler/intrinsics/mathexact/ConstantTest.java) failed with an assert. >>>>>>>>>> assert(idx >= 0) failed: index should be set >>>>>>>>>> >>>>>>>>>> It seems that gcm would put the addExact in a different block then the jump. >>>>>>>>>> This change forces the producer of FlagsProjNode to be in the same block as >>>>>>>>>> the consumer. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025657 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8025657.1/ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> /R >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> > From christian.thalinger at oracle.com Tue Oct 15 10:31:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Oct 2013 10:31:34 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <525D238F.2080501@oracle.com> References: <525D238F.2080501@oracle.com> Message-ID: The change looks good. Did you remove saving the signature because it wasn't used anyway? On an unrelated note but I hate these field names: static BufferBlob* _code1; // code buffer for initial routines static BufferBlob* _code2; // code buffer for all other routines Could you file an RFE to rename these two? On Oct 15, 2013, at 4:14 AM, Albert Noll wrote: > Hi, > > could I have reviews for this small patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 > webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ > > Problem: This flag is broken. The reason is that adapters (gen_i2c_adapter()) that are generated during VM startup do not include the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is specified. StubRoutines::code2() is only allocated later during startup; consequently, code2() is NULL. As a result, the size of the generated adapter as well as the code itself does not mactch. > > Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. Note that this patch also fixes potential issues with -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also removes some unused field of VerifyAdapterSharing. > > > Many thanks in advance, > Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131015/361b6bca/attachment-0001.html From vladimir.kozlov at oracle.com Tue Oct 15 10:52:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 10:52:03 -0700 Subject: RFR (XXS): 8026293: Schedule part of G1 pre-barrier late In-Reply-To: <523CDC39.4050003@oracle.com> References: <523CDC39.4050003@oracle.com> Message-ID: <525D80C3.5020604@oracle.com> http://cr.openjdk.java.net/~kvn/8026293/webrev/ https://bugs.openjdk.java.net/browse/JDK-8026293 A large part of the G1 write barrier is only used during marking, hence the code it not commonly executed. To make the active code segments smaller and better fit the cache these unused segments should be schedule outside of the common path. Setting the the first branch of the pre-barrier check to be unlikely will make the compiler treat the barrier code as cold and hence schedule it outside of the hot path. Contributed by Staffan Friberg. Tested JPRT, jtreg, SPECJEnt, SPECJBB. Thanks, Vladimir From christian.thalinger at oracle.com Tue Oct 15 11:10:12 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Oct 2013 11:10:12 -0700 Subject: RFR (XXS): 8026293: Schedule part of G1 pre-barrier late In-Reply-To: <525D80C3.5020604@oracle.com> References: <523CDC39.4050003@oracle.com> <525D80C3.5020604@oracle.com> Message-ID: <31455B88-72F0-41A8-BE89-D99EE3295C2B@oracle.com> Looks good. On Oct 15, 2013, at 10:52 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8026293/webrev/ > > https://bugs.openjdk.java.net/browse/JDK-8026293 > > A large part of the G1 write barrier is only used during marking, hence the code it not commonly executed. > To make the active code segments smaller and better fit the cache these unused segments should be schedule outside of the common path. > Setting the the first branch of the pre-barrier check to be unlikely will make the compiler treat the barrier code as cold and hence schedule it outside of the hot path. > > Contributed by Staffan Friberg. > > Tested JPRT, jtreg, SPECJEnt, SPECJBB. > > Thanks, > Vladimir > > > > > > > > > > > > > > > > > > > > > > > > > From roland.westrelin at oracle.com Tue Oct 15 11:13:09 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 15 Oct 2013 20:13:09 +0200 Subject: RFR (XXS): 8026293: Schedule part of G1 pre-barrier late In-Reply-To: <525D80C3.5020604@oracle.com> References: <523CDC39.4050003@oracle.com> <525D80C3.5020604@oracle.com> Message-ID: <985C2DB9-C498-4B0D-BE89-87725D19BDE4@oracle.com> > http://cr.openjdk.java.net/~kvn/8026293/webrev/ That looks good to me. Roland. From christian.thalinger at oracle.com Tue Oct 15 11:29:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Oct 2013 11:29:25 -0700 Subject: RFR(S) : 8026414 : [TESTBUG] Tests for Tiered/NonTiered levels In-Reply-To: <525C4205.1060404@oracle.com> References: <525C4205.1060404@oracle.com> Message-ID: <165330A8-A107-4991-B438-E51EB69883F2@oracle.com> Looks good. Nice usage of lambda :-) On Oct 14, 2013, at 12:12 PM, Igor Ignatyev wrote: > Hi all, > > Please review patch: > > New tests for TieredCompilation were developed. > Tests verify that only 4(1) level is used when Tiered is disabled and all otherwise. > > webrev: http://cr.openjdk.java.net/~iignatyev/8026414/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8026414 > testing: compiler/tiered w/ default flags and w/ the same flags as in nightly > -- > Best regards, > Igor Ignatyev From christian.thalinger at oracle.com Tue Oct 15 11:50:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 15 Oct 2013 11:50:15 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: References: Message-ID: <090EEAB6-FDB5-414C-BC9A-E0484DC27B4B@oracle.com> On Oct 12, 2013, at 2:31 PM, Roland Westrelin wrote: > The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. > > When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. What if we would do a deep-clone? Are there any potential performance or memory issues? > The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. > > http://cr.openjdk.java.net/~roland/8024069/webrev.00/ > > Roland. From vladimir.kozlov at oracle.com Tue Oct 15 12:03:48 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 12:03:48 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <525D238F.2080501@oracle.com> References: <525D238F.2080501@oracle.com> Message-ID: <525D9194.3070403@oracle.com> Albert, contains_all_stubs name is incorrect. It should be contains_all_checks. Adapter code does not have stubs in it. I think the next check should be: bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; because code does not change when VerifyAdapterCalls is false. Then you don't need to check VerifyAdapterCalls in next condition: + if ((VerifyAdapterCalls || VerifyAdapterSharing) && !entry->contains_all_checks()) { And we need to regenerate adapter regardless VerifyAdapterSharing because, as you said, VerifyAdapterCalls potentially reports a false error if check for code2 is not generated. So the condition should be simple "if (!entry->contains_all_checks())". Could you leave next lines unchanged (use 2 lines for arguments)?: ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, sizeof(buffer_locs)/sizeof(relocInfo)); MacroAssembler _masm(&buffer); Cleanup is fine. Thanks, Vladimir On 10/15/13 4:14 AM, Albert Noll wrote: > Hi, > > could I have reviews for this small patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 > webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ > > > Problem: This flag is broken. The reason is that adapters > (gen_i2c_adapter()) that are generated during VM startup do not include > the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is > specified. StubRoutines::code2() is only allocated later during startup; > consequently, code2() is NULL. As a result, the size of the generated > adapter as well as the code itself does not mactch. > > Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. > Note that this patch also fixes potential issues with > -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also > removes some unused field of VerifyAdapterSharing. > > > Many thanks in advance, > Albert > ** From vladimir.kozlov at oracle.com Tue Oct 15 12:07:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 12:07:29 -0700 Subject: RFR (XXS): 8026293: Schedule part of G1 pre-barrier late In-Reply-To: <985C2DB9-C498-4B0D-BE89-87725D19BDE4@oracle.com> References: <523CDC39.4050003@oracle.com> <525D80C3.5020604@oracle.com> <985C2DB9-C498-4B0D-BE89-87725D19BDE4@oracle.com> Message-ID: <525D9271.7090201@oracle.com> Thank you Roland and Christian for reviews. Vladimir On 10/15/13 11:13 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8026293/webrev/ > > That looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Tue Oct 15 13:59:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 13:59:36 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> Message-ID: <525DACB8.9070400@oracle.com> On 10/14/13 2:19 PM, Roland Westrelin wrote: > > On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: > >> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> Thanks for the comments. >>> >>>> I wish you added more comments to the code. >>> >>> Do you want me to send another webrev? >> >> I would wait review from Christian before updating webrev. >> >>> >>>> >>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>> >>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>> >>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >> >> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >> >> arg = x->profiled_arg_at(i); > > Yes. Okay. Thanks, Vladimir > > Roland. > >> >> Vladimir >> >>> >>>> methodData.cpp Rename args_cell to params_cell: >>>> >>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>> + if (args_cell > 0) { >>> >>> Ok. >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>> The last of the series of new type profiling points. >>>>> >>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>> >>>>> The output of PrintMethodData is: >>>>> >>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>> interpreter_invocation_count: 5000 >>>>> invocation_counter: 5000 >>>>> backedge_counter: 0 >>>>> mdo size: 444 bytes >>>>> >>>>> parameter types 0: stack(0) 'TestProfiling' >>>>> 1: stack(1) 'TestProfiling$A' >>>>> >>>>> Roland. >>>>> >>> > From vladimir.kozlov at oracle.com Tue Oct 15 14:52:11 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 14:52:11 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> Message-ID: <525DB90B.5010800@oracle.com> On 10/15/13 3:31 AM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > >> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >> _inline_cg->generate(jvms, NULL); > > What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? Yes, you are right. But you still have exit.jvms in which you can do replacement. > >> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? > > You're right. We don't need to care about intrinsics. > > So in GraphKit::replace_in_map(). this: > > if (parser == NULL) { > parser = parent_parser(); > } > > is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. > >> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. > > I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. > >> >> And I don't understand where 1) requirement comes from. > > If we have something like this: > > void m(A a) { > if (some_condition) { > B b = (B)a; > } else { > // some other stuff > } > } > > then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. What about this case? We should be keeping the cast: void m(A a) { if (some_condition) { // some other stuff } B b = (B)a; } I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). Thanks, Vladimir > > Roland. > >> >> I am fine with moving is_uncommon_trap_*() mathods. >> >> Thanks, >> Vladimir >> >> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>> >>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>> >>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>> >>> Roland. >>> > From christian.thalinger at oracle.com Tue Oct 15 17:43:34 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Wed, 16 Oct 2013 00:43:34 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Message-ID: <20131016004336.28B746242F@hg.openjdk.java.net> Changeset: 8df6f123d35e Author: drchase Date: 2013-10-12 17:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8df6f123d35e 8026124: JSR-292 bug: java.nio.file.Path.toString cores dump Summary: catch problem case, assert it matches valid input, new test Reviewed-by: jrose, twisti, kvn ! src/share/vm/interpreter/linkResolver.cpp + test/compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java + test/compiler/jsr292/createsInterfaceDotEqualsCallInfo.js From vladimir.kozlov at oracle.com Tue Oct 15 20:19:40 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 16 Oct 2013 03:19:40 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131016031947.9B84562436@hg.openjdk.java.net> Changeset: f91a9a696e5e Author: kvn Date: 2013-10-15 12:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f91a9a696e5e 8026293: Schedule part of G1 pre-barrier late Summary: move rare executed part of G1 write barrier from hot path. Reviewed-by: kvn, twisti, roland Contributed-by: staffan.friberg at oracle.com ! src/share/vm/opto/graphKit.cpp Changeset: 1263c7e17e1c Author: kvn Date: 2013-10-15 17:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1263c7e17e1c Merge From albert.noll at oracle.com Tue Oct 15 22:55:12 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 16 Oct 2013 07:55:12 +0200 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <525D9194.3070403@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> Message-ID: <525E2A40.4070104@oracle.com> Christian, Vladimir, thanks for the reviews. @Christian: yes, I removed the signature since it was unused. I'll file an RFE to rename the two fields. @Vladimir: your suggestions make the code simpler. I adopted them in the new webrev. http://cr.openjdk.java.net/~anoll/8026478/webrev.01/ Best, Albert On 15.10.2013 21:03, Vladimir Kozlov wrote: > Albert, > > contains_all_stubs name is incorrect. It should be > contains_all_checks. Adapter code does not have stubs in it. > > I think the next check should be: > > bool contains_all_checks = (StubRoutines::code2() != NULL) || > !VerifyAdapterCalls; > > because code does not change when VerifyAdapterCalls is false. > Then you don't need to check VerifyAdapterCalls in next condition: > > + if ((VerifyAdapterCalls || VerifyAdapterSharing) && > !entry->contains_all_checks()) { > > And we need to regenerate adapter regardless VerifyAdapterSharing > because, as you said, VerifyAdapterCalls potentially reports a false > error if check for code2 is not generated. > > So the condition should be simple "if (!entry->contains_all_checks())". > > Could you leave next lines unchanged (use 2 lines for arguments)?: > ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > > sizeof(buffer_locs)/sizeof(relocInfo)); > MacroAssembler _masm(&buffer); > > Cleanup is fine. > > Thanks, > Vladimir > > On 10/15/13 4:14 AM, Albert Noll wrote: >> Hi, >> >> could I have reviews for this small patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >> >> >> Problem: This flag is broken. The reason is that adapters >> (gen_i2c_adapter()) that are generated during VM startup do not include >> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >> specified. StubRoutines::code2() is only allocated later during startup; >> consequently, code2() is NULL. As a result, the size of the generated >> adapter as well as the code itself does not mactch. >> >> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >> Note that this patch also fixes potential issues with >> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >> removes some unused field of VerifyAdapterSharing. >> >> >> Many thanks in advance, >> Albert >> ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131016/bf626f45/attachment-0001.html From albert.noll at oracle.com Tue Oct 15 23:02:57 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 16 Oct 2013 08:02:57 +0200 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <525D9194.3070403@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> Message-ID: <525E2C11.9050100@oracle.com> Forgot to adjust the comment. This version should be fine. http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ Albert On 15.10.2013 21:03, Vladimir Kozlov wrote: > Albert, > > contains_all_stubs name is incorrect. It should be > contains_all_checks. Adapter code does not have stubs in it. > > I think the next check should be: > > bool contains_all_checks = (StubRoutines::code2() != NULL) || > !VerifyAdapterCalls; > > because code does not change when VerifyAdapterCalls is false. > Then you don't need to check VerifyAdapterCalls in next condition: > > + if ((VerifyAdapterCalls || VerifyAdapterSharing) && > !entry->contains_all_checks()) { > > And we need to regenerate adapter regardless VerifyAdapterSharing > because, as you said, VerifyAdapterCalls potentially reports a false > error if check for code2 is not generated. > > So the condition should be simple "if (!entry->contains_all_checks())". > > Could you leave next lines unchanged (use 2 lines for arguments)?: > ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > > sizeof(buffer_locs)/sizeof(relocInfo)); > MacroAssembler _masm(&buffer); > > Cleanup is fine. > > Thanks, > Vladimir > > On 10/15/13 4:14 AM, Albert Noll wrote: >> Hi, >> >> could I have reviews for this small patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >> >> >> Problem: This flag is broken. The reason is that adapters >> (gen_i2c_adapter()) that are generated during VM startup do not include >> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >> specified. StubRoutines::code2() is only allocated later during startup; >> consequently, code2() is NULL. As a result, the size of the generated >> adapter as well as the code itself does not mactch. >> >> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >> Note that this patch also fixes potential issues with >> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >> removes some unused field of VerifyAdapterSharing. >> >> >> Many thanks in advance, >> Albert >> ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131016/c4f2298f/attachment.html From vladimir.kozlov at oracle.com Tue Oct 15 23:16:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 15 Oct 2013 23:16:09 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <525E2A40.4070104@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2A40.4070104@oracle.com> Message-ID: <525E2F29.1000401@oracle.com> Good. Thanks, Vladimir On 10/15/13 10:55 PM, Albert Noll wrote: > Christian, Vladimir, thanks for the reviews. > > @Christian: yes, I removed the signature since it was unused. I'll file an RFE to rename the two fields. > @Vladimir: your suggestions make the code simpler. I adopted them in the new webrev. > > http://cr.openjdk.java.net/~anoll/8026478/webrev.01/ > > Best, > Albert > > On 15.10.2013 21:03, Vladimir Kozlov wrote: >> Albert, >> >> contains_all_stubs name is incorrect. It should be contains_all_checks. Adapter code does not have stubs in it. >> >> I think the next check should be: >> >> bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; >> >> because code does not change when VerifyAdapterCalls is false. >> Then you don't need to check VerifyAdapterCalls in next condition: >> >> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && !entry->contains_all_checks()) { >> >> And we need to regenerate adapter regardless VerifyAdapterSharing because, as you said, VerifyAdapterCalls potentially >> reports a false error if check for code2 is not generated. >> >> So the condition should be simple "if (!entry->contains_all_checks())". >> >> Could you leave next lines unchanged (use 2 lines for arguments)?: >> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >> >> sizeof(buffer_locs)/sizeof(relocInfo)); >> MacroAssembler _masm(&buffer); >> >> Cleanup is fine. >> >> Thanks, >> Vladimir >> >> On 10/15/13 4:14 AM, Albert Noll wrote: >>> Hi, >>> >>> could I have reviews for this small patch? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>> >>> >>> Problem: This flag is broken. The reason is that adapters >>> (gen_i2c_adapter()) that are generated during VM startup do not include >>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>> specified. StubRoutines::code2() is only allocated later during startup; >>> consequently, code2() is NULL. As a result, the size of the generated >>> adapter as well as the code itself does not mactch. >>> >>> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >>> Note that this patch also fixes potential issues with >>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>> removes some unused field of VerifyAdapterSharing. >>> >>> >>> Many thanks in advance, >>> Albert >>> ** > From roland.westrelin at oracle.com Wed Oct 16 00:15:04 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 Oct 2013 09:15:04 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <525DB90B.5010800@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> Message-ID: On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: > On 10/15/13 3:31 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >> Thanks for reviewing this. >> >>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>> _inline_cg->generate(jvms, NULL); >> >> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? > > Yes, you are right. But you still have exit.jvms in which you can do replacement. Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. > >> >>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >> >> You're right. We don't need to care about intrinsics. >> >> So in GraphKit::replace_in_map(). this: >> >> if (parser == NULL) { >> parser = parent_parser(); >> } >> >> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >> >>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >> >> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >> >>> >>> And I don't understand where 1) requirement comes from. >> >> If we have something like this: >> >> void m(A a) { >> if (some_condition) { >> B b = (B)a; >> } else { >> // some other stuff >> } >> } >> >> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. > > What about this case? We should be keeping the cast: > > void m(A a) { > if (some_condition) { > // some other stuff > } > B b = (B)a; > } > This case we could handle in my change by skipping over simple ifs. > I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. void m(A a) { B b = (B)b; // maybe some more stuff after } If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. Roland. > > Thanks, > Vladimir > >> >> Roland. >> >>> >>> I am fine with moving is_uncommon_trap_*() mathods. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>> >>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>> >>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>> >>>> Roland. >>>> >> From rickard.backman at oracle.com Wed Oct 16 00:24:46 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Wed, 16 Oct 2013 07:24:46 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Message-ID: <20131016072452.023E762448@hg.openjdk.java.net> Changeset: 4a2acfb16e97 Author: rbackman Date: 2013-10-11 12:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4a2acfb16e97 8025657: compiler/intrinsics/mathexact/ConstantTest.java fails on assert in lcm.cpp on solaris x64 Reviewed-by: kvn, twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp + test/compiler/intrinsics/mathexact/RepeatTest.java From vladimir.kozlov at oracle.com Wed Oct 16 00:29:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 00:29:25 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> Message-ID: <525E4055.6090508@oracle.com> Roland, I know we are rushing currently so we don't have time to do proper generic fix. Can you do it only for JSR292 methods where you see this pattern and preferably under flag? The less we change common code now is better. Thanks, Vladimir On 10/16/13 12:15 AM, Roland Westrelin wrote: > > On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: > >> On 10/15/13 3:31 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> Thanks for reviewing this. >>> >>>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>>> _inline_cg->generate(jvms, NULL); >>> >>> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? >> >> Yes, you are right. But you still have exit.jvms in which you can do replacement. > > Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. > >> >>> >>>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >>> >>> You're right. We don't need to care about intrinsics. >>> >>> So in GraphKit::replace_in_map(). this: >>> >>> if (parser == NULL) { >>> parser = parent_parser(); >>> } >>> >>> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >>> >>>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >>> >>> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >>> >>>> >>>> And I don't understand where 1) requirement comes from. >>> >>> If we have something like this: >>> >>> void m(A a) { >>> if (some_condition) { >>> B b = (B)a; >>> } else { >>> // some other stuff >>> } >>> } >>> >>> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. >> >> What about this case? We should be keeping the cast: >> >> void m(A a) { >> if (some_condition) { >> // some other stuff >> } >> B b = (B)a; >> } >> > > This case we could handle in my change by skipping over simple ifs. > >> I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). > > > For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. > > void m(A a) { > B b = (B)b; > // maybe some more stuff after > } > > If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. > > Roland. > >> >> Thanks, >> Vladimir >> >>> >>> Roland. >>> >>>> >>>> I am fine with moving is_uncommon_trap_*() mathods. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>>> >>>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>>> >>>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>>> >>>>> Roland. >>>>> >>> > From roland.westrelin at oracle.com Wed Oct 16 00:42:26 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 Oct 2013 09:42:26 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <525E4055.6090508@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> <525E4055.6090508@oracle.com> Message-ID: <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> On Oct 16, 2013, at 9:29 AM, Vladimir Kozlov wrote: > Roland, > > I know we are rushing currently so we don't have time to do proper generic fix. > Can you do it only for JSR292 methods where you see this pattern and preferably under flag? > The less we change common code now is better. What about I don't try to restrict it to JSR292 methods (I'm concerned that if I'm too restrictive we can't even turn it on to see if it helps) but put it under a flag that is off by default? And then when type speculation is on, turning type speculation on turns this on as well? Roland. > > Thanks, > Vladimir > > On 10/16/13 12:15 AM, Roland Westrelin wrote: >> >> On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: >> >>> On 10/15/13 3:31 AM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for reviewing this. >>>> >>>>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>>>> _inline_cg->generate(jvms, NULL); >>>> >>>> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? >>> >>> Yes, you are right. But you still have exit.jvms in which you can do replacement. >> >> Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. >> >>> >>>> >>>>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >>>> >>>> You're right. We don't need to care about intrinsics. >>>> >>>> So in GraphKit::replace_in_map(). this: >>>> >>>> if (parser == NULL) { >>>> parser = parent_parser(); >>>> } >>>> >>>> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >>>> >>>>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >>>> >>>> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >>>> >>>>> >>>>> And I don't understand where 1) requirement comes from. >>>> >>>> If we have something like this: >>>> >>>> void m(A a) { >>>> if (some_condition) { >>>> B b = (B)a; >>>> } else { >>>> // some other stuff >>>> } >>>> } >>>> >>>> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. >>> >>> What about this case? We should be keeping the cast: >>> >>> void m(A a) { >>> if (some_condition) { >>> // some other stuff >>> } >>> B b = (B)a; >>> } >>> >> >> This case we could handle in my change by skipping over simple ifs. >> >>> I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). >> >> >> For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. >> >> void m(A a) { >> B b = (B)b; >> // maybe some more stuff after >> } >> >> If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Roland. >>>> >>>>> >>>>> I am fine with moving is_uncommon_trap_*() mathods. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>>>> >>>>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>>>> >>>>>> Roland. >>>>>> >>>> >> From vladimir.kozlov at oracle.com Wed Oct 16 01:00:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 01:00:35 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> <525E4055.6090508@oracle.com> <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> Message-ID: <525E47A3.80103@oracle.com> On 10/16/13 12:42 AM, Roland Westrelin wrote: > > On Oct 16, 2013, at 9:29 AM, Vladimir Kozlov wrote: > >> Roland, >> >> I know we are rushing currently so we don't have time to do proper generic fix. >> Can you do it only for JSR292 methods where you see this pattern and preferably under flag? >> The less we change common code now is better. > > What about I don't try to restrict it to JSR292 methods (I'm concerned that if I'm too restrictive we can't even turn it on to see if it helps) but put it under a flag that is off by default? And then when type speculation is on, turning type speculation on turns this on as well? Yes, it is fine under flag. Vladimir > > Roland. > >> >> Thanks, >> Vladimir >> >> On 10/16/13 12:15 AM, Roland Westrelin wrote: >>> >>> On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: >>> >>>> On 10/15/13 3:31 AM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thanks for reviewing this. >>>>> >>>>>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>>>>> _inline_cg->generate(jvms, NULL); >>>>> >>>>> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? >>>> >>>> Yes, you are right. But you still have exit.jvms in which you can do replacement. >>> >>> Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. >>> >>>> >>>>> >>>>>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >>>>> >>>>> You're right. We don't need to care about intrinsics. >>>>> >>>>> So in GraphKit::replace_in_map(). this: >>>>> >>>>> if (parser == NULL) { >>>>> parser = parent_parser(); >>>>> } >>>>> >>>>> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >>>>> >>>>>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >>>>> >>>>> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >>>>> >>>>>> >>>>>> And I don't understand where 1) requirement comes from. >>>>> >>>>> If we have something like this: >>>>> >>>>> void m(A a) { >>>>> if (some_condition) { >>>>> B b = (B)a; >>>>> } else { >>>>> // some other stuff >>>>> } >>>>> } >>>>> >>>>> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. >>>> >>>> What about this case? We should be keeping the cast: >>>> >>>> void m(A a) { >>>> if (some_condition) { >>>> // some other stuff >>>> } >>>> B b = (B)a; >>>> } >>>> >>> >>> This case we could handle in my change by skipping over simple ifs. >>> >>>> I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). >>> >>> >>> For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. >>> >>> void m(A a) { >>> B b = (B)b; >>> // maybe some more stuff after >>> } >>> >>> If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> I am fine with moving is_uncommon_trap_*() mathods. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>>>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>>>>> >>>>>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>>>>> >>>>>>> Roland. >>>>>>> >>>>> >>> > From roland.westrelin at oracle.com Wed Oct 16 02:23:17 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 Oct 2013 11:23:17 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <090EEAB6-FDB5-414C-BC9A-E0484DC27B4B@oracle.com> References: <090EEAB6-FDB5-414C-BC9A-E0484DC27B4B@oracle.com> Message-ID: On Oct 15, 2013, at 8:50 PM, Christian Thalinger wrote: > > On Oct 12, 2013, at 2:31 PM, Roland Westrelin wrote: > >> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >> >> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. > > What if we would do a deep-clone? Are there any potential performance or memory issues? What this change targets is stuff happening during inlining. Inlining is not performed from within a PreserveJVMState. So the PreserveJVMState case is not something we want to optimize for. We just want to make sure a replace_in_map called from within a PreserveJVMState doesn't break something. Roland. > >> The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >> >> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >> >> Roland. > From igor.veresov at oracle.com Wed Oct 16 06:27:00 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Oct 2013 06:27:00 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> Message-ID: Yup, thanks! igor On Oct 15, 2013, at 10:23 AM, Christian Thalinger wrote: > > On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: > >> >> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: >> >>> You don't need 'if()': >>> >>> + if (mem->is_MergeMem()) { >>> + while (mem->is_MergeMem()) { >>> >> ok >> >>> Typo "the have" ("it is"?): >>> >>> + // now let it fall though, and see if the have a projection >>> >> yup > > "though" should be "through"? > >> >>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >>> >> >> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. >> >> Thanks! >> igor >> >>> Thanks, >>> Vladimir >>> >>> On 10/14/13 1:57 PM, Igor Veresov wrote: >>>> Hi guys, >>>> >>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>>> >>>> Testing: jtreg, CTW, the failing tests >>>> >>>> igor >>>> >>>> >> > From igor.veresov at oracle.com Wed Oct 16 07:18:01 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Oct 2013 07:18:01 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> Message-ID: I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify. Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/ igor On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: > > On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: > >> You don't need 'if()': >> >> + if (mem->is_MergeMem()) { >> + while (mem->is_MergeMem()) { >> > ok > >> Typo "the have" ("it is"?): >> >> + // now let it fall though, and see if the have a projection >> > yup > >> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >> > > Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. > > Thanks! > igor > >> Thanks, >> Vladimir >> >> On 10/14/13 1:57 PM, Igor Veresov wrote: >>> Hi guys, >>> >>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>> >>> Testing: jtreg, CTW, the failing tests >>> >>> igor >>> >>> > From niclas.adlertz at oracle.com Wed Oct 16 07:32:41 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 16 Oct 2013 16:32:41 +0200 Subject: RFR(XS) 8022783: Nashorn test fails with: assert(!def_outside->member(r)) Message-ID: <525EA389.7040902@oracle.com> Hi all, Despite the fact that I have not been able to reproduce JDK-8022783, it generates the same error as many other bugs; JDK-7033056, JDK-8016269, JDK-8011770, JDK-8005956, JDK-8016157 and JDK-7196566. They are all related to re-materialization. One major concern when re-materializing is that each input node to the re-materialized node might need to have its live range 'L' stretched. If 'L' is defined at multiple places (due to coalescing), we might stretch one definition of 'L' beyond another definition. Currently we handle this by doing a private copy of the input in the same block as the node that is being re-materialized. This happens at the beginning of PhaseChaitin::Split_Rematerialize: // The input live ranges will be stretched to the site of the new // instruction. They might be stretched past a def and will thus // have the old and new values of the same live range alive at the // same time - a definite no-no. Split out private copies of // the inputs. if( def->req() > 1 ) { for( uint i = 1; i < def->req(); i++ ) { Node *in = def->in(i); // Check for single-def (LRG cannot redefined) uint lidx = _lrg_map.live_range_id(in); if (lidx >= _lrg_map.max_lrg_id()) { continue; // Value is a recent spill-copy } if (lrgs(lidx).is_singledef()) { continue; } Block *b_def = _cfg.get_block_for_node(def); int idx_def = b_def->find_node(def); Node *in_spill = get_spillcopy_wide( in, def, i ); if( !in_spill ) return 0; // Bailed out insert_proj(b_def,idx_def,in_spill,maxlrg++); if( b_def == b ) insidx++; def->set_req(i,in_spill); } } We do not need to do this for live ranges with only a single definition. We also do not do this for recently created spill copies. Recent spill copies refers to spill copies created in the current split pass, that have not yet been assigned live ranges. The problem is that spill copies may introduce phi nodes due to different reaching definitions from different control paths. And phi nodes introduces coalescing; in the end of a split pass we coalesce phi inputs with the phi itself (for all phi nodes created in the split pass). So what happens if a phi input is a recent spill copy? The recent spill copy get coalesced with the phi (and the live range of the the spill copy and the phi will be multi defined). And what happens if this recent spill copy is input to a re-materialized node? Then we introduce the risk of stretching the live range beyond another def. (*) This is exactly what happens in prior bugs JDK-8005956 and JDK-8016157. When I solved them, I did not know well enough what the problem was, so I disabled re-materialization for some nodes. Now I know better and instead I can add the same support for recent spill copies, i.e. I create private copies for them as well. At the same time, I can remove the old temporary solutions. I have verified that JDK-8005956 now also works with the new solution. Unfortunately I have not been able to reproduce JDK-8016157, but I have been able to solve a new bug, JDK-7196566, using this new solution. I have also verified that this fix does not give any performance regressions. http://sthaurora-ds.se.oracle.com/performance/rest/submit/runStatus?name=REG_SPLIT http://sthaurora-ds.se.oracle.com/performance/rest/perf/report?name=REG_SPLIT WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8022783 Kind Regards, Niclas Adlertz (*) It is tricky because this can not happen by just coalescing a recent spill copy (as phi input) with its phi node 'P'. It happens because the input for 'P' is also a phi, which is THEN coalesced together with the recent spill copy. Simply put, we need more than one recursion of coalescing in the split pass for this to happen. From vladimir.kozlov at oracle.com Wed Oct 16 09:00:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 09:00:35 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> Message-ID: <525EB823.8080308@oracle.com> Igor, New verification code should be under #ifdef ASSERT instead of #ifndef PRODUCT. And the print codes "fusion has incorrect" with path dump should be under PrintOptimizeStringConcat flag as in other places. Otherwise it is good. Thanks, Vladimir On 10/16/13 7:18 AM, Igor Veresov wrote: > I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify. > > Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/ > > igor > > On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: > >> >> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: >> >>> You don't need 'if()': >>> >>> + if (mem->is_MergeMem()) { >>> + while (mem->is_MergeMem()) { >>> >> ok >> >>> Typo "the have" ("it is"?): >>> >>> + // now let it fall though, and see if the have a projection >>> >> yup >> >>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >>> >> >> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. >> >> Thanks! >> igor >> >>> Thanks, >>> Vladimir >>> >>> On 10/14/13 1:57 PM, Igor Veresov wrote: >>>> Hi guys, >>>> >>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>>> >>>> Testing: jtreg, CTW, the failing tests >>>> >>>> igor >>>> >>>> >> > From roland.westrelin at oracle.com Wed Oct 16 09:04:44 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 Oct 2013 18:04:44 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <525E47A3.80103@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> <525E4055.6090508@oracle.com> <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> <525E47A3.80103@oracle.com> Message-ID: <3B5A17FD-B2B3-465B-905E-AC655BFF8A95@oracle.com> >>> I know we are rushing currently so we don't have time to do proper generic fix. >>> Can you do it only for JSR292 methods where you see this pattern and preferably under flag? >>> The less we change common code now is better. >> >> What about I don't try to restrict it to JSR292 methods (I'm concerned that if I'm too restrictive we can't even turn it on to see if it helps) but put it under a flag that is off by default? And then when type speculation is on, turning type speculation on turns this on as well? > > Yes, it is fine under flag. Here is a new webrev for this. The change is under a flag. It's off by default. I removed the useless library intrinsic changes. I now use parser->caller()->map(). http://cr.openjdk.java.net/~roland/8024069/webrev.01/ Roland. > > Vladimir > >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/16/13 12:15 AM, Roland Westrelin wrote: >>>> >>>> On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: >>>> >>>>> On 10/15/13 3:31 AM, Roland Westrelin wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> Thanks for reviewing this. >>>>>> >>>>>>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>>>>>> _inline_cg->generate(jvms, NULL); >>>>>> >>>>>> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? >>>>> >>>>> Yes, you are right. But you still have exit.jvms in which you can do replacement. >>>> >>>> Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. >>>> >>>>> >>>>>> >>>>>>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >>>>>> >>>>>> You're right. We don't need to care about intrinsics. >>>>>> >>>>>> So in GraphKit::replace_in_map(). this: >>>>>> >>>>>> if (parser == NULL) { >>>>>> parser = parent_parser(); >>>>>> } >>>>>> >>>>>> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >>>>>> >>>>>>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >>>>>> >>>>>> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >>>>>> >>>>>>> >>>>>>> And I don't understand where 1) requirement comes from. >>>>>> >>>>>> If we have something like this: >>>>>> >>>>>> void m(A a) { >>>>>> if (some_condition) { >>>>>> B b = (B)a; >>>>>> } else { >>>>>> // some other stuff >>>>>> } >>>>>> } >>>>>> >>>>>> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. >>>>> >>>>> What about this case? We should be keeping the cast: >>>>> >>>>> void m(A a) { >>>>> if (some_condition) { >>>>> // some other stuff >>>>> } >>>>> B b = (B)a; >>>>> } >>>>> >>>> >>>> This case we could handle in my change by skipping over simple ifs. >>>> >>>>> I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). >>>> >>>> >>>> For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. >>>> >>>> void m(A a) { >>>> B b = (B)b; >>>> // maybe some more stuff after >>>> } >>>> >>>> If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> I am fine with moving is_uncommon_trap_*() mathods. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>>>>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>>>>>> >>>>>>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>> >>>> >> From vladimir.kozlov at oracle.com Wed Oct 16 09:10:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 09:10:39 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <3B5A17FD-B2B3-465B-905E-AC655BFF8A95@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> <525E4055.6090508@oracle.com> <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> <525E47A3.80103@oracle.com> <3B5A17FD-B2B3-465B-905E-AC655BFF8A95@oracle.com> Message-ID: <525EBA7F.8030400@oracle.com> Okay. Vladimir On 10/16/13 9:04 AM, Roland Westrelin wrote: >>>> I know we are rushing currently so we don't have time to do proper generic fix. >>>> Can you do it only for JSR292 methods where you see this pattern and preferably under flag? >>>> The less we change common code now is better. >>> >>> What about I don't try to restrict it to JSR292 methods (I'm concerned that if I'm too restrictive we can't even turn it on to see if it helps) but put it under a flag that is off by default? And then when type speculation is on, turning type speculation on turns this on as well? >> >> Yes, it is fine under flag. > > Here is a new webrev for this. The change is under a flag. It's off by default. I removed the useless library intrinsic changes. I now use parser->caller()->map(). > > http://cr.openjdk.java.net/~roland/8024069/webrev.01/ > > Roland. > >> >> Vladimir >> >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/16/13 12:15 AM, Roland Westrelin wrote: >>>>> >>>>> On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/15/13 3:31 AM, Roland Westrelin wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> Thanks for reviewing this. >>>>>>> >>>>>>>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>>>>>>> _inline_cg->generate(jvms, NULL); >>>>>>> >>>>>>> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? >>>>>> >>>>>> Yes, you are right. But you still have exit.jvms in which you can do replacement. >>>>> >>>>> Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. >>>>> >>>>>> >>>>>>> >>>>>>>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >>>>>>> >>>>>>> You're right. We don't need to care about intrinsics. >>>>>>> >>>>>>> So in GraphKit::replace_in_map(). this: >>>>>>> >>>>>>> if (parser == NULL) { >>>>>>> parser = parent_parser(); >>>>>>> } >>>>>>> >>>>>>> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >>>>>>> >>>>>>>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >>>>>>> >>>>>>> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >>>>>>> >>>>>>>> >>>>>>>> And I don't understand where 1) requirement comes from. >>>>>>> >>>>>>> If we have something like this: >>>>>>> >>>>>>> void m(A a) { >>>>>>> if (some_condition) { >>>>>>> B b = (B)a; >>>>>>> } else { >>>>>>> // some other stuff >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. >>>>>> >>>>>> What about this case? We should be keeping the cast: >>>>>> >>>>>> void m(A a) { >>>>>> if (some_condition) { >>>>>> // some other stuff >>>>>> } >>>>>> B b = (B)a; >>>>>> } >>>>>> >>>>> >>>>> This case we could handle in my change by skipping over simple ifs. >>>>> >>>>>> I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). >>>>> >>>>> >>>>> For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. >>>>> >>>>> void m(A a) { >>>>> B b = (B)b; >>>>> // maybe some more stuff after >>>>> } >>>>> >>>>> If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> I am fine with moving is_uncommon_trap_*() mathods. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>>>>>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>>>>>>> >>>>>>>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>> >>>>> >>> > From igor.veresov at oracle.com Wed Oct 16 09:20:34 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Oct 2013 09:20:34 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <525EB823.8080308@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> <525EB823.8080308@oracle.com> Message-ID: On Oct 16, 2013, at 9:00 AM, Vladimir Kozlov wrote: > Igor, > > New verification code should be under #ifdef ASSERT instead of #ifndef PRODUCT. > And the print codes "fusion has incorrect" with path dump should be under PrintOptimizeStringConcat flag as in other places. Duh, thanks for noticing that! Here's the updated webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.4/ igor > > Otherwise it is good. > > Thanks, > Vladimir > > On 10/16/13 7:18 AM, Igor Veresov wrote: >> I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/ >> >> igor >> >> On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: >> >>> >>> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: >>> >>>> You don't need 'if()': >>>> >>>> + if (mem->is_MergeMem()) { >>>> + while (mem->is_MergeMem()) { >>>> >>> ok >>> >>>> Typo "the have" ("it is"?): >>>> >>>> + // now let it fall though, and see if the have a projection >>>> >>> yup >>> >>>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >>>> >>> >>> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. >>> >>> Thanks! >>> igor >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/14/13 1:57 PM, Igor Veresov wrote: >>>>> Hi guys, >>>>> >>>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>>>> >>>>> Testing: jtreg, CTW, the failing tests >>>>> >>>>> igor >>>>> >>>>> >>> >> From vladimir.kozlov at oracle.com Wed Oct 16 09:22:45 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 09:22:45 -0700 Subject: RFR(XS) 8022783: Nashorn test fails with: assert(!def_outside->member(r)) In-Reply-To: <525EA389.7040902@oracle.com> References: <525EA389.7040902@oracle.com> Message-ID: <525EBD55.3010002@oracle.com> Niclas, You need to change/add comments in this code. Otherwise it is good. Thanks, Vladimir On 10/16/13 7:32 AM, Niclas Adlertz wrote: > Hi all, > > Despite the fact that I have not been able to reproduce JDK-8022783, it generates the same error as many other bugs; > JDK-7033056, JDK-8016269, JDK-8011770, JDK-8005956, JDK-8016157 and JDK-7196566. > They are all related to re-materialization. One major concern when re-materializing is that each input node to the > re-materialized node might need to have its live range 'L' stretched. > If 'L' is defined at multiple places (due to coalescing), we might stretch one definition of 'L' beyond another definition. > > Currently we handle this by doing a private copy of the input in the same block as the node that is being > re-materialized. This happens at the beginning of PhaseChaitin::Split_Rematerialize: > > // The input live ranges will be stretched to the site of the new > // instruction. They might be stretched past a def and will thus > // have the old and new values of the same live range alive at the > // same time - a definite no-no. Split out private copies of > // the inputs. > if( def->req() > 1 ) { > for( uint i = 1; i < def->req(); i++ ) { > Node *in = def->in(i); > // Check for single-def (LRG cannot redefined) > uint lidx = _lrg_map.live_range_id(in); > if (lidx >= _lrg_map.max_lrg_id()) { > continue; // Value is a recent spill-copy > } > if (lrgs(lidx).is_singledef()) { > continue; > } > > Block *b_def = _cfg.get_block_for_node(def); > int idx_def = b_def->find_node(def); > Node *in_spill = get_spillcopy_wide( in, def, i ); > if( !in_spill ) return 0; // Bailed out > insert_proj(b_def,idx_def,in_spill,maxlrg++); > if( b_def == b ) > insidx++; > def->set_req(i,in_spill); > } > } > > We do not need to do this for live ranges with only a single definition. > We also do not do this for recently created spill copies. Recent spill copies refers to spill copies created in the > current split pass, that have not yet been assigned live ranges. > > The problem is that spill copies may introduce phi nodes due to different reaching definitions from different control > paths. And phi nodes introduces coalescing; in the end of a split pass we coalesce phi inputs with the phi itself (for > all phi nodes created in the split pass). > So what happens if a phi input is a recent spill copy? The recent spill copy get coalesced with the phi (and the live > range of the the spill copy and the phi will be multi defined). > And what happens if this recent spill copy is input to a re-materialized node? Then we introduce the risk of stretching > the live range beyond another def. (*) > > This is exactly what happens in prior bugs JDK-8005956 and JDK-8016157. When I solved them, I did not know well enough > what the problem was, so I disabled re-materialization for some nodes. Now I know better and instead I can add the same > support for recent spill copies, i.e. I create private copies for them as well. At the same time, I can remove the old > temporary solutions. > > I have verified that JDK-8005956 now also works with the new solution. Unfortunately I have not been able to reproduce > JDK-8016157, but I have been able to solve a new bug, JDK-7196566, using this new solution. > > I have also verified that this fix does not give any performance regressions. > http://sthaurora-ds.se.oracle.com/performance/rest/submit/runStatus?name=REG_SPLIT > http://sthaurora-ds.se.oracle.com/performance/rest/perf/report?name=REG_SPLIT > > WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8022783 > > Kind Regards, > Niclas Adlertz > > (*) It is tricky because this can not happen by just coalescing a recent spill copy (as phi input) with its phi node > 'P'. It happens because the input for 'P' is also a phi, which is THEN coalesced together with the recent spill copy. > Simply put, we need more than one recursion of coalescing in the split pass for this to happen. From vladimir.kozlov at oracle.com Wed Oct 16 09:23:46 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 09:23:46 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> <525EB823.8080308@oracle.com> Message-ID: <525EBD92.4000309@oracle.com> Good. Thanks, Vladimir On 10/16/13 9:20 AM, Igor Veresov wrote: > On Oct 16, 2013, at 9:00 AM, Vladimir Kozlov wrote: > >> Igor, >> >> New verification code should be under #ifdef ASSERT instead of #ifndef PRODUCT. >> And the print codes "fusion has incorrect" with path dump should be under PrintOptimizeStringConcat flag as in other places. > > Duh, thanks for noticing that! > > Here's the updated webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.4/ > > igor > >> >> Otherwise it is good. >> >> Thanks, >> Vladimir >> >> On 10/16/13 7:18 AM, Igor Veresov wrote: >>> I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/ >>> >>> igor >>> >>> On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: >>> >>>> >>>> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: >>>> >>>>> You don't need 'if()': >>>>> >>>>> + if (mem->is_MergeMem()) { >>>>> + while (mem->is_MergeMem()) { >>>>> >>>> ok >>>> >>>>> Typo "the have" ("it is"?): >>>>> >>>>> + // now let it fall though, and see if the have a projection >>>>> >>>> yup >>>> >>>>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >>>>> >>>> >>>> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. >>>> >>>> Thanks! >>>> igor >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/14/13 1:57 PM, Igor Veresov wrote: >>>>>> Hi guys, >>>>>> >>>>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>>>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>>>>> >>>>>> Testing: jtreg, CTW, the failing tests >>>>>> >>>>>> igor >>>>>> >>>>>> >>>> >>> > From igor.veresov at oracle.com Wed Oct 16 09:24:31 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Oct 2013 09:24:31 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <525EBD92.4000309@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> <525EB823.8080308@oracle.com> <525EBD92.4000309@oracle.com> Message-ID: <9E849FCF-053C-4520-B5DF-0C760A2F40C0@oracle.com> Thanks, Vladimir! igor On Oct 16, 2013, at 9:23 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/16/13 9:20 AM, Igor Veresov wrote: >> On Oct 16, 2013, at 9:00 AM, Vladimir Kozlov wrote: >> >>> Igor, >>> >>> New verification code should be under #ifdef ASSERT instead of #ifndef PRODUCT. >>> And the print codes "fusion has incorrect" with path dump should be under PrintOptimizeStringConcat flag as in other places. >> >> Duh, thanks for noticing that! >> >> Here's the updated webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.4/ >> >> igor >> >>> >>> Otherwise it is good. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/16/13 7:18 AM, Igor Veresov wrote: >>>> I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/ >>>> >>>> igor >>>> >>>> On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: >>>> >>>>> >>>>> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: >>>>> >>>>>> You don't need 'if()': >>>>>> >>>>>> + if (mem->is_MergeMem()) { >>>>>> + while (mem->is_MergeMem()) { >>>>>> >>>>> ok >>>>> >>>>>> Typo "the have" ("it is"?): >>>>>> >>>>>> + // now let it fall though, and see if the have a projection >>>>>> >>>>> yup >>>>> >>>>>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >>>>>> >>>>> >>>>> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. >>>>> >>>>> Thanks! >>>>> igor >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/14/13 1:57 PM, Igor Veresov wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>>>>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>>>>>> >>>>>>> Testing: jtreg, CTW, the failing tests >>>>>>> >>>>>>> igor >>>>>>> >>>>>>> >>>>> >>>> >> From roland.westrelin at oracle.com Wed Oct 16 10:27:55 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 16 Oct 2013 19:27:55 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <525EBA7F.8030400@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> <525E4055.6090508@oracle.com> <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> <525E47A3.80103@oracle.com> <3B5A17FD-B2B3-465B-905E-AC655BFF8A95@oracle.com> <525EBA7F.8030400@oracle.com> Message-ID: <57BFA9FB-D4B5-4717-82EE-1C8833339EE3@oracle.com> Thanks for the review, Vladimir. Roland. From christian.thalinger at oracle.com Wed Oct 16 10:39:08 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Oct 2013 10:39:08 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> <525EB823.8080308@oracle.com> Message-ID: <6B9BA48B-DBB1-4E0D-854C-EDAA2A857418@oracle.com> Please don't use abbreviations in comments: + // Verify that the other arm is uct Comments should be easy to understand and self explanatory. I don't want to look at the code to understand the comment. Except for smaller formatting issues (which I'm not going to mention here) this looks good. On Oct 16, 2013, at 9:20 AM, Igor Veresov wrote: > On Oct 16, 2013, at 9:00 AM, Vladimir Kozlov wrote: > >> Igor, >> >> New verification code should be under #ifdef ASSERT instead of #ifndef PRODUCT. >> And the print codes "fusion has incorrect" with path dump should be under PrintOptimizeStringConcat flag as in other places. > > Duh, thanks for noticing that! > > Here's the updated webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.4/ > > igor > >> >> Otherwise it is good. >> >> Thanks, >> Vladimir >> >> On 10/16/13 7:18 AM, Igor Veresov wrote: >>> I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/ >>> >>> igor >>> >>> On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: >>> >>>> >>>> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: >>>> >>>>> You don't need 'if()': >>>>> >>>>> + if (mem->is_MergeMem()) { >>>>> + while (mem->is_MergeMem()) { >>>>> >>>> ok >>>> >>>>> Typo "the have" ("it is"?): >>>>> >>>>> + // now let it fall though, and see if the have a projection >>>>> >>>> yup >>>> >>>>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >>>>> >>>> >>>> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. >>>> >>>> Thanks! >>>> igor >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/14/13 1:57 PM, Igor Veresov wrote: >>>>>> Hi guys, >>>>>> >>>>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>>>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>>>>> >>>>>> Testing: jtreg, CTW, the failing tests >>>>>> >>>>>> igor >>>>>> >>>>>> >>>> >>> > From christian.thalinger at oracle.com Wed Oct 16 10:43:30 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Oct 2013 10:43:30 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <525E2C11.9050100@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> Message-ID: <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> It would be nice to have a comment on this guy: + bool _contains_all_checks; No need for another webrev if you decide to add the comment. Looks good. On Oct 15, 2013, at 11:02 PM, Albert Noll wrote: > Forgot to adjust the comment. This version should be fine. > > http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ > > Albert > > On 15.10.2013 21:03, Vladimir Kozlov wrote: >> Albert, >> >> contains_all_stubs name is incorrect. It should be contains_all_checks. Adapter code does not have stubs in it. >> >> I think the next check should be: >> >> bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; >> >> because code does not change when VerifyAdapterCalls is false. >> Then you don't need to check VerifyAdapterCalls in next condition: >> >> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && !entry->contains_all_checks()) { >> >> And we need to regenerate adapter regardless VerifyAdapterSharing because, as you said, VerifyAdapterCalls potentially reports a false error if check for code2 is not generated. >> >> So the condition should be simple "if (!entry->contains_all_checks())". >> >> Could you leave next lines unchanged (use 2 lines for arguments)?: >> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >> >> sizeof(buffer_locs)/sizeof(relocInfo)); >> MacroAssembler _masm(&buffer); >> >> Cleanup is fine. >> >> Thanks, >> Vladimir >> >> On 10/15/13 4:14 AM, Albert Noll wrote: >>> Hi, >>> >>> could I have reviews for this small patch? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>> >>> >>> Problem: This flag is broken. The reason is that adapters >>> (gen_i2c_adapter()) that are generated during VM startup do not include >>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>> specified. StubRoutines::code2() is only allocated later during startup; >>> consequently, code2() is NULL. As a result, the size of the generated >>> adapter as well as the code itself does not mactch. >>> >>> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >>> Note that this patch also fixes potential issues with >>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>> removes some unused field of VerifyAdapterSharing. >>> >>> >>> Many thanks in advance, >>> Albert >>> ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131016/f8193129/attachment-0001.html From igor.veresov at oracle.com Wed Oct 16 10:45:53 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Oct 2013 10:45:53 -0700 Subject: RFR(M): Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 In-Reply-To: <6B9BA48B-DBB1-4E0D-854C-EDAA2A857418@oracle.com> References: <973C0358-C06B-4F6B-B80A-6C29AB00B295@oracle.com> <525641C6.8030702@oracle.com> <3F3ADE61-9EC0-4BC0-92B2-E9D076AFB2E6@oracle.com> <734305AA-853B-47BB-BEF6-9BB115C42CD2@oracle.com> <8D1B14F4-0983-4189-B019-ACC97B226786@oracle.com> <525C64AA.2040901@oracle.com> <6ABCE96D-818F-41B8-BCC9-647DA0725315@oracle.com> <525EB823.8080308@oracle.com> <6B9BA48B-DBB1-4E0D-854C-EDAA2A857418@oracle.com> Message-ID: <0DEEECE6-1681-417F-A195-681CC68FC0B5@oracle.com> Thanks, Chis! I'll fix the comment. igor On Oct 16, 2013, at 10:39 AM, Christian Thalinger wrote: > Please don't use abbreviations in comments: > > + // Verify that the other arm is uct > > Comments should be easy to understand and self explanatory. I don't want to look at the code to understand the comment. > > Except for smaller formatting issues (which I'm not going to mention here) this looks good. > > On Oct 16, 2013, at 9:20 AM, Igor Veresov wrote: > >> On Oct 16, 2013, at 9:00 AM, Vladimir Kozlov wrote: >> >>> Igor, >>> >>> New verification code should be under #ifdef ASSERT instead of #ifndef PRODUCT. >>> And the print codes "fusion has incorrect" with path dump should be under PrintOptimizeStringConcat flag as in other places. >> >> Duh, thanks for noticing that! >> >> Here's the updated webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.4/ >> >> igor >> >>> >>> Otherwise it is good. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/16/13 7:18 AM, Igor Veresov wrote: >>>> I've added some code to verify the control flow pattern between the constructor calls and initialize. The control flow should be essentially a straight line, except for simple diamonds of casts, and things like null and class checks with the false branch ending with uncommon trap. Ran through ctw and jtreg to verify. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.3/ >>>> >>>> igor >>>> >>>> On Oct 14, 2013, at 5:38 PM, Igor Veresov wrote: >>>> >>>>> >>>>> On Oct 14, 2013, at 2:39 PM, Vladimir Kozlov wrote: >>>>> >>>>>> You don't need 'if()': >>>>>> >>>>>> + if (mem->is_MergeMem()) { >>>>>> + while (mem->is_MergeMem()) { >>>>>> >>>>> ok >>>>> >>>>>> Typo "the have" ("it is"?): >>>>>> >>>>>> + // now let it fall though, and see if the have a projection >>>>>> >>>>> yup >>>>> >>>>>> I wish you had some asserts for constructors case. May be check in debug VM that controls from Initialize to contructor don't have other uses. >>>>>> >>>>> >>>>> Well, this is already handled in the control flow analysis, but sure, I'll add some code. I'll come back with this tomorrow. >>>>> >>>>> Thanks! >>>>> igor >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/14/13 1:57 PM, Igor Veresov wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> I had to go back and think about the solution to clear up some doubts. While my original solution mostly worked, there is actually a more efficient way to do the analysis in polynomial time. >>>>>>> Basically the implementation boils down to verifying that there are no side effects between the first constructor and all the following calls by following the bottom memory slices up until we find a know call. The presence of memory slices of different alias types between the calls also indicate the side effect. As for the case when side effects (calls or stores) happen after allocation and before the constructor call they always have a control dependency on initialization, and therefore will be caught by the existing control flow validation. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8009303/webrev.2/ >>>>>>> >>>>>>> Testing: jtreg, CTW, the failing tests >>>>>>> >>>>>>> igor >>>>>>> >>>>>>> >>>>> >>>> >> > From igor.veresov at oracle.com Wed Oct 16 11:58:17 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 16 Oct 2013 11:58:17 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <525C42C4.1090801@oracle.com> References: <525C42C4.1090801@oracle.com> Message-ID: Looks ok. Maybe add_method_name() should have an assert to verify that it's not overwriting the slot that's already used? igor On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ > 7 lines changed: 5 ins; 1 del; 1 mod > > Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: > assert(m.vminfoIsConsistent()); > > After that check, class redefinition is broken - it's still possible to invoke old version of a method. > > Analysis from Serguei: > "The problem is here: > oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& info) { > . . . . . . . . > m->method_holder()->add_member_name(m->method_idnum(), mname); > > return mname(); > } > > The call to add_member_name() resets the member name at the index m->method_idnum(). After that one of the two member names with the same method_idnum() is out of the MNT and is not updated when the method is redefined." > > The fix is to check whether there's already a member name associated with the before creating a new one. > > Testing: failing test. > > Contributed-by: sspitsyn, vlivanov > > Best regards, > Vladimir Ivanov > > JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 From albert.noll at oracle.com Wed Oct 16 12:22:22 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 16 Oct 2013 21:22:22 +0200 Subject: RFR(XS): 8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Message-ID: <525EE76E.3050105@oracle.com> Hi, could I have a review for this patch? bug: https://bugs.openjdk.java.net/browse/JDK-8026708 webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ Problem: Not enough room for interpreter. My last patch did not solve the problem for solaris-amd64. A local build (solaris-amd64) of the most recent hotspot-comp version requires a template interpreter size of 211K (obtained with -XX:+PrintInterpreter). There have been some modifications to the template interpreter in the last couple of weeks which might have triggered this error. Solution: Increase interpreter size by 8k (32-bit and 64-bit). Testing: Failing test case in solaris-amd64 Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131016/16cc64a1/attachment.html From vladimir.kozlov at oracle.com Wed Oct 16 12:28:58 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 12:28:58 -0700 Subject: RFR(XS): 8024128: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation In-Reply-To: <525EE76E.3050105@oracle.com> References: <525EE76E.3050105@oracle.com> Message-ID: <525EE8FA.5000407@oracle.com> I think we should increase it more for future otherwise you will have to always catch up with interpreter changes. Increase it to 256 * 1024 and 224 * 1024 Vladimir On 10/16/13 12:22 PM, Albert Noll wrote: > Hi, > > could I have a review for this patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8026708 > webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ > > > Problem: Not enough room for interpreter. My last patch did not solve > the problem for solaris-amd64. > A local build (solaris-amd64) of the most recent > hotspot-comp version requires a template interpreter > size of 211K (obtained with -XX:+PrintInterpreter). > There have been some modifications to the template > interpreter in the last couple of weeks which might have > triggered this error. > > Solution: Increase interpreter size by 8k (32-bit and 64-bit). > > Testing: Failing test case in solaris-amd64 > > > Many thanks in advance, > Albert From albert.noll at oracle.com Wed Oct 16 13:06:07 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 16 Oct 2013 22:06:07 +0200 Subject: RFR(XS): 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation In-Reply-To: <525EE8FA.5000407@oracle.com> References: <525EE76E.3050105@oracle.com> <525EE8FA.5000407@oracle.com> Message-ID: <525EF1AF.7020500@oracle.com> Hi Vladimir, thanks for the review. I agree, this gives us more air. Here is the new webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.01/ Best, Albert P.S.: I had the wrong header to the mail. The bug id is actually 8026708. On 16.10.2013 21:28, Vladimir Kozlov wrote: > I think we should increase it more for future otherwise you will have > to always catch up with interpreter changes. > > Increase it to 256 * 1024 and 224 * 1024 > > Vladimir > > On 10/16/13 12:22 PM, Albert Noll wrote: >> Hi, >> >> could I have a review for this patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8026708 >> webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ >> >> >> Problem: Not enough room for interpreter. My last patch did not solve >> the problem for solaris-amd64. >> A local build (solaris-amd64) of the most recent >> hotspot-comp version requires a template interpreter >> size of 211K (obtained with -XX:+PrintInterpreter). >> There have been some modifications to the template >> interpreter in the last couple of weeks which might have >> triggered this error. >> >> Solution: Increase interpreter size by 8k (32-bit and 64-bit). >> >> Testing: Failing test case in solaris-amd64 >> >> >> Many thanks in advance, >> Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131016/aa50eb25/attachment.html From christian.thalinger at oracle.com Wed Oct 16 13:28:49 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Oct 2013 13:28:49 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <525C42C4.1090801@oracle.com> References: <525C42C4.1090801@oracle.com> Message-ID: <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ > 7 lines changed: 5 ins; 1 del; 1 mod > > Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: > assert(m.vminfoIsConsistent()); > > After that check, class redefinition is broken - it's still possible to invoke old version of a method. > > Analysis from Serguei: > "The problem is here: > oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& info) { > . . . . . . . . > m->method_holder()->add_member_name(m->method_idnum(), mname); > > return mname(); > } > > The call to add_member_name() resets the member name at the index m->method_idnum(). After that one of the two member names with the same method_idnum() is out of the MNT and is not updated when the method is redefined." As I understand this the problem is calling MethodHandles::init_method_MemberName which installs a new MemberName instance in the MemberNameTable. Correct? If that's the case then there is a potential race here. + x = m->method_holder()->get_member_name(m->method_idnum()); + if (x == NULL) { + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); x = MethodHandles::init_method_MemberName(mname2, info); } Racing threads can get back null when calling get_member_name and then install different MemberName objects in the table. > > The fix is to check whether there's already a member name associated with the before creating a new one. > > Testing: failing test. > > Contributed-by: sspitsyn, vlivanov > > Best regards, > Vladimir Ivanov > > JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 From christian.thalinger at oracle.com Wed Oct 16 13:56:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 16 Oct 2013 13:56:02 -0700 Subject: RFR(XS): 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation In-Reply-To: <525EF1AF.7020500@oracle.com> References: <525EE76E.3050105@oracle.com> <525EE8FA.5000407@oracle.com> <525EF1AF.7020500@oracle.com> Message-ID: What command line options did you use to verify the size is enough? I noticed the other day that using JDWP: -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 also hit the limit. VerifyOops? On Oct 16, 2013, at 1:06 PM, Albert Noll wrote: > Hi Vladimir, > > thanks for the review. I agree, this gives us more air. > Here is the new webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.01/ > > Best, > Albert > > P.S.: I had the wrong header to the mail. The bug id is actually 8026708. > > > > On 16.10.2013 21:28, Vladimir Kozlov wrote: >> I think we should increase it more for future otherwise you will have to always catch up with interpreter changes. >> >> Increase it to 256 * 1024 and 224 * 1024 >> >> Vladimir >> >> On 10/16/13 12:22 PM, Albert Noll wrote: >>> Hi, >>> >>> could I have a review for this patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026708 >>> webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ >>> >>> >>> Problem: Not enough room for interpreter. My last patch did not solve >>> the problem for solaris-amd64. >>> A local build (solaris-amd64) of the most recent >>> hotspot-comp version requires a template interpreter >>> size of 211K (obtained with -XX:+PrintInterpreter). >>> There have been some modifications to the template >>> interpreter in the last couple of weeks which might have >>> triggered this error. >>> >>> Solution: Increase interpreter size by 8k (32-bit and 64-bit). >>> >>> Testing: Failing test case in solaris-amd64 >>> >>> >>> Many thanks in advance, >>> Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131016/b93bc617/attachment.html From vladimir.kozlov at oracle.com Wed Oct 16 13:58:19 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 16 Oct 2013 13:58:19 -0700 Subject: RFR(XS): 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation In-Reply-To: <525EF1AF.7020500@oracle.com> References: <525EE76E.3050105@oracle.com> <525EE8FA.5000407@oracle.com> <525EF1AF.7020500@oracle.com> Message-ID: <525EFDEB.6060406@oracle.com> Good. Thanks, Vladimir On 10/16/13 1:06 PM, Albert Noll wrote: > Hi Vladimir, > > thanks for the review. I agree, this gives us more air. > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8026708/webrev.01/ > > > Best, > Albert > > P.S.: I had the wrong header to the mail. The bug id is actually 8026708. > > > > On 16.10.2013 21:28, Vladimir Kozlov wrote: >> I think we should increase it more for future otherwise you will have >> to always catch up with interpreter changes. >> >> Increase it to 256 * 1024 and 224 * 1024 >> >> Vladimir >> >> On 10/16/13 12:22 PM, Albert Noll wrote: >>> Hi, >>> >>> could I have a review for this patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026708 >>> webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ >>> >>> >>> Problem: Not enough room for interpreter. My last patch did not solve >>> the problem for solaris-amd64. >>> A local build (solaris-amd64) of the most recent >>> hotspot-comp version requires a template interpreter >>> size of 211K (obtained with -XX:+PrintInterpreter). >>> There have been some modifications to the template >>> interpreter in the last couple of weeks which might have >>> triggered this error. >>> >>> Solution: Increase interpreter size by 8k (32-bit and 64-bit). >>> >>> Testing: Failing test case in solaris-amd64 >>> >>> >>> Many thanks in advance, >>> Albert > From igor.veresov at oracle.com Wed Oct 16 14:57:32 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 16 Oct 2013 21:57:32 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Message-ID: <20131016215742.43C356248C@hg.openjdk.java.net> Changeset: 90abdd727e64 Author: iveresov Date: 2013-10-16 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/90abdd727e64 8009303: Tiered: incorrect results in VM tests stringconcat with -Xcomp -XX:+DeoptimizeALot on solaris-amd64 Summary: Do memory flow analysis in string concat optimizier to exclude cases when computation of arguments to StringBuffer::append has side effects Reviewed-by: kvn, twisti ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/stringopts.cpp From albert.noll at oracle.com Thu Oct 17 01:46:30 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 17 Oct 2013 10:46:30 +0200 Subject: RFR(XS): 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation In-Reply-To: <525EFDEB.6060406@oracle.com> References: <525EE76E.3050105@oracle.com> <525EE8FA.5000407@oracle.com> <525EF1AF.7020500@oracle.com> <525EFDEB.6060406@oracle.com> Message-ID: <525FA3E6.5050003@oracle.com> Christian, Vladimir, thanks for looking at the patch. Increasing the space that is reserved for the template interpreter leaves 45K (2K reserved for alignment) of availbale space if the following options are used (64-bit): java -Xmixed -server -d64 -XX:+UseParallelGC -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter -XX:-UseCompressedOops -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 -XX:+VerifyOops code size = 208K bytes total space = 255K bytes wasted space = 47K bytes # of codelets = 264 avg codelet size = 808 bytes I was not aware that '-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000' requires so much space in the interpreter. Sorry for that! I am fine with the current solution (256k for 64-bit and 224k for 32-bit). Best, Albert On 16.10.2013 22:58, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/16/13 1:06 PM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks for the review. I agree, this gives us more air. >> Here is the new webrev: >> http://cr.openjdk.java.net/~anoll/8026708/webrev.01/ >> >> >> Best, >> Albert >> >> P.S.: I had the wrong header to the mail. The bug id is actually >> 8026708. >> >> >> >> On 16.10.2013 21:28, Vladimir Kozlov wrote: >>> I think we should increase it more for future otherwise you will have >>> to always catch up with interpreter changes. >>> >>> Increase it to 256 * 1024 and 224 * 1024 >>> >>> Vladimir >>> >>> On 10/16/13 12:22 PM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I have a review for this patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026708 >>>> webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ >>>> >>>> >>>> Problem: Not enough room for interpreter. My last patch did not solve >>>> the problem for solaris-amd64. >>>> A local build (solaris-amd64) of the most recent >>>> hotspot-comp version requires a template interpreter >>>> size of 211K (obtained with -XX:+PrintInterpreter). >>>> There have been some modifications to the template >>>> interpreter in the last couple of weeks which might >>>> have >>>> triggered this error. >>>> >>>> Solution: Increase interpreter size by 8k (32-bit and 64-bit). >>>> >>>> Testing: Failing test case in solaris-amd64 >>>> >>>> >>>> Many thanks in advance, >>>> Albert >> From serguei.spitsyn at oracle.com Thu Oct 17 02:39:00 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 17 Oct 2013 02:39:00 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> Message-ID: <525FB034.9000806@oracle.com> On 10/16/13 1:28 PM, Christian Thalinger wrote: > On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >> 7 lines changed: 5 ins; 1 del; 1 mod >> >> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >> assert(m.vminfoIsConsistent()); >> >> After that check, class redefinition is broken - it's still possible to invoke old version of a method. >> >> Analysis from Serguei: >> "The problem is here: >> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& info) { >> . . . . . . . . >> m->method_holder()->add_member_name(m->method_idnum(), mname); >> >> return mname(); >> } >> >> The call to add_member_name() resets the member name at the index m->method_idnum(). After that one of the two member names with the same method_idnum() is out of the MNT and is not updated when the method is redefined." > As I understand this the problem is calling MethodHandles::init_method_MemberName which installs a new MemberName instance in the MemberNameTable. Correct? > > If that's the case then there is a potential race here. > > + x = m->method_holder()->get_member_name(m->method_idnum()); > + if (x == NULL) { > + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); > x = MethodHandles::init_method_MemberName(mname2, info); > } > > Racing threads can get back null when calling get_member_name and then install different MemberName objects in the table. Good catch, Chris. I do not see a way to fix it easily without some refactoring. It is probably better to add to the InstanceKlass a helper function that will do this dance with a required synchronization. But the following line needs to be taken out of the init_method_MemberName() : m->method_holder()->add_member_name(m->method_idnum(), mname); Thanks, Serguei > >> The fix is to check whether there's already a member name associated with the before creating a new one. >> >> Testing: failing test. >> >> Contributed-by: sspitsyn, vlivanov >> >> Best regards, >> Vladimir Ivanov >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 From niclas.adlertz at oracle.com Thu Oct 17 03:11:37 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 17 Oct 2013 12:11:37 +0200 Subject: RFR(XS) 8022783: Nashorn test fails with: assert(!def_outside->member(r)) In-Reply-To: <525EBD55.3010002@oracle.com> References: <525EA389.7040902@oracle.com> <525EBD55.3010002@oracle.com> Message-ID: <525FB7D9.9030804@oracle.com> Thanks Vladimir. http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev01/ Kind Regards, Niclas Adlertz On 2013-10-16 18:22, Vladimir Kozlov wrote: > Niclas, > > You need to change/add comments in this code. Otherwise it is good. > > Thanks, > Vladimir > > On 10/16/13 7:32 AM, Niclas Adlertz wrote: >> Hi all, >> >> Despite the fact that I have not been able to reproduce JDK-8022783, it generates the same error as many other bugs; >> JDK-7033056, JDK-8016269, JDK-8011770, JDK-8005956, JDK-8016157 and JDK-7196566. >> They are all related to re-materialization. One major concern when re-materializing is that each input node to the >> re-materialized node might need to have its live range 'L' stretched. >> If 'L' is defined at multiple places (due to coalescing), we might stretch one definition of 'L' beyond another definition. >> >> Currently we handle this by doing a private copy of the input in the same block as the node that is being >> re-materialized. This happens at the beginning of PhaseChaitin::Split_Rematerialize: >> >> // The input live ranges will be stretched to the site of the new >> // instruction. They might be stretched past a def and will thus >> // have the old and new values of the same live range alive at the >> // same time - a definite no-no. Split out private copies of >> // the inputs. >> if( def->req() > 1 ) { >> for( uint i = 1; i < def->req(); i++ ) { >> Node *in = def->in(i); >> // Check for single-def (LRG cannot redefined) >> uint lidx = _lrg_map.live_range_id(in); >> if (lidx >= _lrg_map.max_lrg_id()) { >> continue; // Value is a recent spill-copy >> } >> if (lrgs(lidx).is_singledef()) { >> continue; >> } >> >> Block *b_def = _cfg.get_block_for_node(def); >> int idx_def = b_def->find_node(def); >> Node *in_spill = get_spillcopy_wide( in, def, i ); >> if( !in_spill ) return 0; // Bailed out >> insert_proj(b_def,idx_def,in_spill,maxlrg++); >> if( b_def == b ) >> insidx++; >> def->set_req(i,in_spill); >> } >> } >> >> We do not need to do this for live ranges with only a single definition. >> We also do not do this for recently created spill copies. Recent spill copies refers to spill copies created in the >> current split pass, that have not yet been assigned live ranges. >> >> The problem is that spill copies may introduce phi nodes due to different reaching definitions from different control >> paths. And phi nodes introduces coalescing; in the end of a split pass we coalesce phi inputs with the phi itself (for >> all phi nodes created in the split pass). >> So what happens if a phi input is a recent spill copy? The recent spill copy get coalesced with the phi (and the live >> range of the the spill copy and the phi will be multi defined). >> And what happens if this recent spill copy is input to a re-materialized node? Then we introduce the risk of stretching >> the live range beyond another def. (*) >> >> This is exactly what happens in prior bugs JDK-8005956 and JDK-8016157. When I solved them, I did not know well enough >> what the problem was, so I disabled re-materialization for some nodes. Now I know better and instead I can add the same >> support for recent spill copies, i.e. I create private copies for them as well. At the same time, I can remove the old >> temporary solutions. >> >> I have verified that JDK-8005956 now also works with the new solution. Unfortunately I have not been able to reproduce >> JDK-8016157, but I have been able to solve a new bug, JDK-7196566, using this new solution. >> >> I have also verified that this fix does not give any performance regressions. >> http://sthaurora-ds.se.oracle.com/performance/rest/submit/runStatus?name=REG_SPLIT >> http://sthaurora-ds.se.oracle.com/performance/rest/perf/report?name=REG_SPLIT >> >> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8022783 >> >> Kind Regards, >> Niclas Adlertz >> >> (*) It is tricky because this can not happen by just coalescing a recent spill copy (as phi input) with its phi node >> 'P'. It happens because the input for 'P' is also a phi, which is THEN coalesced together with the recent spill copy. >> Simply put, we need more than one recursion of coalescing in the split pass for this to happen. From vladimir.x.ivanov at oracle.com Thu Oct 17 05:46:29 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 17 Oct 2013 16:46:29 +0400 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <525FB034.9000806@oracle.com> References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> Message-ID: <525FDC25.30805@oracle.com> Serguei, Chris, Igor, thanks for looking at this fix. I need to look more thoroughly at this code. I assumed that member name is initialized only once, but I was wrong - asserting empty slot in MethodHandles::init_method_MemberName fails during initialization of JSR292 core classes. Best regards, Vladimir Ivanov On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: > On 10/16/13 1:28 PM, Christian Thalinger wrote: >> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >> wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>> 7 lines changed: 5 ins; 1 del; 1 mod >>> >>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>> assert(m.vminfoIsConsistent()); >>> >>> After that check, class redefinition is broken - it's still possible >>> to invoke old version of a method. >>> >>> Analysis from Serguei: >>> "The problem is here: >>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>> info) { >>> . . . . . . . . >>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>> >>> return mname(); >>> } >>> >>> The call to add_member_name() resets the member name at the index >>> m->method_idnum(). After that one of the two member names with the >>> same method_idnum() is out of the MNT and is not updated when the >>> method is redefined." >> As I understand this the problem is calling >> MethodHandles::init_method_MemberName which installs a new MemberName >> instance in the MemberNameTable. Correct? >> >> If that's the case then there is a potential race here. >> >> + x = m->method_holder()->get_member_name(m->method_idnum()); >> + if (x == NULL) { >> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >> x = MethodHandles::init_method_MemberName(mname2, info); >> } >> >> Racing threads can get back null when calling get_member_name and then >> install different MemberName objects in the table. > > Good catch, Chris. > I do not see a way to fix it easily without some refactoring. > > It is probably better to add to the InstanceKlass a helper function that > will do > this dance with a required synchronization. > But the following line needs to be taken out of the > init_method_MemberName() : > m->method_holder()->add_member_name(m->method_idnum(), mname); > > > Thanks, > Serguei > >> >>> The fix is to check whether there's already a member name associated >>> with the before creating a new one. >>> >>> Testing: failing test. >>> >>> Contributed-by: sspitsyn, vlivanov >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 > From vladimir.kozlov at oracle.com Thu Oct 17 08:18:22 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Oct 2013 08:18:22 -0700 Subject: RFR(XS): 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation In-Reply-To: <525FA3E6.5050003@oracle.com> References: <525EE76E.3050105@oracle.com> <525EE8FA.5000407@oracle.com> <525EF1AF.7020500@oracle.com> <525EFDEB.6060406@oracle.com> <525FA3E6.5050003@oracle.com> Message-ID: <525FFFBE.50503@oracle.com> Good. Thank you again, Albert Vladimir On 10/17/13 1:46 AM, Albert Noll wrote: > Christian, Vladimir, thanks for looking at the patch. > > Increasing the space that is reserved for the template interpreter leaves 45K (2K reserved for alignment) of availbale > space if the > following options are used (64-bit): > > java -Xmixed -server -d64 -XX:+UseParallelGC -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions > -XX:+PrintInterpreter -XX:-UseCompressedOops -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 > -XX:+VerifyOops > > code size = 208K bytes > total space = 255K bytes > wasted space = 47K bytes > > # of codelets = 264 > avg codelet size = 808 bytes > > > I was not aware that '-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000' requires so much space > in the interpreter. Sorry for that! > > I am fine with the current solution (256k for 64-bit and 224k for 32-bit). > > Best, > Albert > > > On 16.10.2013 22:58, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 10/16/13 1:06 PM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for the review. I agree, this gives us more air. >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8026708/webrev.01/ >>> >>> >>> Best, >>> Albert >>> >>> P.S.: I had the wrong header to the mail. The bug id is actually 8026708. >>> >>> >>> >>> On 16.10.2013 21:28, Vladimir Kozlov wrote: >>>> I think we should increase it more for future otherwise you will have >>>> to always catch up with interpreter changes. >>>> >>>> Increase it to 256 * 1024 and 224 * 1024 >>>> >>>> Vladimir >>>> >>>> On 10/16/13 12:22 PM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> could I have a review for this patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026708 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ >>>>> >>>>> >>>>> Problem: Not enough room for interpreter. My last patch did not solve >>>>> the problem for solaris-amd64. >>>>> A local build (solaris-amd64) of the most recent >>>>> hotspot-comp version requires a template interpreter >>>>> size of 211K (obtained with -XX:+PrintInterpreter). >>>>> There have been some modifications to the template >>>>> interpreter in the last couple of weeks which might have >>>>> triggered this error. >>>>> >>>>> Solution: Increase interpreter size by 8k (32-bit and 64-bit). >>>>> >>>>> Testing: Failing test case in solaris-amd64 >>>>> >>>>> >>>>> Many thanks in advance, >>>>> Albert >>> > From vladimir.kozlov at oracle.com Thu Oct 17 08:21:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Oct 2013 08:21:23 -0700 Subject: RFR(XS) 8022783: Nashorn test fails with: assert(!def_outside->member(r)) In-Reply-To: <525FB7D9.9030804@oracle.com> References: <525EA389.7040902@oracle.com> <525EBD55.3010002@oracle.com> <525FB7D9.9030804@oracle.com> Message-ID: <52600073.7090402@oracle.com> Good but split long comment line into two (no need to resend webrev). Thanks, Vladimir On 10/17/13 3:11 AM, Niclas Adlertz wrote: > Thanks Vladimir. > > http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev01/ > > Kind Regards, > Niclas Adlertz > > On 2013-10-16 18:22, Vladimir Kozlov wrote: >> Niclas, >> >> You need to change/add comments in this code. Otherwise it is good. >> >> Thanks, >> Vladimir >> >> On 10/16/13 7:32 AM, Niclas Adlertz wrote: >>> Hi all, >>> >>> Despite the fact that I have not been able to reproduce JDK-8022783, it generates the same error as many other bugs; >>> JDK-7033056, JDK-8016269, JDK-8011770, JDK-8005956, JDK-8016157 and JDK-7196566. >>> They are all related to re-materialization. One major concern when re-materializing is that each input node to the >>> re-materialized node might need to have its live range 'L' stretched. >>> If 'L' is defined at multiple places (due to coalescing), we might stretch one definition of 'L' beyond another >>> definition. >>> >>> Currently we handle this by doing a private copy of the input in the same block as the node that is being >>> re-materialized. This happens at the beginning of PhaseChaitin::Split_Rematerialize: >>> >>> // The input live ranges will be stretched to the site of the new >>> // instruction. They might be stretched past a def and will thus >>> // have the old and new values of the same live range alive at the >>> // same time - a definite no-no. Split out private copies of >>> // the inputs. >>> if( def->req() > 1 ) { >>> for( uint i = 1; i < def->req(); i++ ) { >>> Node *in = def->in(i); >>> // Check for single-def (LRG cannot redefined) >>> uint lidx = _lrg_map.live_range_id(in); >>> if (lidx >= _lrg_map.max_lrg_id()) { >>> continue; // Value is a recent spill-copy >>> } >>> if (lrgs(lidx).is_singledef()) { >>> continue; >>> } >>> >>> Block *b_def = _cfg.get_block_for_node(def); >>> int idx_def = b_def->find_node(def); >>> Node *in_spill = get_spillcopy_wide( in, def, i ); >>> if( !in_spill ) return 0; // Bailed out >>> insert_proj(b_def,idx_def,in_spill,maxlrg++); >>> if( b_def == b ) >>> insidx++; >>> def->set_req(i,in_spill); >>> } >>> } >>> >>> We do not need to do this for live ranges with only a single definition. >>> We also do not do this for recently created spill copies. Recent spill copies refers to spill copies created in the >>> current split pass, that have not yet been assigned live ranges. >>> >>> The problem is that spill copies may introduce phi nodes due to different reaching definitions from different control >>> paths. And phi nodes introduces coalescing; in the end of a split pass we coalesce phi inputs with the phi itself (for >>> all phi nodes created in the split pass). >>> So what happens if a phi input is a recent spill copy? The recent spill copy get coalesced with the phi (and the live >>> range of the the spill copy and the phi will be multi defined). >>> And what happens if this recent spill copy is input to a re-materialized node? Then we introduce the risk of stretching >>> the live range beyond another def. (*) >>> >>> This is exactly what happens in prior bugs JDK-8005956 and JDK-8016157. When I solved them, I did not know well enough >>> what the problem was, so I disabled re-materialization for some nodes. Now I know better and instead I can add the same >>> support for recent spill copies, i.e. I create private copies for them as well. At the same time, I can remove the old >>> temporary solutions. >>> >>> I have verified that JDK-8005956 now also works with the new solution. Unfortunately I have not been able to reproduce >>> JDK-8016157, but I have been able to solve a new bug, JDK-7196566, using this new solution. >>> >>> I have also verified that this fix does not give any performance regressions. >>> http://sthaurora-ds.se.oracle.com/performance/rest/submit/runStatus?name=REG_SPLIT >>> http://sthaurora-ds.se.oracle.com/performance/rest/perf/report?name=REG_SPLIT >>> >>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8022783 >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> (*) It is tricky because this can not happen by just coalescing a recent spill copy (as phi input) with its phi node >>> 'P'. It happens because the input for 'P' is also a phi, which is THEN coalesced together with the recent spill copy. >>> Simply put, we need more than one recursion of coalescing in the split pass for this to happen. > From christian.thalinger at oracle.com Thu Oct 17 10:35:28 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 17 Oct 2013 10:35:28 -0700 Subject: RFR(XS) 8022783: Nashorn test fails with: assert(!def_outside->member(r)) In-Reply-To: <525FB7D9.9030804@oracle.com> References: <525EA389.7040902@oracle.com> <525EBD55.3010002@oracle.com> <525FB7D9.9030804@oracle.com> Message-ID: Looks good. On Oct 17, 2013, at 3:11 AM, Niclas Adlertz wrote: > Thanks Vladimir. > > http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev01/ > > Kind Regards, > Niclas Adlertz > > On 2013-10-16 18:22, Vladimir Kozlov wrote: >> Niclas, >> >> You need to change/add comments in this code. Otherwise it is good. >> >> Thanks, >> Vladimir >> >> On 10/16/13 7:32 AM, Niclas Adlertz wrote: >>> Hi all, >>> >>> Despite the fact that I have not been able to reproduce JDK-8022783, it generates the same error as many other bugs; >>> JDK-7033056, JDK-8016269, JDK-8011770, JDK-8005956, JDK-8016157 and JDK-7196566. >>> They are all related to re-materialization. One major concern when re-materializing is that each input node to the >>> re-materialized node might need to have its live range 'L' stretched. >>> If 'L' is defined at multiple places (due to coalescing), we might stretch one definition of 'L' beyond another definition. >>> >>> Currently we handle this by doing a private copy of the input in the same block as the node that is being >>> re-materialized. This happens at the beginning of PhaseChaitin::Split_Rematerialize: >>> >>> // The input live ranges will be stretched to the site of the new >>> // instruction. They might be stretched past a def and will thus >>> // have the old and new values of the same live range alive at the >>> // same time - a definite no-no. Split out private copies of >>> // the inputs. >>> if( def->req() > 1 ) { >>> for( uint i = 1; i < def->req(); i++ ) { >>> Node *in = def->in(i); >>> // Check for single-def (LRG cannot redefined) >>> uint lidx = _lrg_map.live_range_id(in); >>> if (lidx >= _lrg_map.max_lrg_id()) { >>> continue; // Value is a recent spill-copy >>> } >>> if (lrgs(lidx).is_singledef()) { >>> continue; >>> } >>> >>> Block *b_def = _cfg.get_block_for_node(def); >>> int idx_def = b_def->find_node(def); >>> Node *in_spill = get_spillcopy_wide( in, def, i ); >>> if( !in_spill ) return 0; // Bailed out >>> insert_proj(b_def,idx_def,in_spill,maxlrg++); >>> if( b_def == b ) >>> insidx++; >>> def->set_req(i,in_spill); >>> } >>> } >>> >>> We do not need to do this for live ranges with only a single definition. >>> We also do not do this for recently created spill copies. Recent spill copies refers to spill copies created in the >>> current split pass, that have not yet been assigned live ranges. >>> >>> The problem is that spill copies may introduce phi nodes due to different reaching definitions from different control >>> paths. And phi nodes introduces coalescing; in the end of a split pass we coalesce phi inputs with the phi itself (for >>> all phi nodes created in the split pass). >>> So what happens if a phi input is a recent spill copy? The recent spill copy get coalesced with the phi (and the live >>> range of the the spill copy and the phi will be multi defined). >>> And what happens if this recent spill copy is input to a re-materialized node? Then we introduce the risk of stretching >>> the live range beyond another def. (*) >>> >>> This is exactly what happens in prior bugs JDK-8005956 and JDK-8016157. When I solved them, I did not know well enough >>> what the problem was, so I disabled re-materialization for some nodes. Now I know better and instead I can add the same >>> support for recent spill copies, i.e. I create private copies for them as well. At the same time, I can remove the old >>> temporary solutions. >>> >>> I have verified that JDK-8005956 now also works with the new solution. Unfortunately I have not been able to reproduce >>> JDK-8016157, but I have been able to solve a new bug, JDK-7196566, using this new solution. >>> >>> I have also verified that this fix does not give any performance regressions. >>> http://sthaurora-ds.se.oracle.com/performance/rest/submit/runStatus?name=REG_SPLIT >>> http://sthaurora-ds.se.oracle.com/performance/rest/perf/report?name=REG_SPLIT >>> >>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8022783 >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> (*) It is tricky because this can not happen by just coalescing a recent spill copy (as phi input) with its phi node >>> 'P'. It happens because the input for 'P' is also a phi, which is THEN coalesced together with the recent spill copy. >>> Simply put, we need more than one recursion of coalescing in the split pass for this to happen. > From niclas.adlertz at oracle.com Thu Oct 17 10:42:06 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 17 Oct 2013 19:42:06 +0200 Subject: RFR(XS) 8022783: Nashorn test fails with: assert(!def_outside->member(r)) In-Reply-To: References: <525EA389.7040902@oracle.com> <525EBD55.3010002@oracle.com> <525FB7D9.9030804@oracle.com> Message-ID: <78FA995A-D563-4C73-8558-0E3A001A6EA7@oracle.com> Thanks Vladimir and Christian. Kind Regards, Niclas Adlertz On 17 okt 2013, at 19:35, Christian Thalinger wrote: > Looks good. > > On Oct 17, 2013, at 3:11 AM, Niclas Adlertz wrote: > >> Thanks Vladimir. >> >> http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev01/ >> >> Kind Regards, >> Niclas Adlertz >> >> On 2013-10-16 18:22, Vladimir Kozlov wrote: >>> Niclas, >>> >>> You need to change/add comments in this code. Otherwise it is good. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/16/13 7:32 AM, Niclas Adlertz wrote: >>>> Hi all, >>>> >>>> Despite the fact that I have not been able to reproduce JDK-8022783, it generates the same error as many other bugs; >>>> JDK-7033056, JDK-8016269, JDK-8011770, JDK-8005956, JDK-8016157 and JDK-7196566. >>>> They are all related to re-materialization. One major concern when re-materializing is that each input node to the >>>> re-materialized node might need to have its live range 'L' stretched. >>>> If 'L' is defined at multiple places (due to coalescing), we might stretch one definition of 'L' beyond another definition. >>>> >>>> Currently we handle this by doing a private copy of the input in the same block as the node that is being >>>> re-materialized. This happens at the beginning of PhaseChaitin::Split_Rematerialize: >>>> >>>> // The input live ranges will be stretched to the site of the new >>>> // instruction. They might be stretched past a def and will thus >>>> // have the old and new values of the same live range alive at the >>>> // same time - a definite no-no. Split out private copies of >>>> // the inputs. >>>> if( def->req() > 1 ) { >>>> for( uint i = 1; i < def->req(); i++ ) { >>>> Node *in = def->in(i); >>>> // Check for single-def (LRG cannot redefined) >>>> uint lidx = _lrg_map.live_range_id(in); >>>> if (lidx >= _lrg_map.max_lrg_id()) { >>>> continue; // Value is a recent spill-copy >>>> } >>>> if (lrgs(lidx).is_singledef()) { >>>> continue; >>>> } >>>> >>>> Block *b_def = _cfg.get_block_for_node(def); >>>> int idx_def = b_def->find_node(def); >>>> Node *in_spill = get_spillcopy_wide( in, def, i ); >>>> if( !in_spill ) return 0; // Bailed out >>>> insert_proj(b_def,idx_def,in_spill,maxlrg++); >>>> if( b_def == b ) >>>> insidx++; >>>> def->set_req(i,in_spill); >>>> } >>>> } >>>> >>>> We do not need to do this for live ranges with only a single definition. >>>> We also do not do this for recently created spill copies. Recent spill copies refers to spill copies created in the >>>> current split pass, that have not yet been assigned live ranges. >>>> >>>> The problem is that spill copies may introduce phi nodes due to different reaching definitions from different control >>>> paths. And phi nodes introduces coalescing; in the end of a split pass we coalesce phi inputs with the phi itself (for >>>> all phi nodes created in the split pass). >>>> So what happens if a phi input is a recent spill copy? The recent spill copy get coalesced with the phi (and the live >>>> range of the the spill copy and the phi will be multi defined). >>>> And what happens if this recent spill copy is input to a re-materialized node? Then we introduce the risk of stretching >>>> the live range beyond another def. (*) >>>> >>>> This is exactly what happens in prior bugs JDK-8005956 and JDK-8016157. When I solved them, I did not know well enough >>>> what the problem was, so I disabled re-materialization for some nodes. Now I know better and instead I can add the same >>>> support for recent spill copies, i.e. I create private copies for them as well. At the same time, I can remove the old >>>> temporary solutions. >>>> >>>> I have verified that JDK-8005956 now also works with the new solution. Unfortunately I have not been able to reproduce >>>> JDK-8016157, but I have been able to solve a new bug, JDK-7196566, using this new solution. >>>> >>>> I have also verified that this fix does not give any performance regressions. >>>> http://sthaurora-ds.se.oracle.com/performance/rest/submit/runStatus?name=REG_SPLIT >>>> http://sthaurora-ds.se.oracle.com/performance/rest/perf/report?name=REG_SPLIT >>>> >>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8022783/webrev00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8022783 >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> (*) It is tricky because this can not happen by just coalescing a recent spill copy (as phi input) with its phi node >>>> 'P'. It happens because the input for 'P' is also a phi, which is THEN coalesced together with the recent spill copy. >>>> Simply put, we need more than one recursion of coalescing in the split pass for this to happen. >> > From roland.westrelin at oracle.com Thu Oct 17 10:55:21 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 17 Oct 2013 19:55:21 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <52326202.1020807@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> Message-ID: <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> Here is a new webrev for this: http://cr.openjdk.java.net/~roland/8024070/webrev.01/ I applied your suggestions below. I kept the "speculative" name. "Profiling" in the code indicates profiling data that we use right away so reusing profiling for this, I find confusing. I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some problems that need investigation. I did extensive testing with the CastPPNodes. Can we keep them for now and reconsider that later? type.cpp has several generic type system fixes: 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && !klass_is_exact()) { 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), tp->klass_is_exact(), offset, instance_id, speculative); 3186 } else { mimics what we do for instance klass with subclass/superclass when both subclass and superclass are exact 3315 if( this_klass->is_interface() && !(tinst_klass->is_interface() || 3316 tinst_klass == ciEnv::current()->Object_klass())) { is required because otherwise if tinst_klass is of an object class, we swap tinst_* and this_* but don't enter the next if() and we use this->_ptr and tinst->_ptr which were not swapped. I also had to make the cases: 3818 case AnyNull: 3819 case TopPTR: and 3847 case NotNull: 3848 case BotPTR: symmetrical which they are not currently. Roland. > General notes: > > I think 'speculative' is not right word. We get these types from profiling when we see only one type. And we use it only after generated checks. 'profiled' will be more accurate and clear where it comes from. Or other more appropriate name. > > You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types). > > Please, explain why we need CastPP. In merge points it will leak to Phi nodes and further anyway. > > Small notes: > > c2_globals.hpp: > > TypeSpeculation --> UseTypeSpeculation > > drop_speculative* --> remove_speculative* > > Why change all TypeInstPtr::make() if you have default value set for last parameters. > > In a lot of places you use: > t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() > > add Type::has_speculative_type() and Type::speculative_type() to use in such cases. > > library_call.cpp: typo: > > ciKlass* src_k, *dest_k; > ^ > regards, > Vladimir > > On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >> Roland, >> >> Thank you for doing this experiment. But Richards is faster ;) >> Regression could be also caused by different inlining (InlineSmallCode) >> because more uncommon traps are generated. >> Anyway, you convince me. Let me go through your changes again. I am also >> looking on your extra type profiling changes. >> >> Thanks, >> Vladimir >> >> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>> Can you try an other experiment (may be you did it already)? Always >>>>> (under flag) generate klass check (type_check_receiver()) when >>>>> unique type from profiling is more precise than type from static >>>>> analysis. Yes, we may get performance regression in cases where more >>>>> precise type is not needed. We need to test it and see how bad it is. >>>> >>>> This change in itself doesn't bring any performance improvement. It's >>>> here so that if we add more profiling points (8023657) we know what >>>> to do with the data from profiling. Type speculation + extra >>>> profiling show a perf improvement on nashorn (10-20% on some >>>> benchmarks with the nashorn.jar from jdk b105). To me the experiment >>>> that makes sense it to enable profiling from 8023657, do the type >>>> checks at the profiling points systematically and see what impact we >>>> see on perf. I did that with type checks on entry to the root method >>>> of the compilation for incoming arguments and at returns from calls >>>> that were not inlined and I had a clear regression on specjvm98. I >>>> don't remember the exact numbers. I can run the experiment again. >>> >>> This is the kind of results I get with nashorn: >>> deltablue: >>> current: 2345 >>> with type speculation and extra profiling: 2662 >>> with extra profiling and systematic type checks: 2285 >>> >>> RayTrace: >>> current: 1978 >>> with type speculation and extra profiling: 2113 >>> with extra profiling and systematic type checks: 1795 >>> >>> Richards: >>> current: 2222 >>> with type speculation and extra profiling: 2489 >>> with extra profiling and systematic type checks: 2563 >>> >>> "extra profiling and systematic type checks" is: >>> - type checks for incoming arguments on method entry for the root >>> method of the compilation >>> - type check on return from non inlined calls >>> >>> so a limited subset of type checks but that gives us type for value >>> flowing in the compiled method. Eventhought the number of checks is >>> limited, it is sufficient to cause a regression on standard benchmarks: >>> >>> ============================================================================ >>> >>> t >>> Benchmark Samples Mean Stdev >>> specjvm98 10 663.84 0.01 >>> javac 10 385.70 0.05 >>> db 10 444.51 0.01 >>> jess 10 699.05 0.00 >>> jack 10 603.98 0.01 >>> compress 10 534.99 0.01 >>> mtrt 10 1694.45 0.01 >>> mpegaudio 10 866.77 0.00 >>> ============================================================================ >>> >>> t2 >>> Benchmark Samples Mean Stdev %Diff P >>> Significant >>> specjvm98 10 654.39 0.01 -1.42 >>> 0.014 * >>> javac 10 356.46 0.07 -7.58 >>> 0.013 * >>> db 10 444.87 0.01 0.08 >>> 0.875 * >>> jess 10 681.66 0.01 -2.49 >>> 0.000 Yes >>> jack 10 601.90 0.01 -0.34 >>> 0.425 * >>> compress 10 538.06 0.02 0.57 >>> 0.329 * >>> mtrt 10 1722.77 0.03 1.67 >>> 0.181 * >>> mpegaudio 10 854.38 0.01 -1.43 >>> 0.001 Yes >>> ============================================================================ >>> >>> >>> Roland. >>> From roland.westrelin at oracle.com Thu Oct 17 11:44:21 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 17 Oct 2013 20:44:21 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <525DACB8.9070400@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> Message-ID: <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> Here is a new webrev with more comments. http://cr.openjdk.java.net/~roland/8026251/webrev.02/ Roland. On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: > On 10/14/13 2:19 PM, Roland Westrelin wrote: >> >> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >> >>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> Thanks for the comments. >>>> >>>>> I wish you added more comments to the code. >>>> >>>> Do you want me to send another webrev? >>> >>> I would wait review from Christian before updating webrev. >>> >>>> >>>>> >>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>> >>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>> >>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>> >>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>> >>> arg = x->profiled_arg_at(i); >> >> Yes. > > Okay. > > Thanks, > Vladimir > >> >> Roland. >> >>> >>> Vladimir >>> >>>> >>>>> methodData.cpp Rename args_cell to params_cell: >>>>> >>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>> + if (args_cell > 0) { >>>> >>>> Ok. >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>> The last of the series of new type profiling points. >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>> >>>>>> The output of PrintMethodData is: >>>>>> >>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>> interpreter_invocation_count: 5000 >>>>>> invocation_counter: 5000 >>>>>> backedge_counter: 0 >>>>>> mdo size: 444 bytes >>>>>> >>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>> 1: stack(1) 'TestProfiling$A' >>>>>> >>>>>> Roland. >>>>>> >>>> >> From albert.noll at oracle.com Thu Oct 17 13:09:19 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 17 Oct 2013 22:09:19 +0200 Subject: RFR(XS): 8024008: Nashorn V8 (Crypto) benchmark crashes with small CodeCache size In-Reply-To: <5252FA2F.6050102@oracle.com> References: <522DD453.4010809@oracle.com> <522E09C4.1070700@oracle.com> <522EC44F.2060005@oracle.com> <522F1612.4030606@oracle.com> <522FA629.10509@oracle.com> <524DB4B6.7040201@oracle.com> <524DC536.5030602@oracle.com> <5252FA2F.6050102@oracle.com> Message-ID: <526043EF.70401@oracle.com> Hi, here is an updated webrev: let me explain the changes here: I strongly assume that these changes will solve https://bugs.openjdk.java.net/browse/JDK-8026407 CompileBroker.cpp: * if (!should_compile_new_jobs()) {* * CompilationPolicy::policy()->delay_compilation(method());* * return NULL;* * }* I think these lines are wrong and we must create the wrapper. * AdapterHandlerLibrary::create_native_wrapper(method, compile_id);* We need to create the wrapper to be able to call a native method from compiled code. Furthermore, the wrapper is not allocated form the code cache. It is allocated from a pre-allocated piece of memory. sharedRuntime.cpp * // CodeCache is full, disable compilation* * // Ought to log this but compile log is only per compile thread* * // and we're some non descript Java thread.* * MutexUnlocker mu(AdapterHandlerLibrary_lock);* *! CompileBroker::handle_full_code_cache();* *- return NULL; // Out of CodeCache space* This code is useless, since *AdapterBlob::create(&buffer) *allocates from a pre-allocated chunk of memory and not from the 'normal code cache'. In addition, this code caused some errors, since handle_full_code_cache() calls the sweeper. The calling thread needs to be in the correct state and is not allowed to own certain locks. This can cause problems. Same here: * } else {* * // CodeCache is full, disable compilation* * CompileBroker::handle_full_code_cache();* In addition, I introduced a new product flag, AdapterHandlerLibrarySize . The reason is that when running nashorn with very small code cache size (e.g., <5m), the error message that there is not enoug memory the hold adapters is quite frequently. Also, I think that having that value hidden in sharedRuntime.cpp is not the best way. I doubled the default size to 32K. This is sufficient to execute nashorn with a code cache size of 3500k. On 07.10.2013 20:15, Albert Noll wrote: > Hi Valdimir, > > thanks for you feedback. If the generation of the > AdapterHandlerLibrary wrapper is optional, the following changes in > compileBroker.cpp should work: > > > // If the compiler is shut off due to code cache getting full > // fail out now so blocking compiles dont hang the java thread > // if ( !should_compile_new_jobs()) { > // CompilationPolicy::policy()->delay_compilation(method()); > // return NULL; > // } > > // do the compilation > if (method->is_native()) { > if (!PreferInterpreterNativeStubs || > method->is_method_handle_intrinsic()) { > // Acquire our lock. > // int compile_id; > // { > // MutexLocker locker(MethodCompileQueue_lock, THREAD); > // compile_id = assign_compile_id(method, standard_entry_bci); > // } > // (void) AdapterHandlerLibrary::create_native_wrapper(method, > compile_id); > } else { > return NULL; > } > } else { > compile_method_base(method, osr_bci, comp_level, hot_method, > hot_count, comment, THREAD); > } > > However, with the changes above, I get the "i2c adapter must return to > an interpreter frame" even > if the code cache is not full and compilation remains enabled. > Something seems really broken here. > > Irrespective of the current bug, it seems that checking whether we > should compile new methods > in line 1304 in compileBroker.cpp does not make much sense, since this > bit can change asynchronously > any time. It made more sense before 8020151, but now I think it is > time to remove it. > > Best, > Albert > > On 03.10.2013 21:27, Vladimir Kozlov wrote: >> Albert, >> >> I don't see connection between not generating wrapper (which is fine, >> it is only needed for hot calls to native method) and wrong return >> address when calling i2c adapter (failed message). Can you find what >> return address is? >> >> It could be a different problem (or not) from what this bug about. >> Several things can go bad when codecache is full. Also attached to >> bug report hs_err files shows different crushes. >> >> Was you able to reproduce it with fastdebug VM? Switch off >> -XX:-CheckCompressedOops to get the same code generation as with >> product 64-bit VM. And switch off -XX:-VerifyDependencies to speed >> testing (10x, this test is very expensive). >> >> Also can you try to run with latest VM version which has fixes to >> produce more info for call stack in hs_err. To have only next lines >> is not useful: >> >> C 0x0000000648baace0 >> [error occurred during error reporting (printing native stack), id 0xb] >> >> Thanks, >> Vladimir >> >> On 10/3/13 11:17 AM, Albert Noll wrote: >>> Hi, >>> >>> I think I found the reason for the crash. Please forget the previous >>> suggestions. >>> >>> See the following webrev: >>> >>> Problem: >>> http://cr.openjdk.java.net/~anoll/8024008/webrev.02/ >>> >>> If the code cache gets full, this code in compileBroker.cpp is not >>> executed. >>> >>> 1318 (void) >>> AdapterHandlerLibrary::create_native_wrapper(method, compile_id); >>> >>> As a result, we get the following error "i2c adapter must return to >>> an interpreter frame" >>> if the JVM is called with "-XX:+UnlockDiagnosticVMOptions >>> -XX:+VerifyAdapterCalls" >>> >>> I do not yet fully understand why that's the case, so please if you >>> know let me know. >>> >>> Solution: >>> Move the code cache is full-check after line 1318. >>> >>> Many thanks, >>> Albert >>> >>> >>> Am 11.09.2013 01:07, schrieb Vladimir Kozlov: >>>> Albert, >>>> >>>> I would suggest to run as many tests as possible to verify correctness >>>> of changes because this code is very important. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/10/13 5:52 AM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> the current version causes a serious performance regression. >>>>> I have to figure out what's wrong. >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 10.09.2013 09:03, Albert Noll wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> thanks for looking at this. I checked all call sites of >>>>>> 'make_not_entrant()' and 'make_zombie()'. I do not see any problems. >>>>>> The worst thing that can happen is that an nmethod for which the >>>>>> call >>>>>> returns fals gets removed later than expected. >>>>>> >>>>>> I updated the comment and did some minor code refactoring. >>>>>> >>>>>> Also I think that it is worth considering to backport this change, >>>>>> since the bug can appear any time >>>>>> the code cache fills up. If that bug appears, it is extremely >>>>>> hard to >>>>>> reproduce and debug. >>>>>> >>>>>> Here is the updated webrev. >>>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.01/ >>>>>> >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> >>>>>> On 09.09.2013 19:47, Vladimir Kozlov wrote: >>>>>>> Several places in sources do not check returned result of >>>>>>> make_not_entrant_or_zombie(). And they may assume that method >>>>>>> marked >>>>>>> as non-entrant, for example, because before we returned 'false' >>>>>>> only >>>>>>> when an other thread already changed the state to one we need. >>>>>>> >>>>>>> Can you check all call sites to make sure they work correctly with >>>>>>> this change? >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/9/13 6:59 AM, Albert Noll wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> thanks for reviewing this patch. >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024008 >>>>>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Many thanks in advance, >>>>>>>> Albert >>>>>>>> >>>>>>>> Problem: >>>>>>>> The state of nmethods that are currently locked by the VM must not >>>>>>>> change. >>>>>>>> Some operations such as setting ICs (e.g., >>>>>>>> SharedRuntime::resolve_sub_helper()) >>>>>>>> rely on this fact. 'nmethod::make_not_entrant_or_zombie does not >>>>>>>> make this >>>>>>>> check. >>>>>>>> >>>>>>>> Solution: >>>>>>>> Do method state unchanged of nmethod is locked by the VM. >>>>>>>> >>>>>>>> Testing: Run Octane benchmarks on top of Nashorn with small code >>>>>>>> cache size (16m). >>>>>>>> >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131017/3511f4ad/attachment.html From vladimir.kozlov at oracle.com Thu Oct 17 15:09:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Oct 2013 15:09:08 -0700 Subject: RFR(XS): 8024008: Nashorn V8 (Crypto) benchmark crashes with small CodeCache size In-Reply-To: <526043EF.70401@oracle.com> References: <522DD453.4010809@oracle.com> <522E09C4.1070700@oracle.com> <522EC44F.2060005@oracle.com> <522F1612.4030606@oracle.com> <522FA629.10509@oracle.com> <524DB4B6.7040201@oracle.com> <524DC536.5030602@oracle.com> <5252FA2F.6050102@oracle.com> <526043EF.70401@oracle.com> Message-ID: <52606004.4050009@oracle.com> Albert, You are mistaking. AdapterBlob::create(&buffer) is used only during code generation (the same as temp buffer for C2 and C1). The nmethod::new() nmethod(), called from nmethod::new_native_nmethod(), will relocate the code to CodeCache. So we need space in CodeCache for adapters and native wrappers. Vladimir On 10/17/13 1:09 PM, Albert Noll wrote: > Hi, > > here is an updated webrev: let me explain the changes here: > I strongly assume that these changes will solve > https://bugs.openjdk.java.net/browse/JDK-8026407 > > CompileBroker.cpp: > > * if (!should_compile_new_jobs()) {* > * CompilationPolicy::policy()->delay_compilation(method());* > * return NULL;* > * }* > > I think these lines are wrong and we must create the wrapper. > > * AdapterHandlerLibrary::create_native_wrapper(method, compile_id);* > > > We need to create the wrapper to be able to call a native method from > compiled code. > Furthermore, the wrapper is not allocated form the code cache. It is > allocated from > a pre-allocated piece of memory. > > sharedRuntime.cpp > > * // CodeCache is full, disable compilation* > * // Ought to log this but compile log is only per compile thread* > * // and we're some non descript Java thread.* > * MutexUnlocker mu(AdapterHandlerLibrary_lock);* > *! CompileBroker::handle_full_code_cache();* > *- return NULL; // Out of CodeCache space* > > > This code is useless, since *AdapterBlob::create(&buffer) *allocates from > a pre-allocated chunk of memory and not from the 'normal code cache'. In > addition, this code caused some errors, since handle_full_code_cache() calls > the sweeper. The calling thread needs to be in the correct state and is > not allowed to > own certain locks. This can cause problems. > > Same here: > > * } else {* > * // CodeCache is full, disable compilation* > * CompileBroker::handle_full_code_cache();* > > > In addition, I introduced a new product flag, AdapterHandlerLibrarySize . > The reason is that when running nashorn with very small code cache size > (e.g., <5m), > the error message that there is not enoug memory the hold adapters is > quite frequently. > Also, I think that having that value hidden in sharedRuntime.cpp is not > the best way. I doubled > the default size to 32K. This is sufficient to execute nashorn with a > code cache size of 3500k. > > > On 07.10.2013 20:15, Albert Noll wrote: >> Hi Valdimir, >> >> thanks for you feedback. If the generation of the >> AdapterHandlerLibrary wrapper is optional, the following changes in >> compileBroker.cpp should work: >> >> >> // If the compiler is shut off due to code cache getting full >> // fail out now so blocking compiles dont hang the java thread >> // if ( !should_compile_new_jobs()) { >> // CompilationPolicy::policy()->delay_compilation(method()); >> // return NULL; >> // } >> >> // do the compilation >> if (method->is_native()) { >> if (!PreferInterpreterNativeStubs || >> method->is_method_handle_intrinsic()) { >> // Acquire our lock. >> // int compile_id; >> // { >> // MutexLocker locker(MethodCompileQueue_lock, THREAD); >> // compile_id = assign_compile_id(method, standard_entry_bci); >> // } >> // (void) AdapterHandlerLibrary::create_native_wrapper(method, >> compile_id); >> } else { >> return NULL; >> } >> } else { >> compile_method_base(method, osr_bci, comp_level, hot_method, >> hot_count, comment, THREAD); >> } >> >> However, with the changes above, I get the "i2c adapter must return to >> an interpreter frame" even >> if the code cache is not full and compilation remains enabled. >> Something seems really broken here. >> >> Irrespective of the current bug, it seems that checking whether we >> should compile new methods >> in line 1304 in compileBroker.cpp does not make much sense, since this >> bit can change asynchronously >> any time. It made more sense before 8020151, but now I think it is >> time to remove it. >> >> Best, >> Albert >> >> On 03.10.2013 21:27, Vladimir Kozlov wrote: >>> Albert, >>> >>> I don't see connection between not generating wrapper (which is fine, >>> it is only needed for hot calls to native method) and wrong return >>> address when calling i2c adapter (failed message). Can you find what >>> return address is? >>> >>> It could be a different problem (or not) from what this bug about. >>> Several things can go bad when codecache is full. Also attached to >>> bug report hs_err files shows different crushes. >>> >>> Was you able to reproduce it with fastdebug VM? Switch off >>> -XX:-CheckCompressedOops to get the same code generation as with >>> product 64-bit VM. And switch off -XX:-VerifyDependencies to speed >>> testing (10x, this test is very expensive). >>> >>> Also can you try to run with latest VM version which has fixes to >>> produce more info for call stack in hs_err. To have only next lines >>> is not useful: >>> >>> C 0x0000000648baace0 >>> [error occurred during error reporting (printing native stack), id 0xb] >>> >>> Thanks, >>> Vladimir >>> >>> On 10/3/13 11:17 AM, Albert Noll wrote: >>>> Hi, >>>> >>>> I think I found the reason for the crash. Please forget the previous >>>> suggestions. >>>> >>>> See the following webrev: >>>> >>>> Problem: >>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.02/ >>>> >>>> If the code cache gets full, this code in compileBroker.cpp is not >>>> executed. >>>> >>>> 1318 (void) >>>> AdapterHandlerLibrary::create_native_wrapper(method, compile_id); >>>> >>>> As a result, we get the following error "i2c adapter must return to >>>> an interpreter frame" >>>> if the JVM is called with "-XX:+UnlockDiagnosticVMOptions >>>> -XX:+VerifyAdapterCalls" >>>> >>>> I do not yet fully understand why that's the case, so please if you >>>> know let me know. >>>> >>>> Solution: >>>> Move the code cache is full-check after line 1318. >>>> >>>> Many thanks, >>>> Albert >>>> >>>> >>>> Am 11.09.2013 01:07, schrieb Vladimir Kozlov: >>>>> Albert, >>>>> >>>>> I would suggest to run as many tests as possible to verify correctness >>>>> of changes because this code is very important. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/10/13 5:52 AM, Albert Noll wrote: >>>>>> Hi, >>>>>> >>>>>> the current version causes a serious performance regression. >>>>>> I have to figure out what's wrong. >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> On 10.09.2013 09:03, Albert Noll wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> thanks for looking at this. I checked all call sites of >>>>>>> 'make_not_entrant()' and 'make_zombie()'. I do not see any problems. >>>>>>> The worst thing that can happen is that an nmethod for which the >>>>>>> call >>>>>>> returns fals gets removed later than expected. >>>>>>> >>>>>>> I updated the comment and did some minor code refactoring. >>>>>>> >>>>>>> Also I think that it is worth considering to backport this change, >>>>>>> since the bug can appear any time >>>>>>> the code cache fills up. If that bug appears, it is extremely >>>>>>> hard to >>>>>>> reproduce and debug. >>>>>>> >>>>>>> Here is the updated webrev. >>>>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.01/ >>>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 09.09.2013 19:47, Vladimir Kozlov wrote: >>>>>>>> Several places in sources do not check returned result of >>>>>>>> make_not_entrant_or_zombie(). And they may assume that method >>>>>>>> marked >>>>>>>> as non-entrant, for example, because before we returned 'false' >>>>>>>> only >>>>>>>> when an other thread already changed the state to one we need. >>>>>>>> >>>>>>>> Can you check all call sites to make sure they work correctly with >>>>>>>> this change? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/9/13 6:59 AM, Albert Noll wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> thanks for reviewing this patch. >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8024008 >>>>>>>>> http://cr.openjdk.java.net/~anoll/8024008/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Many thanks in advance, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> Problem: >>>>>>>>> The state of nmethods that are currently locked by the VM must not >>>>>>>>> change. >>>>>>>>> Some operations such as setting ICs (e.g., >>>>>>>>> SharedRuntime::resolve_sub_helper()) >>>>>>>>> rely on this fact. 'nmethod::make_not_entrant_or_zombie does not >>>>>>>>> make this >>>>>>>>> check. >>>>>>>>> >>>>>>>>> Solution: >>>>>>>>> Do method state unchanged of nmethod is locked by the VM. >>>>>>>>> >>>>>>>>> Testing: Run Octane benchmarks on top of Nashorn with small code >>>>>>>>> cache size (16m). >>>>>>>>> >>>>>>> >>>>>> >>>> >> > From vladimir.kozlov at oracle.com Thu Oct 17 18:39:47 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Oct 2013 18:39:47 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> Message-ID: <52609163.3070800@oracle.com> It is good. Thank you for this. Vladimir On 10/17/13 11:44 AM, Roland Westrelin wrote: > Here is a new webrev with more comments. > > http://cr.openjdk.java.net/~roland/8026251/webrev.02/ > > Roland. > > > On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: > >> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>> >>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>> >>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> Thanks for the comments. >>>>> >>>>>> I wish you added more comments to the code. >>>>> >>>>> Do you want me to send another webrev? >>>> >>>> I would wait review from Christian before updating webrev. >>>> >>>>> >>>>>> >>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>> >>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>> >>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>> >>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>> >>>> arg = x->profiled_arg_at(i); >>> >>> Yes. >> >> Okay. >> >> Thanks, >> Vladimir >> >>> >>> Roland. >>> >>>> >>>> Vladimir >>>> >>>>> >>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>> >>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>> + if (args_cell > 0) { >>>>> >>>>> Ok. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>> The last of the series of new type profiling points. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>> >>>>>>> The output of PrintMethodData is: >>>>>>> >>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>> interpreter_invocation_count: 5000 >>>>>>> invocation_counter: 5000 >>>>>>> backedge_counter: 0 >>>>>>> mdo size: 444 bytes >>>>>>> >>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>> >>>>>>> Roland. >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Thu Oct 17 19:51:39 2013 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 18 Oct 2013 02:51:39 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Message-ID: <20131018025153.BFF87624F5@hg.openjdk.java.net> Changeset: 74e00b98d5dd Author: anoll Date: 2013-10-17 19:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/74e00b98d5dd 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation Summary: Increase size for the template interpreter accordingly Reviewed-by: kvn, twisti ! src/cpu/x86/vm/templateInterpreter_x86.hpp From vladimir.kozlov at oracle.com Thu Oct 17 20:21:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Oct 2013 20:21:12 -0700 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> Message-ID: <5260A928.2010305@oracle.com> On 10/17/13 10:55 AM, Roland Westrelin wrote: > Here is a new webrev for this: > > http://cr.openjdk.java.net/~roland/8024070/webrev.01/ > > I applied your suggestions below. > I kept the "speculative" name. "Profiling" in the code indicates profiling data that we use right away so reusing profiling for this, I find confusing. Okay. > I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some problems that need investigation. I did extensive testing with the CastPPNodes. Can we keep them for now and reconsider that later? Yes, it is fine. > > type.cpp has several generic type system fixes: > > 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && !klass_is_exact()) { > 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), tp->klass_is_exact(), offset, instance_id, speculative); > 3186 } else { Looks correct but, please, make sure it works for multi-dimensional object arrays. And run full CTW tests and all jtregs. I am concern that sometimes exact Object klass may be not really exact. > > mimics what we do for instance klass with subclass/superclass when both subclass and superclass are exact > > 3315 if( this_klass->is_interface() && !(tinst_klass->is_interface() || > 3316 tinst_klass == ciEnv::current()->Object_klass())) { > > is required because otherwise if tinst_klass is of an object class, we swap tinst_* and this_* but don't enter the next if() and we use this->_ptr and tinst->_ptr which were not swapped. Seems reasonable. > > I also had to make the cases: > > 3818 case AnyNull: > 3819 case TopPTR: > > and > > 3847 case NotNull: > 3848 case BotPTR: > > symmetrical which they are not currently. Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong place (it was always false). With your changes the code is still not symmetrical. I think in last case (NotNull or BotPTR) when klass() == tap->klass() we need to pass const_oop() to constructor. This is what we do when tap is Const and 'this' is below. I need to look on whole changes later. I will send additional comments. Thanks, Vladimir > > Roland. > >> General notes: >> >> I think 'speculative' is not right word. We get these types from profiling when we see only one type. And we use it only after generated checks. 'profiled' will be more accurate and clear where it comes from. Or other more appropriate name. >> >> You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types). >> >> Please, explain why we need CastPP. In merge points it will leak to Phi nodes and further anyway. >> >> Small notes: >> >> c2_globals.hpp: >> >> TypeSpeculation --> UseTypeSpeculation >> >> drop_speculative* --> remove_speculative* >> >> Why change all TypeInstPtr::make() if you have default value set for last parameters. >> >> In a lot of places you use: >> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >> >> add Type::has_speculative_type() and Type::speculative_type() to use in such cases. >> >> library_call.cpp: typo: >> >> ciKlass* src_k, *dest_k; >> ^ >> regards, >> Vladimir >> >> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>> Roland, >>> >>> Thank you for doing this experiment. But Richards is faster ;) >>> Regression could be also caused by different inlining (InlineSmallCode) >>> because more uncommon traps are generated. >>> Anyway, you convince me. Let me go through your changes again. I am also >>> looking on your extra type profiling changes. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>> Can you try an other experiment (may be you did it already)? Always >>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>> unique type from profiling is more precise than type from static >>>>>> analysis. Yes, we may get performance regression in cases where more >>>>>> precise type is not needed. We need to test it and see how bad it is. >>>>> >>>>> This change in itself doesn't bring any performance improvement. It's >>>>> here so that if we add more profiling points (8023657) we know what >>>>> to do with the data from profiling. Type speculation + extra >>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>> benchmarks with the nashorn.jar from jdk b105). To me the experiment >>>>> that makes sense it to enable profiling from 8023657, do the type >>>>> checks at the profiling points systematically and see what impact we >>>>> see on perf. I did that with type checks on entry to the root method >>>>> of the compilation for incoming arguments and at returns from calls >>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>> don't remember the exact numbers. I can run the experiment again. >>>> >>>> This is the kind of results I get with nashorn: >>>> deltablue: >>>> current: 2345 >>>> with type speculation and extra profiling: 2662 >>>> with extra profiling and systematic type checks: 2285 >>>> >>>> RayTrace: >>>> current: 1978 >>>> with type speculation and extra profiling: 2113 >>>> with extra profiling and systematic type checks: 1795 >>>> >>>> Richards: >>>> current: 2222 >>>> with type speculation and extra profiling: 2489 >>>> with extra profiling and systematic type checks: 2563 >>>> >>>> "extra profiling and systematic type checks" is: >>>> - type checks for incoming arguments on method entry for the root >>>> method of the compilation >>>> - type check on return from non inlined calls >>>> >>>> so a limited subset of type checks but that gives us type for value >>>> flowing in the compiled method. Eventhought the number of checks is >>>> limited, it is sufficient to cause a regression on standard benchmarks: >>>> >>>> ============================================================================ >>>> >>>> t >>>> Benchmark Samples Mean Stdev >>>> specjvm98 10 663.84 0.01 >>>> javac 10 385.70 0.05 >>>> db 10 444.51 0.01 >>>> jess 10 699.05 0.00 >>>> jack 10 603.98 0.01 >>>> compress 10 534.99 0.01 >>>> mtrt 10 1694.45 0.01 >>>> mpegaudio 10 866.77 0.00 >>>> ============================================================================ >>>> >>>> t2 >>>> Benchmark Samples Mean Stdev %Diff P >>>> Significant >>>> specjvm98 10 654.39 0.01 -1.42 >>>> 0.014 * >>>> javac 10 356.46 0.07 -7.58 >>>> 0.013 * >>>> db 10 444.87 0.01 0.08 >>>> 0.875 * >>>> jess 10 681.66 0.01 -2.49 >>>> 0.000 Yes >>>> jack 10 601.90 0.01 -0.34 >>>> 0.425 * >>>> compress 10 538.06 0.02 0.57 >>>> 0.329 * >>>> mtrt 10 1722.77 0.03 1.67 >>>> 0.181 * >>>> mpegaudio 10 854.38 0.01 -1.43 >>>> 0.001 Yes >>>> ============================================================================ >>>> >>>> >>>> Roland. >>>> > From serguei.spitsyn at oracle.com Fri Oct 18 01:25:21 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 18 Oct 2013 01:25:21 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <525FDC25.30805@oracle.com> References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> <525FDC25.30805@oracle.com> Message-ID: <5260F071.6080708@oracle.com> Vladimir, Just want to share some details with you. On 10/17/13 5:46 AM, Vladimir Ivanov wrote: > Serguei, Chris, Igor, thanks for looking at this fix. > > I need to look more thoroughly at this code. > I assumed that member name is initialized only once, but I was wrong - > asserting empty slot in MethodHandles::init_method_MemberName fails > during initialization of JSR292 core classes. John or Chris, please, correct me if I'm wrong... But, I think, John had a plan in mind to utilize the MNT for uniqueness of member names. It was about all member names, not only method member names. Thanks, Serguei > > Best regards, > Vladimir Ivanov > > On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: >> On 10/16/13 1:28 PM, Christian Thalinger wrote: >>> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >>> wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>>> 7 lines changed: 5 ins; 1 del; 1 mod >>>> >>>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>>> assert(m.vminfoIsConsistent()); >>>> >>>> After that check, class redefinition is broken - it's still possible >>>> to invoke old version of a method. >>>> >>>> Analysis from Serguei: >>>> "The problem is here: >>>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>>> info) { >>>> . . . . . . . . >>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>> >>>> return mname(); >>>> } >>>> >>>> The call to add_member_name() resets the member name at the index >>>> m->method_idnum(). After that one of the two member names with the >>>> same method_idnum() is out of the MNT and is not updated when the >>>> method is redefined." >>> As I understand this the problem is calling >>> MethodHandles::init_method_MemberName which installs a new MemberName >>> instance in the MemberNameTable. Correct? >>> >>> If that's the case then there is a potential race here. >>> >>> + x = m->method_holder()->get_member_name(m->method_idnum()); >>> + if (x == NULL) { >>> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >>> x = MethodHandles::init_method_MemberName(mname2, info); >>> } >>> >>> Racing threads can get back null when calling get_member_name and then >>> install different MemberName objects in the table. >> >> Good catch, Chris. >> I do not see a way to fix it easily without some refactoring. >> >> It is probably better to add to the InstanceKlass a helper function that >> will do >> this dance with a required synchronization. >> But the following line needs to be taken out of the >> init_method_MemberName() : >> m->method_holder()->add_member_name(m->method_idnum(), mname); >> >> >> Thanks, >> Serguei >> >>> >>>> The fix is to check whether there's already a member name associated >>>> with the before creating a new one. >>>> >>>> Testing: failing test. >>>> >>>> Contributed-by: sspitsyn, vlivanov >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >> From rickard.backman at oracle.com Fri Oct 18 02:34:54 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Fri, 18 Oct 2013 11:34:54 +0200 Subject: RFR(L) 8026844: Various Math functions needs intrinsification Message-ID: <20131018093454.GC17703@rbackman> Hi, can I get reviews for the following change: This change creates intrinsics for addExact(long, long), subtractExact, negateExact, incrementExact, decrementExact and multiplyExact. The intrinsics are only added on x86 and only 64-bit has the intrinsics for the long-versions. (32-bit only has int-versions). Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ Thanks /R From niclas.adlertz at oracle.com Fri Oct 18 06:34:26 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Fri, 18 Oct 2013 13:34:26 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131018133442.3D63C6251B@hg.openjdk.java.net> Changeset: 1856ea98184a Author: adlertz Date: 2013-10-18 10:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1856ea98184a 8022783: Nashorn test fails with: assert(!def_outside->member(r)) Summary: Enables private copies of inputs for recent spill copies as well Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/reg_split.cpp Changeset: e3b736cf4fa3 Author: adlertz Date: 2013-10-18 09:36 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e3b736cf4fa3 Merge From vladimir.kozlov at oracle.com Fri Oct 18 08:50:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Oct 2013 08:50:42 -0700 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <20131018093454.GC17703@rbackman> References: <20131018093454.GC17703@rbackman> Message-ID: <526158D2.8080601@oracle.com> Rickard, is_MathExactOpcode() could be replaced by adding the node to DEFINE_CLASS_ID structure as you did with FlagsProj. is_MathExact() will be true for all its subclasses. Put MathExactNode() constructors together. In library_call.cpp can you name Integer version of method with I: inline_math_addExactI() to be symmetrical with Long version. And I don't think you need separate methods for increment and decrement - path flag to add and sub method. Why you did not implement mulexact(reg, mem) mach nodes? Otherwise it is good. Thanks, Vladimir On 10/18/13 2:34 AM, Rickard B?ckman wrote: > Hi, can I get reviews for the following change: > > This change creates intrinsics for addExact(long, long), subtractExact, > negateExact, incrementExact, decrementExact and multiplyExact. > > The intrinsics are only added on x86 and only 64-bit has the intrinsics > for the long-versions. (32-bit only has int-versions). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > > Thanks > /R > From christian.thalinger at oracle.com Fri Oct 18 09:14:26 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 09:14:26 -0700 Subject: RFR(XS): 8026708: guarantee(codelet_size > 0 && (size_t)codelet_size > 2*K) failed: not enough space for interpreter generation In-Reply-To: <525FA3E6.5050003@oracle.com> References: <525EE76E.3050105@oracle.com> <525EE8FA.5000407@oracle.com> <525EF1AF.7020500@oracle.com> <525EFDEB.6060406@oracle.com> <525FA3E6.5050003@oracle.com> Message-ID: On Oct 17, 2013, at 1:46 AM, Albert Noll wrote: > Christian, Vladimir, thanks for looking at the patch. > > Increasing the space that is reserved for the template interpreter leaves 45K (2K reserved for alignment) of availbale space if the > following options are used (64-bit): > > java -Xmixed -server -d64 -XX:+UseParallelGC -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter -XX:-UseCompressedOops -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 -XX:+VerifyOops > > code size = 208K bytes > total space = 255K bytes > wasted space = 47K bytes > > # of codelets = 264 > avg codelet size = 808 bytes > > > I was not aware that '-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000' requires so much space > in the interpreter. Sorry for that! Me neither. Nothing to be sorry about :-) > > I am fine with the current solution (256k for 64-bit and 224k for 32-bit). The change is good. > > Best, > Albert > > > On 16.10.2013 22:58, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 10/16/13 1:06 PM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for the review. I agree, this gives us more air. >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8026708/webrev.01/ >>> >>> >>> Best, >>> Albert >>> >>> P.S.: I had the wrong header to the mail. The bug id is actually 8026708. >>> >>> >>> >>> On 16.10.2013 21:28, Vladimir Kozlov wrote: >>>> I think we should increase it more for future otherwise you will have >>>> to always catch up with interpreter changes. >>>> >>>> Increase it to 256 * 1024 and 224 * 1024 >>>> >>>> Vladimir >>>> >>>> On 10/16/13 12:22 PM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> could I have a review for this patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026708 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8026708/webrev.00/ >>>>> >>>>> >>>>> Problem: Not enough room for interpreter. My last patch did not solve >>>>> the problem for solaris-amd64. >>>>> A local build (solaris-amd64) of the most recent >>>>> hotspot-comp version requires a template interpreter >>>>> size of 211K (obtained with -XX:+PrintInterpreter). >>>>> There have been some modifications to the template >>>>> interpreter in the last couple of weeks which might have >>>>> triggered this error. >>>>> >>>>> Solution: Increase interpreter size by 8k (32-bit and 64-bit). >>>>> >>>>> Testing: Failing test case in solaris-amd64 >>>>> >>>>> >>>>> Many thanks in advance, >>>>> Albert >>> > From roland.westrelin at oracle.com Fri Oct 18 09:19:17 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 18 Oct 2013 18:19:17 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <5260A928.2010305@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> Message-ID: <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> Hi Vladimir, On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov wrote: > On 10/17/13 10:55 AM, Roland Westrelin wrote: >> Here is a new webrev for this: >> >> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >> >> I applied your suggestions below. >> I kept the "speculative" name. "Profiling" in the code indicates profiling data that we use right away so reusing profiling for this, I find confusing. > > Okay. > >> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some problems that need investigation. I did extensive testing with the CastPPNodes. Can we keep them for now and reconsider that later? > > Yes, it is fine. > >> >> type.cpp has several generic type system fixes: >> >> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && !klass_is_exact()) { >> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), tp->klass_is_exact(), offset, instance_id, speculative); >> 3186 } else { > > Looks correct but, please, make sure it works for multi-dimensional object arrays. And run full CTW tests and all jtregs. I am concern that sometimes exact Object klass may be not really exact. Ok. > >> >> mimics what we do for instance klass with subclass/superclass when both subclass and superclass are exact >> >> 3315 if( this_klass->is_interface() && !(tinst_klass->is_interface() || >> 3316 tinst_klass == ciEnv::current()->Object_klass())) { >> >> is required because otherwise if tinst_klass is of an object class, we swap tinst_* and this_* but don't enter the next if() and we use this->_ptr and tinst->_ptr which were not swapped. > > Seems reasonable. > >> >> I also had to make the cases: >> >> 3818 case AnyNull: >> 3819 case TopPTR: >> >> and >> >> 3847 case NotNull: >> 3848 case BotPTR: >> >> symmetrical which they are not currently. > > Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong place (it was always false). > With your changes the code is still not symmetrical. I think in last case (NotNull or BotPTR) when klass() == tap->klass() we need to pass const_oop() to constructor. This is what we do when tap is Const and 'this' is below. Wouldn't this be sufficient as a fix? diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp --- a/src/share/vm/opto/type.cpp +++ b/src/share/vm/opto/type.cpp @@ -3851,7 +3851,7 @@ xk = tap->_klass_is_exact; else xk = (tap->_klass_is_exact & this->_klass_is_exact) && (klass() == tap->klass()); // Only precise for identical arrays - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, instance_id, speculative); + return TypeAryPtr::make(ptr, tap->const_oop(), tary, lazy_klass, xk, off, instance_id, speculative); default: ShouldNotReachHere(); } } tap->const_oop() would be non NULL for a Constant only and xk is set correctly if klass() == tap->klass() I've been trying to write simple tests to reproduce those failures without much success. Any suggestion what simple java code I can write to have something of ptr type AnyNull? Thanks, Roland. > > I need to look on whole changes later. I will send additional comments. > > Thanks, > Vladimir > >> >> Roland. >> >>> General notes: >>> >>> I think 'speculative' is not right word. We get these types from profiling when we see only one type. And we use it only after generated checks. 'profiled' will be more accurate and clear where it comes from. Or other more appropriate name. >>> >>> You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types). >>> >>> Please, explain why we need CastPP. In merge points it will leak to Phi nodes and further anyway. >>> >>> Small notes: >>> >>> c2_globals.hpp: >>> >>> TypeSpeculation --> UseTypeSpeculation >>> >>> drop_speculative* --> remove_speculative* >>> >>> Why change all TypeInstPtr::make() if you have default value set for last parameters. >>> >>> In a lot of places you use: >>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>> >>> add Type::has_speculative_type() and Type::speculative_type() to use in such cases. >>> >>> library_call.cpp: typo: >>> >>> ciKlass* src_k, *dest_k; >>> ^ >>> regards, >>> Vladimir >>> >>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>> Roland, >>>> >>>> Thank you for doing this experiment. But Richards is faster ;) >>>> Regression could be also caused by different inlining (InlineSmallCode) >>>> because more uncommon traps are generated. >>>> Anyway, you convince me. Let me go through your changes again. I am also >>>> looking on your extra type profiling changes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>> Can you try an other experiment (may be you did it already)? Always >>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>> unique type from profiling is more precise than type from static >>>>>>> analysis. Yes, we may get performance regression in cases where more >>>>>>> precise type is not needed. We need to test it and see how bad it is. >>>>>> >>>>>> This change in itself doesn't bring any performance improvement. It's >>>>>> here so that if we add more profiling points (8023657) we know what >>>>>> to do with the data from profiling. Type speculation + extra >>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>> benchmarks with the nashorn.jar from jdk b105). To me the experiment >>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>> checks at the profiling points systematically and see what impact we >>>>>> see on perf. I did that with type checks on entry to the root method >>>>>> of the compilation for incoming arguments and at returns from calls >>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>> don't remember the exact numbers. I can run the experiment again. >>>>> >>>>> This is the kind of results I get with nashorn: >>>>> deltablue: >>>>> current: 2345 >>>>> with type speculation and extra profiling: 2662 >>>>> with extra profiling and systematic type checks: 2285 >>>>> >>>>> RayTrace: >>>>> current: 1978 >>>>> with type speculation and extra profiling: 2113 >>>>> with extra profiling and systematic type checks: 1795 >>>>> >>>>> Richards: >>>>> current: 2222 >>>>> with type speculation and extra profiling: 2489 >>>>> with extra profiling and systematic type checks: 2563 >>>>> >>>>> "extra profiling and systematic type checks" is: >>>>> - type checks for incoming arguments on method entry for the root >>>>> method of the compilation >>>>> - type check on return from non inlined calls >>>>> >>>>> so a limited subset of type checks but that gives us type for value >>>>> flowing in the compiled method. Eventhought the number of checks is >>>>> limited, it is sufficient to cause a regression on standard benchmarks: >>>>> >>>>> ============================================================================ >>>>> >>>>> t >>>>> Benchmark Samples Mean Stdev >>>>> specjvm98 10 663.84 0.01 >>>>> javac 10 385.70 0.05 >>>>> db 10 444.51 0.01 >>>>> jess 10 699.05 0.00 >>>>> jack 10 603.98 0.01 >>>>> compress 10 534.99 0.01 >>>>> mtrt 10 1694.45 0.01 >>>>> mpegaudio 10 866.77 0.00 >>>>> ============================================================================ >>>>> >>>>> t2 >>>>> Benchmark Samples Mean Stdev %Diff P >>>>> Significant >>>>> specjvm98 10 654.39 0.01 -1.42 >>>>> 0.014 * >>>>> javac 10 356.46 0.07 -7.58 >>>>> 0.013 * >>>>> db 10 444.87 0.01 0.08 >>>>> 0.875 * >>>>> jess 10 681.66 0.01 -2.49 >>>>> 0.000 Yes >>>>> jack 10 601.90 0.01 -0.34 >>>>> 0.425 * >>>>> compress 10 538.06 0.02 0.57 >>>>> 0.329 * >>>>> mtrt 10 1722.77 0.03 1.67 >>>>> 0.181 * >>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>> 0.001 Yes >>>>> ============================================================================ >>>>> >>>>> >>>>> Roland. >>>>> >> From roland.westrelin at oracle.com Fri Oct 18 09:26:56 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 18 Oct 2013 18:26:56 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <52609163.3070800@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> Message-ID: <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. http://cr.openjdk.java.net/~roland/8026251/webrev.03/ Roland. On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: > It is good. Thank you for this. > > Vladimir > > On 10/17/13 11:44 AM, Roland Westrelin wrote: >> Here is a new webrev with more comments. >> >> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >> >> Roland. >> >> >> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >> >>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>> >>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>> >>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> Thanks for the comments. >>>>>> >>>>>>> I wish you added more comments to the code. >>>>>> >>>>>> Do you want me to send another webrev? >>>>> >>>>> I would wait review from Christian before updating webrev. >>>>> >>>>>> >>>>>>> >>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>> >>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>> >>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>> >>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>> >>>>> arg = x->profiled_arg_at(i); >>>> >>>> Yes. >>> >>> Okay. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Roland. >>>> >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>> >>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>> + if (args_cell > 0) { >>>>>> >>>>>> Ok. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>> The last of the series of new type profiling points. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>> >>>>>>>> The output of PrintMethodData is: >>>>>>>> >>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>> interpreter_invocation_count: 5000 >>>>>>>> invocation_counter: 5000 >>>>>>>> backedge_counter: 0 >>>>>>>> mdo size: 444 bytes >>>>>>>> >>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>> >>>> >> From christian.thalinger at oracle.com Fri Oct 18 09:47:35 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 09:47:35 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <5260F071.6080708@oracle.com> References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> <525FDC25.30805@oracle.com> <5260F071.6080708@oracle.com> Message-ID: On Oct 18, 2013, at 1:25 AM, serguei.spitsyn at oracle.com wrote: > Vladimir, > > > Just want to share some details with you. > > > On 10/17/13 5:46 AM, Vladimir Ivanov wrote: >> Serguei, Chris, Igor, thanks for looking at this fix. >> >> I need to look more thoroughly at this code. >> I assumed that member name is initialized only once, but I was wrong - asserting empty slot in MethodHandles::init_method_MemberName fails during initialization of JSR292 core classes. > > John or Chris, please, correct me if I'm wrong... > But, I think, John had a plan in mind to utilize the MNT for uniqueness of member names. > It was about all member names, not only method member names. Correct. It is worrying that the assert fires. We should get to the bottom of this and fix it properly. > > > Thanks, > Serguei > >> >> Best regards, >> Vladimir Ivanov >> >> On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: >>> On 10/16/13 1:28 PM, Christian Thalinger wrote: >>>> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >>>> wrote: >>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>>>> 7 lines changed: 5 ins; 1 del; 1 mod >>>>> >>>>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>>>> assert(m.vminfoIsConsistent()); >>>>> >>>>> After that check, class redefinition is broken - it's still possible >>>>> to invoke old version of a method. >>>>> >>>>> Analysis from Serguei: >>>>> "The problem is here: >>>>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>>>> info) { >>>>> . . . . . . . . >>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>> >>>>> return mname(); >>>>> } >>>>> >>>>> The call to add_member_name() resets the member name at the index >>>>> m->method_idnum(). After that one of the two member names with the >>>>> same method_idnum() is out of the MNT and is not updated when the >>>>> method is redefined." >>>> As I understand this the problem is calling >>>> MethodHandles::init_method_MemberName which installs a new MemberName >>>> instance in the MemberNameTable. Correct? >>>> >>>> If that's the case then there is a potential race here. >>>> >>>> + x = m->method_holder()->get_member_name(m->method_idnum()); >>>> + if (x == NULL) { >>>> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >>>> x = MethodHandles::init_method_MemberName(mname2, info); >>>> } >>>> >>>> Racing threads can get back null when calling get_member_name and then >>>> install different MemberName objects in the table. >>> >>> Good catch, Chris. >>> I do not see a way to fix it easily without some refactoring. >>> >>> It is probably better to add to the InstanceKlass a helper function that >>> will do >>> this dance with a required synchronization. >>> But the following line needs to be taken out of the >>> init_method_MemberName() : >>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>>> The fix is to check whether there's already a member name associated >>>>> with the before creating a new one. >>>>> >>>>> Testing: failing test. >>>>> >>>>> Contributed-by: sspitsyn, vlivanov >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >>> > From christian.thalinger at oracle.com Fri Oct 18 10:23:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 10:23:15 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> Message-ID: <5CC33BCB-733F-4822-8F01-E4102626766A@oracle.com> Since InterpreterMacroAssembler::profile_parameters_type is basically them exact same code (except movl/neql vs. movq/negq and rdi vs. r14) can we create new files: src/cpu/x86/vm/interp_masm_x86.{cpp,hpp} and put the method there? I did a quick experiment locally and there is no problem. We should stop duplicating code. src/share/vm/oops/methodData.hpp: + // Offset with the MDO for the area dedicated to + // parameters. -1 if no parameter profiling. + int _parameters_type_data_di; What's "di"? Please rename. src/share/vm/runtime/globals.hpp: + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ Typo "js292". Maybe use "=" instead of "->". Are we printing the flag comments somewhere? If yes, then printing this will look very odd: ! "=XYZ, with Z, Type profiling of arguments at call" \ ! " Y, Type profiling of return value at call" \ ! " X, Type profiling of parameters to methods" \ + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ Since it will be one string without new lines or spaces. Same with this one: + product(intx, TypeProfileParmsLimit, 2, \ + "max number of incoming parameters to consider for type profiling"\ + "-1 for all") \ Otherwise this looks good. On Oct 18, 2013, at 9:26 AM, Roland Westrelin wrote: > Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. > > http://cr.openjdk.java.net/~roland/8026251/webrev.03/ > > Roland. > > > On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: > >> It is good. Thank you for this. >> >> Vladimir >> >> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>> Here is a new webrev with more comments. >>> >>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>> >>> Roland. >>> >>> >>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>> >>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>> >>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> Thanks for the comments. >>>>>>> >>>>>>>> I wish you added more comments to the code. >>>>>>> >>>>>>> Do you want me to send another webrev? >>>>>> >>>>>> I would wait review from Christian before updating webrev. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>> >>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>> >>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>> >>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>> >>>>>> arg = x->profiled_arg_at(i); >>>>> >>>>> Yes. >>>> >>>> Okay. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>> >>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>> + if (args_cell > 0) { >>>>>>> >>>>>>> Ok. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>> The last of the series of new type profiling points. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>> >>>>>>>>> The output of PrintMethodData is: >>>>>>>>> >>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>> invocation_counter: 5000 >>>>>>>>> backedge_counter: 0 >>>>>>>>> mdo size: 444 bytes >>>>>>>>> >>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Oct 18 10:24:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Oct 2013 10:24:40 -0700 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> Message-ID: <52616ED8.9020703@oracle.com> Roland, > tap->const_oop() would be non NULL for a Constant only and xk is set correctly if klass() == tap->klass() Lets leave NULL for now because in general meet(con, bot) = bot. It may change code generation more then other changes and we don't want it now. > > I've been trying to write simple tests to reproduce those failures without much success. Any suggestion what simple java code I can write to have something of ptr type AnyNull? AnyNull is ptr_dual for NotNull. Meets with it is checked in Type::meet(). So it should work for tests only with NotNull. Vladimir On 10/18/13 9:19 AM, Roland Westrelin wrote: > Hi Vladimir, > > On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov wrote: > >> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>> Here is a new webrev for this: >>> >>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>> >>> I applied your suggestions below. >>> I kept the "speculative" name. "Profiling" in the code indicates profiling data that we use right away so reusing profiling for this, I find confusing. >> >> Okay. >> >>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some problems that need investigation. I did extensive testing with the CastPPNodes. Can we keep them for now and reconsider that later? >> >> Yes, it is fine. >> >>> >>> type.cpp has several generic type system fixes: >>> >>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && !klass_is_exact()) { >>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), tp->klass_is_exact(), offset, instance_id, speculative); >>> 3186 } else { >> >> Looks correct but, please, make sure it works for multi-dimensional object arrays. And run full CTW tests and all jtregs. I am concern that sometimes exact Object klass may be not really exact. > > Ok. > >> >>> >>> mimics what we do for instance klass with subclass/superclass when both subclass and superclass are exact >>> >>> 3315 if( this_klass->is_interface() && !(tinst_klass->is_interface() || >>> 3316 tinst_klass == ciEnv::current()->Object_klass())) { >>> >>> is required because otherwise if tinst_klass is of an object class, we swap tinst_* and this_* but don't enter the next if() and we use this->_ptr and tinst->_ptr which were not swapped. >> >> Seems reasonable. >> >>> >>> I also had to make the cases: >>> >>> 3818 case AnyNull: >>> 3819 case TopPTR: >>> >>> and >>> >>> 3847 case NotNull: >>> 3848 case BotPTR: >>> >>> symmetrical which they are not currently. >> >> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong place (it was always false). >> With your changes the code is still not symmetrical. I think in last case (NotNull or BotPTR) when klass() == tap->klass() we need to pass const_oop() to constructor. This is what we do when tap is Const and 'this' is below. > > Wouldn't this be sufficient as a fix? > > diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp > --- a/src/share/vm/opto/type.cpp > +++ b/src/share/vm/opto/type.cpp > @@ -3851,7 +3851,7 @@ > xk = tap->_klass_is_exact; > else xk = (tap->_klass_is_exact & this->_klass_is_exact) && > (klass() == tap->klass()); // Only precise for identical arrays > - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, instance_id, speculative); > + return TypeAryPtr::make(ptr, tap->const_oop(), tary, lazy_klass, xk, off, instance_id, speculative); > default: ShouldNotReachHere(); > } > } > > tap->const_oop() would be non NULL for a Constant only and xk is set correctly if klass() == tap->klass() > > I've been trying to write simple tests to reproduce those failures without much success. Any suggestion what simple java code I can write to have something of ptr type AnyNull? > > Thanks, > Roland. > >> >> I need to look on whole changes later. I will send additional comments. >> >> Thanks, >> Vladimir >> >>> >>> Roland. >>> >>>> General notes: >>>> >>>> I think 'speculative' is not right word. We get these types from profiling when we see only one type. And we use it only after generated checks. 'profiled' will be more accurate and clear where it comes from. Or other more appropriate name. >>>> >>>> You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types). >>>> >>>> Please, explain why we need CastPP. In merge points it will leak to Phi nodes and further anyway. >>>> >>>> Small notes: >>>> >>>> c2_globals.hpp: >>>> >>>> TypeSpeculation --> UseTypeSpeculation >>>> >>>> drop_speculative* --> remove_speculative* >>>> >>>> Why change all TypeInstPtr::make() if you have default value set for last parameters. >>>> >>>> In a lot of places you use: >>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>> >>>> add Type::has_speculative_type() and Type::speculative_type() to use in such cases. >>>> >>>> library_call.cpp: typo: >>>> >>>> ciKlass* src_k, *dest_k; >>>> ^ >>>> regards, >>>> Vladimir >>>> >>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>> Roland, >>>>> >>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>> Regression could be also caused by different inlining (InlineSmallCode) >>>>> because more uncommon traps are generated. >>>>> Anyway, you convince me. Let me go through your changes again. I am also >>>>> looking on your extra type profiling changes. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>> Can you try an other experiment (may be you did it already)? Always >>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>> unique type from profiling is more precise than type from static >>>>>>>> analysis. Yes, we may get performance regression in cases where more >>>>>>>> precise type is not needed. We need to test it and see how bad it is. >>>>>>> >>>>>>> This change in itself doesn't bring any performance improvement. It's >>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the experiment >>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>> checks at the profiling points systematically and see what impact we >>>>>>> see on perf. I did that with type checks on entry to the root method >>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>> >>>>>> This is the kind of results I get with nashorn: >>>>>> deltablue: >>>>>> current: 2345 >>>>>> with type speculation and extra profiling: 2662 >>>>>> with extra profiling and systematic type checks: 2285 >>>>>> >>>>>> RayTrace: >>>>>> current: 1978 >>>>>> with type speculation and extra profiling: 2113 >>>>>> with extra profiling and systematic type checks: 1795 >>>>>> >>>>>> Richards: >>>>>> current: 2222 >>>>>> with type speculation and extra profiling: 2489 >>>>>> with extra profiling and systematic type checks: 2563 >>>>>> >>>>>> "extra profiling and systematic type checks" is: >>>>>> - type checks for incoming arguments on method entry for the root >>>>>> method of the compilation >>>>>> - type check on return from non inlined calls >>>>>> >>>>>> so a limited subset of type checks but that gives us type for value >>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>> limited, it is sufficient to cause a regression on standard benchmarks: >>>>>> >>>>>> ============================================================================ >>>>>> >>>>>> t >>>>>> Benchmark Samples Mean Stdev >>>>>> specjvm98 10 663.84 0.01 >>>>>> javac 10 385.70 0.05 >>>>>> db 10 444.51 0.01 >>>>>> jess 10 699.05 0.00 >>>>>> jack 10 603.98 0.01 >>>>>> compress 10 534.99 0.01 >>>>>> mtrt 10 1694.45 0.01 >>>>>> mpegaudio 10 866.77 0.00 >>>>>> ============================================================================ >>>>>> >>>>>> t2 >>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>> Significant >>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>> 0.014 * >>>>>> javac 10 356.46 0.07 -7.58 >>>>>> 0.013 * >>>>>> db 10 444.87 0.01 0.08 >>>>>> 0.875 * >>>>>> jess 10 681.66 0.01 -2.49 >>>>>> 0.000 Yes >>>>>> jack 10 601.90 0.01 -0.34 >>>>>> 0.425 * >>>>>> compress 10 538.06 0.02 0.57 >>>>>> 0.329 * >>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>> 0.181 * >>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>> 0.001 Yes >>>>>> ============================================================================ >>>>>> >>>>>> >>>>>> Roland. >>>>>> >>> > From christian.thalinger at oracle.com Fri Oct 18 10:25:27 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 10:25:27 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: References: <090EEAB6-FDB5-414C-BC9A-E0484DC27B4B@oracle.com> Message-ID: <95BE2736-2899-4168-9C5B-D6DB22D77527@oracle.com> On Oct 16, 2013, at 2:23 AM, Roland Westrelin wrote: > > On Oct 15, 2013, at 8:50 PM, Christian Thalinger wrote: > >> >> On Oct 12, 2013, at 2:31 PM, Roland Westrelin wrote: >> >>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>> >>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. >> >> What if we would do a deep-clone? Are there any potential performance or memory issues? > > What this change targets is stuff happening during inlining. Inlining is not performed from within a PreserveJVMState. So the PreserveJVMState case is not something we want to optimize for. We just want to make sure a replace_in_map called from within a PreserveJVMState doesn't break something. Okay. > > Roland. > >> >>> The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>> >>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>> >>> Roland. >> > From christian.thalinger at oracle.com Fri Oct 18 10:31:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 10:31:40 -0700 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <3B5A17FD-B2B3-465B-905E-AC655BFF8A95@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> <525E4055.6090508@oracle.com> <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> <525E47A3.80103@oracle.com> <3B5A17FD-B2B3-465B-905E-AC655BFF8A95@oracle.com> Message-ID: <781B3A40-F1DE-4318-9B84-A4F8FEFCB759@oracle.com> src/share/vm/opto/c2_globals.hpp: + product(bool, ReplaceInParentMaps, false, \ + "Propagate type improvements in callers of inlinee if possible") As I hope the limitation to JSR 292 goes away in the future I'd like to be this flag an experimental flag. Removing product flags is non-trivial. Otherwise this looks good. On Oct 16, 2013, at 9:04 AM, Roland Westrelin wrote: >>>> I know we are rushing currently so we don't have time to do proper generic fix. >>>> Can you do it only for JSR292 methods where you see this pattern and preferably under flag? >>>> The less we change common code now is better. >>> >>> What about I don't try to restrict it to JSR292 methods (I'm concerned that if I'm too restrictive we can't even turn it on to see if it helps) but put it under a flag that is off by default? And then when type speculation is on, turning type speculation on turns this on as well? >> >> Yes, it is fine under flag. > > Here is a new webrev for this. The change is under a flag. It's off by default. I removed the useless library intrinsic changes. I now use parser->caller()->map(). > > http://cr.openjdk.java.net/~roland/8024069/webrev.01/ > > Roland. > >> >> Vladimir >> >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/16/13 12:15 AM, Roland Westrelin wrote: >>>>> >>>>> On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/15/13 3:31 AM, Roland Westrelin wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> Thanks for reviewing this. >>>>>>> >>>>>>>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>>>>>>> _inline_cg->generate(jvms, NULL); >>>>>>> >>>>>>> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? >>>>>> >>>>>> Yes, you are right. But you still have exit.jvms in which you can do replacement. >>>>> >>>>> Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. >>>>> >>>>>> >>>>>>> >>>>>>>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >>>>>>> >>>>>>> You're right. We don't need to care about intrinsics. >>>>>>> >>>>>>> So in GraphKit::replace_in_map(). this: >>>>>>> >>>>>>> if (parser == NULL) { >>>>>>> parser = parent_parser(); >>>>>>> } >>>>>>> >>>>>>> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >>>>>>> >>>>>>>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >>>>>>> >>>>>>> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >>>>>>> >>>>>>>> >>>>>>>> And I don't understand where 1) requirement comes from. >>>>>>> >>>>>>> If we have something like this: >>>>>>> >>>>>>> void m(A a) { >>>>>>> if (some_condition) { >>>>>>> B b = (B)a; >>>>>>> } else { >>>>>>> // some other stuff >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. >>>>>> >>>>>> What about this case? We should be keeping the cast: >>>>>> >>>>>> void m(A a) { >>>>>> if (some_condition) { >>>>>> // some other stuff >>>>>> } >>>>>> B b = (B)a; >>>>>> } >>>>>> >>>>> >>>>> This case we could handle in my change by skipping over simple ifs. >>>>> >>>>>> I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). >>>>> >>>>> >>>>> For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. >>>>> >>>>> void m(A a) { >>>>> B b = (B)b; >>>>> // maybe some more stuff after >>>>> } >>>>> >>>>> If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> I am fine with moving is_uncommon_trap_*() mathods. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>>>>>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>>>>>>> >>>>>>>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>> >>>>> >>> > From roland.westrelin at oracle.com Fri Oct 18 10:50:17 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 18 Oct 2013 19:50:17 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <5CC33BCB-733F-4822-8F01-E4102626766A@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <5CC33BCB-733F-4822-8F01-E4102626766A@oracle.com> Message-ID: <24303E32-ADB5-4536-80AA-7D55E5A83A06@oracle.com> Thanks for looking at this. On Oct 18, 2013, at 7:23 PM, Christian Thalinger wrote: > Since InterpreterMacroAssembler::profile_parameters_type is basically them exact same code (except movl/neql vs. movq/negq and rdi vs. r14) can we create new files: > > src/cpu/x86/vm/interp_masm_x86.{cpp,hpp} > > and put the method there? I did a quick experiment locally and there is no problem. We should stop duplicating code. Ok. I'll give it a try. > > src/share/vm/oops/methodData.hpp: > > + // Offset with the MDO for the area dedicated to > + // parameters. -1 if no parameter profiling. > + int _parameters_type_data_di; > > What's "di"? Please rename. di is used elsewhere several times in that code together with dp. // Convert a dp (data pointer) to a di (data index). int dp_to_di(address dp) const { Roland. > > src/share/vm/runtime/globals.hpp: > > + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ > > Typo "js292". Maybe use "=" instead of "->". > > Are we printing the flag comments somewhere? If yes, then printing this will look very odd: > > ! "=XYZ, with Z, Type profiling of arguments at call" \ > ! " Y, Type profiling of return value at call" \ > ! " X, Type profiling of parameters to methods" \ > + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ > > Since it will be one string without new lines or spaces. Same with this one: > > + product(intx, TypeProfileParmsLimit, 2, \ > + "max number of incoming parameters to consider for type profiling"\ > + "-1 for all") \ > > Otherwise this looks good. > > On Oct 18, 2013, at 9:26 AM, Roland Westrelin wrote: > >> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >> >> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >> >> Roland. >> >> >> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >> >>> It is good. Thank you for this. >>> >>> Vladimir >>> >>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>> Here is a new webrev with more comments. >>>> >>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>> >>>> Roland. >>>> >>>> >>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>> >>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>> >>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Thanks for the comments. >>>>>>>> >>>>>>>>> I wish you added more comments to the code. >>>>>>>> >>>>>>>> Do you want me to send another webrev? >>>>>>> >>>>>>> I would wait review from Christian before updating webrev. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>> >>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>> >>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>> >>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>> >>>>>>> arg = x->profiled_arg_at(i); >>>>>> >>>>>> Yes. >>>>> >>>>> Okay. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>> >>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>> + if (args_cell > 0) { >>>>>>>> >>>>>>>> Ok. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>> >>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>> >>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>> invocation_counter: 5000 >>>>>>>>>> backedge_counter: 0 >>>>>>>>>> mdo size: 444 bytes >>>>>>>>>> >>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From morris.meyer at oracle.com Fri Oct 18 11:33:43 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 18 Oct 2013 14:33:43 -0400 Subject: RFR(S): 8008242: VerifyOops fails on SPARC Message-ID: <52617F07.40007@oracle.com> Folks, Could I get a quick follow-up review for this issue? Christian Thalinger has looked this over, and it has been through JPRT. Per Christian and Vladimir Kozlov - the getClass intrinsic is using the result variable which has the type T_OBJECT also as temporary which should have the type T_METADATA. This was okay with perm-gen but now this doesn't work anymore. This is combined with my earlier displacement fixes. --morris meyer JBS - https://bugs.openjdk.java.net/browse/JDK-8008242 WEBREV - http://cr.openjdk.java.net/~morris/8008242.02/ From christian.thalinger at oracle.com Fri Oct 18 11:39:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 11:39:55 -0700 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> Message-ID: <2FFC4F1F-D534-4EA8-A4F6-C60BAC27A007@oracle.com> src/share/vm/ci/ciMethod.hpp: + // Return true if profiling provides a type for the argument nb to + // the call at bci. type is the profiled type. + bool argument_profiled_type(int bci, int nb, ciKlass*& type); + // Return true if profiling provides a type for the parameter nb to + // this method. type is the profiled type. + bool parameter_profiled_type(int nb, ciKlass*& type); + // Return true if profiling provides a type for the return value + // from the call at bci. type is the profiled type. + bool return_profiled_type(int bci, ciKlass*& type); We don't need documentation in both places, .hpp and .cpp; they will get out of sync. It's sufficient to have it in .cpp. Same in src/share/vm/opto/compile.hpp, src/share/vm/opto/graphKit.hpp, and others. I bring it up from time to time but if we are already adding new method comments we could as well use the Doxygen format. Eclipse actually supports Doxygen and highlights the comments properly: http://www.semipol.de/archives/230 src/share/vm/opto/callGenerator.cpp: + ciKlass* spec_receiver_type = NULL; Rename it to "speculative_receiver_type". src/share/vm/opto/compile.hpp: ! JVMState* jvms, bool allow_inline, float profile_factor, ciKlass* spec_rcvr_type = NULL, src/share/vm/opto/doCall.cpp: ! float prof_factor, ciKlass* spec_rcvr_type, And these too. Simply, use that name everywhere. src/share/vm/opto/compile.cpp: ! if(ptr == TypePtr::NotNull || ta->klass_is_exact() || ta->speculative() != NULL) { When you are already removing the spaces could you add a space after the if? "if (". src/share/vm/opto/doCall.cpp: ! ciKlass *k = spec_rcvr_type != NULL ? spec_rcvr_type : profile.receiver(0); Should be "ciKlass* k". Do we have this in the style guide? https://wiki.openjdk.java.net/display/HotSpot/StyleGuide Nope, but we should add it. One thing it says is: ? Put spaces on both sides of control flow keywords if, else, for, switch, etc. * Use extra parentheses in expressions whenever operator precedence seems doubtful. Always use parentheses in shift/mask expressions (<<, &, |, ~). src/share/vm/opto/graphKit.cpp: + // Dow we know the type check always succeed? Typo "Dow". src/share/vm/opto/parse2.cpp: + (c->in(1)->Opcode() == Op_LoadKlass || c->in(1)->Opcode() == Op_DecodeNKlass ) && + c = _gvn.transform( new (C) CmpPNode(b, a) ); Remove extra spaces. It's difficult to follow all the changes in type.cpp but I hope you did enough testing. Looks good. On Oct 17, 2013, at 10:55 AM, Roland Westrelin wrote: > Here is a new webrev for this: > > http://cr.openjdk.java.net/~roland/8024070/webrev.01/ > > I applied your suggestions below. > I kept the "speculative" name. "Profiling" in the code indicates profiling data that we use right away so reusing profiling for this, I find confusing. > I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some problems that need investigation. I did extensive testing with the CastPPNodes. Can we keep them for now and reconsider that later? > > type.cpp has several generic type system fixes: > > 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && !klass_is_exact()) { > 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), tp->klass_is_exact(), offset, instance_id, speculative); > 3186 } else { > > mimics what we do for instance klass with subclass/superclass when both subclass and superclass are exact > > 3315 if( this_klass->is_interface() && !(tinst_klass->is_interface() || > 3316 tinst_klass == ciEnv::current()->Object_klass())) { > > is required because otherwise if tinst_klass is of an object class, we swap tinst_* and this_* but don't enter the next if() and we use this->_ptr and tinst->_ptr which were not swapped. > > I also had to make the cases: > > 3818 case AnyNull: > 3819 case TopPTR: > > and > > 3847 case NotNull: > 3848 case BotPTR: > > symmetrical which they are not currently. > > Roland. > >> General notes: >> >> I think 'speculative' is not right word. We get these types from profiling when we see only one type. And we use it only after generated checks. 'profiled' will be more accurate and clear where it comes from. Or other more appropriate name. >> >> You need to add jtreg tests to verify these changes for different cases (especially merge points with different profile types). >> >> Please, explain why we need CastPP. In merge points it will leak to Phi nodes and further anyway. >> >> Small notes: >> >> c2_globals.hpp: >> >> TypeSpeculation --> UseTypeSpeculation >> >> drop_speculative* --> remove_speculative* >> >> Why change all TypeInstPtr::make() if you have default value set for last parameters. >> >> In a lot of places you use: >> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >> >> add Type::has_speculative_type() and Type::speculative_type() to use in such cases. >> >> library_call.cpp: typo: >> >> ciKlass* src_k, *dest_k; >> ^ >> regards, >> Vladimir >> >> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>> Roland, >>> >>> Thank you for doing this experiment. But Richards is faster ;) >>> Regression could be also caused by different inlining (InlineSmallCode) >>> because more uncommon traps are generated. >>> Anyway, you convince me. Let me go through your changes again. I am also >>> looking on your extra type profiling changes. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>> Can you try an other experiment (may be you did it already)? Always >>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>> unique type from profiling is more precise than type from static >>>>>> analysis. Yes, we may get performance regression in cases where more >>>>>> precise type is not needed. We need to test it and see how bad it is. >>>>> >>>>> This change in itself doesn't bring any performance improvement. It's >>>>> here so that if we add more profiling points (8023657) we know what >>>>> to do with the data from profiling. Type speculation + extra >>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>> benchmarks with the nashorn.jar from jdk b105). To me the experiment >>>>> that makes sense it to enable profiling from 8023657, do the type >>>>> checks at the profiling points systematically and see what impact we >>>>> see on perf. I did that with type checks on entry to the root method >>>>> of the compilation for incoming arguments and at returns from calls >>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>> don't remember the exact numbers. I can run the experiment again. >>>> >>>> This is the kind of results I get with nashorn: >>>> deltablue: >>>> current: 2345 >>>> with type speculation and extra profiling: 2662 >>>> with extra profiling and systematic type checks: 2285 >>>> >>>> RayTrace: >>>> current: 1978 >>>> with type speculation and extra profiling: 2113 >>>> with extra profiling and systematic type checks: 1795 >>>> >>>> Richards: >>>> current: 2222 >>>> with type speculation and extra profiling: 2489 >>>> with extra profiling and systematic type checks: 2563 >>>> >>>> "extra profiling and systematic type checks" is: >>>> - type checks for incoming arguments on method entry for the root >>>> method of the compilation >>>> - type check on return from non inlined calls >>>> >>>> so a limited subset of type checks but that gives us type for value >>>> flowing in the compiled method. Eventhought the number of checks is >>>> limited, it is sufficient to cause a regression on standard benchmarks: >>>> >>>> ============================================================================ >>>> >>>> t >>>> Benchmark Samples Mean Stdev >>>> specjvm98 10 663.84 0.01 >>>> javac 10 385.70 0.05 >>>> db 10 444.51 0.01 >>>> jess 10 699.05 0.00 >>>> jack 10 603.98 0.01 >>>> compress 10 534.99 0.01 >>>> mtrt 10 1694.45 0.01 >>>> mpegaudio 10 866.77 0.00 >>>> ============================================================================ >>>> >>>> t2 >>>> Benchmark Samples Mean Stdev %Diff P >>>> Significant >>>> specjvm98 10 654.39 0.01 -1.42 >>>> 0.014 * >>>> javac 10 356.46 0.07 -7.58 >>>> 0.013 * >>>> db 10 444.87 0.01 0.08 >>>> 0.875 * >>>> jess 10 681.66 0.01 -2.49 >>>> 0.000 Yes >>>> jack 10 601.90 0.01 -0.34 >>>> 0.425 * >>>> compress 10 538.06 0.02 0.57 >>>> 0.329 * >>>> mtrt 10 1722.77 0.03 1.67 >>>> 0.181 * >>>> mpegaudio 10 854.38 0.01 -1.43 >>>> 0.001 Yes >>>> ============================================================================ >>>> >>>> >>>> Roland. >>>> > From christian.thalinger at oracle.com Fri Oct 18 11:42:27 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 11:42:27 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <24303E32-ADB5-4536-80AA-7D55E5A83A06@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <5CC33BCB-733F-4822-8F01-E4102626766A@oracle.com> <24303E32-ADB5-4536-80AA-7D55E5A83A06@oracle.com> Message-ID: On Oct 18, 2013, at 10:50 AM, Roland Westrelin wrote: > Thanks for looking at this. > > On Oct 18, 2013, at 7:23 PM, Christian Thalinger wrote: > >> Since InterpreterMacroAssembler::profile_parameters_type is basically them exact same code (except movl/neql vs. movq/negq and rdi vs. r14) can we create new files: >> >> src/cpu/x86/vm/interp_masm_x86.{cpp,hpp} >> >> and put the method there? I did a quick experiment locally and there is no problem. We should stop duplicating code. > > Ok. I'll give it a try. > >> >> src/share/vm/oops/methodData.hpp: >> >> + // Offset with the MDO for the area dedicated to >> + // parameters. -1 if no parameter profiling. >> + int _parameters_type_data_di; >> >> What's "di"? Please rename. > > di is used elsewhere several times in that code together with dp. > > // Convert a dp (data pointer) to a di (data index). > int dp_to_di(address dp) const { If you don't want to change the name then change the comment. It's talking about an offset. Is the data index the same as the offset? Same scale? > > Roland. > >> >> src/share/vm/runtime/globals.hpp: >> >> + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ >> >> Typo "js292". Maybe use "=" instead of "->". >> >> Are we printing the flag comments somewhere? If yes, then printing this will look very odd: >> >> ! "=XYZ, with Z, Type profiling of arguments at call" \ >> ! " Y, Type profiling of return value at call" \ >> ! " X, Type profiling of parameters to methods" \ >> + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ >> >> Since it will be one string without new lines or spaces. Same with this one: >> >> + product(intx, TypeProfileParmsLimit, 2, \ >> + "max number of incoming parameters to consider for type profiling"\ >> + "-1 for all") \ >> >> Otherwise this looks good. >> >> On Oct 18, 2013, at 9:26 AM, Roland Westrelin wrote: >> >>> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >>> >>> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >>> >>> Roland. >>> >>> >>> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >>> >>>> It is good. Thank you for this. >>>> >>>> Vladimir >>>> >>>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>>> Here is a new webrev with more comments. >>>>> >>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>>> >>>>> Roland. >>>>> >>>>> >>>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>>> >>>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> Thanks for the comments. >>>>>>>>> >>>>>>>>>> I wish you added more comments to the code. >>>>>>>>> >>>>>>>>> Do you want me to send another webrev? >>>>>>>> >>>>>>>> I would wait review from Christian before updating webrev. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>>> >>>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>>> >>>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>>> >>>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>>> >>>>>>>> arg = x->profiled_arg_at(i); >>>>>>> >>>>>>> Yes. >>>>>> >>>>>> Okay. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>>> >>>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>>> + if (args_cell > 0) { >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>>> >>>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>>> invocation_counter: 5000 >>>>>>>>>>> backedge_counter: 0 >>>>>>>>>>> mdo size: 444 bytes >>>>>>>>>>> >>>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From vladimir.kozlov at oracle.com Fri Oct 18 11:58:39 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Oct 2013 11:58:39 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> Message-ID: <526184DF.80305@oracle.com> Roland, You replaced profile_calls() && MethodData::profile_return() with simple profile_return(). But profile_return() does not check profile_calls(). Why? Thanks, Vladimir On 10/18/13 9:26 AM, Roland Westrelin wrote: > Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. > > http://cr.openjdk.java.net/~roland/8026251/webrev.03/ > > Roland. > > > On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: > >> It is good. Thank you for this. >> >> Vladimir >> >> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>> Here is a new webrev with more comments. >>> >>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>> >>> Roland. >>> >>> >>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>> >>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>> >>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> Thanks for the comments. >>>>>>> >>>>>>>> I wish you added more comments to the code. >>>>>>> >>>>>>> Do you want me to send another webrev? >>>>>> >>>>>> I would wait review from Christian before updating webrev. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>> >>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>> >>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>> >>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>> >>>>>> arg = x->profiled_arg_at(i); >>>>> >>>>> Yes. >>>> >>>> Okay. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>> >>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>> + if (args_cell > 0) { >>>>>>> >>>>>>> Ok. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>> The last of the series of new type profiling points. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>> >>>>>>>>> The output of PrintMethodData is: >>>>>>>>> >>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>> invocation_counter: 5000 >>>>>>>>> backedge_counter: 0 >>>>>>>>> mdo size: 444 bytes >>>>>>>>> >>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Oct 18 12:01:43 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Oct 2013 12:01:43 -0700 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <52617F07.40007@oracle.com> References: <52617F07.40007@oracle.com> Message-ID: <52618597.8070804@oracle.com> Good. Thanks, Vladimir On 10/18/13 11:33 AM, Morris Meyer wrote: > Folks, > > Could I get a quick follow-up review for this issue? Christian > Thalinger has looked this over, and it has been through JPRT. > > Per Christian and Vladimir Kozlov - the getClass intrinsic is using the > result variable which has the type T_OBJECT also as temporary which > should have the type T_METADATA. This was okay with perm-gen but now > this doesn't work anymore. > > This is combined with my earlier displacement fixes. > > --morris meyer > > JBS - https://bugs.openjdk.java.net/browse/JDK-8008242 > WEBREV - http://cr.openjdk.java.net/~morris/8008242.02/ From christian.thalinger at oracle.com Fri Oct 18 12:04:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 12:04:14 -0700 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <20131018093454.GC17703@rbackman> References: <20131018093454.GC17703@rbackman> Message-ID: <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> src/share/vm/opto/library_call.cpp: + Node* arg1 = argument(0); // type long + // argument(1) == TOP + Node* arg2 = argument(2); // type long + // argument(4) == TOP The "argument(4)" comment it wrong; should be 3. + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); Remove the extra spaces. src/share/vm/opto/mathexactnode.hpp: + MathExactNode(Node* ctrl, Node* n1); MathExactNode(Node* ctrl, Node* in1, Node* in2); Should "n1" be "in1"? Or maybe just "n". These have two copyright headers: test/compiler/intrinsics/mathexact/IncExactITest.java test/compiler/intrinsics/mathexact/IncExactLTest.java It seems all of the tests have a wrong bug number: 26 * @bug 8024924 or 26 * @bug 8025657 test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: 28 * @compile MulExactIRepeatTest.java That one doesn't compile Verify.java. Please check all of the test files for these issue. In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? The question is do we really need individual test files for these? I don't object just mentioning it. On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: > Hi, can I get reviews for the following change: > > This change creates intrinsics for addExact(long, long), subtractExact, > negateExact, incrementExact, decrementExact and multiplyExact. > > The intrinsics are only added on x86 and only 64-bit has the intrinsics > for the long-versions. (32-bit only has int-versions). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > > Thanks > /R From christian.thalinger at oracle.com Fri Oct 18 12:06:21 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 12:06:21 -0700 Subject: RFR(S): 8008242: VerifyOops fails on SPARC In-Reply-To: <52617F07.40007@oracle.com> References: <52617F07.40007@oracle.com> Message-ID: <6502FB08-819E-42C5-83B0-962EA5BF5946@oracle.com> Looks good. On Oct 18, 2013, at 11:33 AM, Morris Meyer wrote: > Folks, > > Could I get a quick follow-up review for this issue? Christian Thalinger has looked this over, and it has been through JPRT. > > Per Christian and Vladimir Kozlov - the getClass intrinsic is using the result variable which has the type T_OBJECT also as temporary which should have the type T_METADATA. This was okay with perm-gen but now this doesn't work anymore. > > This is combined with my earlier displacement fixes. > > --morris meyer > > JBS - https://bugs.openjdk.java.net/browse/JDK-8008242 > WEBREV - http://cr.openjdk.java.net/~morris/8008242.02/ From igor.ignatyev at oracle.com Fri Oct 18 12:28:18 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Oct 2013 23:28:18 +0400 Subject: RFR(S) : 8026414 : [TESTBUG] Tests for Tiered/NonTiered levels In-Reply-To: <165330A8-A107-4991-B438-E51EB69883F2@oracle.com> References: <525C4205.1060404@oracle.com> <165330A8-A107-4991-B438-E51EB69883F2@oracle.com> Message-ID: <52618BD2.6090102@oracle.com> Chris, Thank you for review. Could I have a second review for this from someone w/ 'a Reviewer' status? - Igor On 10/15/2013 10:29 PM, Christian Thalinger wrote: > Looks good. Nice usage of lambda :-) > > On Oct 14, 2013, at 12:12 PM, Igor Ignatyev wrote: > >> Hi all, >> >> Please review patch: >> >> New tests for TieredCompilation were developed. >> Tests verify that only 4(1) level is used when Tiered is disabled and all otherwise. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8026414/webrev.00/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8026414 >> testing: compiler/tiered w/ default flags and w/ the same flags as in nightly >> -- >> Best regards, >> Igor Ignatyev > From igor.ignatyev at oracle.com Fri Oct 18 12:29:33 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Oct 2013 23:29:33 +0400 Subject: RFR(XS) : 8023318 : compiler/whitebox tests timeout with enabled TieredCompilation In-Reply-To: <525C45F5.4010605@oracle.com> References: <525C413D.3020205@oracle.com> <525C45F5.4010605@oracle.com> Message-ID: <52618C1D.40207@oracle.com> Vladimir, thanks for review. Could I have a second review for this from someone w/ 'a Reviewer' status? - Igor On 10/14/2013 11:28 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 10/14/13 12:08 PM, Igor Ignatyev wrote: >> Hi all, >> >> Please review patch: >> >> Problem: >> OSR test cases in 'compiler/whitebox/*' takes too much time w/ enabled >> TieredCompilation. >> >> Fix: >> 'BACKEDGE_THRESHOLD' was decreased to 150000 for TieredCompilation. This >> value is enough, because all tests run w/ >> '-XX:CompileCommand=compileonly,TestCase$Helper::*', so compilation >> queue is empty. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8023318/webrev.00/ >> jbs: https://bugs.openjdk.java.net/browse/JDK-8023318 >> testing: compiler/whitebox w/ default flags and w/ the same flags as in >> nightly From christian.thalinger at oracle.com Fri Oct 18 13:08:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 18 Oct 2013 13:08:15 -0700 Subject: RFR(XS) : 8023318 : compiler/whitebox tests timeout with enabled TieredCompilation In-Reply-To: <52618C1D.40207@oracle.com> References: <525C413D.3020205@oracle.com> <525C45F5.4010605@oracle.com> <52618C1D.40207@oracle.com> Message-ID: <95EB1AC7-0738-47FF-B621-78D929C22FDC@oracle.com> Looks good. On Oct 18, 2013, at 12:29 PM, Igor Ignatyev wrote: > Vladimir, thanks for review. > > > Could I have a second review for this from someone w/ 'a Reviewer' status? > > - Igor > On 10/14/2013 11:28 PM, Vladimir Kozlov wrote: >> Good. >> >> Vladimir >> >> On 10/14/13 12:08 PM, Igor Ignatyev wrote: >>> Hi all, >>> >>> Please review patch: >>> >>> Problem: >>> OSR test cases in 'compiler/whitebox/*' takes too much time w/ enabled >>> TieredCompilation. >>> >>> Fix: >>> 'BACKEDGE_THRESHOLD' was decreased to 150000 for TieredCompilation. This >>> value is enough, because all tests run w/ >>> '-XX:CompileCommand=compileonly,TestCase$Helper::*', so compilation >>> queue is empty. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8023318/webrev.00/ >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8023318 >>> testing: compiler/whitebox w/ default flags and w/ the same flags as in >>> nightly From igor.veresov at oracle.com Fri Oct 18 14:16:40 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 18 Oct 2013 14:16:40 -0700 Subject: RFR(S) : 8026414 : [TESTBUG] Tests for Tiered/NonTiered levels In-Reply-To: <52618BD2.6090102@oracle.com> References: <525C4205.1060404@oracle.com> <165330A8-A107-4991-B438-E51EB69883F2@oracle.com> <52618BD2.6090102@oracle.com> Message-ID: <70CEEE1B-2295-4DE0-B560-767BF983D65A@oracle.com> Looks good. igor On Oct 18, 2013, at 12:28 PM, Igor Ignatyev wrote: > Chris, > Thank you for review. > > > Could I have a second review for this from someone w/ 'a Reviewer' status? > > - Igor > > On 10/15/2013 10:29 PM, Christian Thalinger wrote: >> Looks good. Nice usage of lambda :-) >> >> On Oct 14, 2013, at 12:12 PM, Igor Ignatyev wrote: >> >>> Hi all, >>> >>> Please review patch: >>> >>> New tests for TieredCompilation were developed. >>> Tests verify that only 4(1) level is used when Tiered is disabled and all otherwise. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8026414/webrev.00/ >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8026414 >>> testing: compiler/tiered w/ default flags and w/ the same flags as in nightly >>> -- >>> Best regards, >>> Igor Ignatyev >> From roland.westrelin at oracle.com Fri Oct 18 14:25:38 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 18 Oct 2013 23:25:38 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <526184DF.80305@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <526184DF.80305@oracle.com> Message-ID: <8AC6E3D9-6445-477C-BC68-DFC2BE1FD06B@oracle.com> > You replaced profile_calls() && MethodData::profile_return() with simple profile_return(). But profile_return() does not check profile_calls(). Why? > In profile_calls() && MethodData::profile_return(), the main reason for the profile_calls() was for the env()->comp_level() == CompLevel_full_profile test. profile_calls() also tests C1UpdateMethodData && C1ProfileCalls. profile_parameters()/profile_arguments()/profile_return() should probably test C1UpdateMethodData for consistency with other profile_* methods. So I'll add it. Does it really need to test C1ProfileCalls? When would we need to change C1ProfileCalls? Profiling of return/arguments/profiling can be turned on and off with TypeProfileLevel. Aren't C1UpdateMethodData and C1ProfileCalls obsolete options that we could remove now? Roland. > Thanks, > Vladimir > > On 10/18/13 9:26 AM, Roland Westrelin wrote: >> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >> >> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >> >> Roland. >> >> >> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >> >>> It is good. Thank you for this. >>> >>> Vladimir >>> >>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>> Here is a new webrev with more comments. >>>> >>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>> >>>> Roland. >>>> >>>> >>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>> >>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>> >>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Thanks for the comments. >>>>>>>> >>>>>>>>> I wish you added more comments to the code. >>>>>>>> >>>>>>>> Do you want me to send another webrev? >>>>>>> >>>>>>> I would wait review from Christian before updating webrev. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>> >>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>> >>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>> >>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>> >>>>>>> arg = x->profiled_arg_at(i); >>>>>> >>>>>> Yes. >>>>> >>>>> Okay. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>> >>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>> + if (args_cell > 0) { >>>>>>>> >>>>>>>> Ok. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>> >>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>> >>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>> invocation_counter: 5000 >>>>>>>>>> backedge_counter: 0 >>>>>>>>>> mdo size: 444 bytes >>>>>>>>>> >>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From igor.veresov at oracle.com Fri Oct 18 14:39:56 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 18 Oct 2013 14:39:56 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <8AC6E3D9-6445-477C-BC68-DFC2BE1FD06B@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <526184DF.80305@oracle.com> <8AC6E3D9-6445-477C-BC68-DFC2BE1FD06B@oracle.com> Message-ID: On Oct 18, 2013, at 2:25 PM, Roland Westrelin wrote: >> You replaced profile_calls() && MethodData::profile_return() with simple profile_return(). But profile_return() does not check profile_calls(). Why? >> > > In profile_calls() && MethodData::profile_return(), the main reason for the profile_calls() was for the env()->comp_level() == CompLevel_full_profile test. > > profile_calls() also tests C1UpdateMethodData && C1ProfileCalls. profile_parameters()/profile_arguments()/profile_return() should probably test C1UpdateMethodData for consistency with other profile_* methods. So I'll add it. Does it really need to test C1ProfileCalls? When would we need to change C1ProfileCalls? Profiling of return/arguments/profiling can be turned on and off with TypeProfileLevel. Aren't C1UpdateMethodData and C1ProfileCalls obsolete options that we could remove now? > These flags were mainly for debugging. We can remove them or may be move them to diagnostic. igor > Roland. > >> Thanks, >> Vladimir >> >> On 10/18/13 9:26 AM, Roland Westrelin wrote: >>> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >>> >>> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >>> >>> Roland. >>> >>> >>> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >>> >>>> It is good. Thank you for this. >>>> >>>> Vladimir >>>> >>>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>>> Here is a new webrev with more comments. >>>>> >>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>>> >>>>> Roland. >>>>> >>>>> >>>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>>> >>>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> Thanks for the comments. >>>>>>>>> >>>>>>>>>> I wish you added more comments to the code. >>>>>>>>> >>>>>>>>> Do you want me to send another webrev? >>>>>>>> >>>>>>>> I would wait review from Christian before updating webrev. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>>> >>>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>>> >>>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>>> >>>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>>> >>>>>>>> arg = x->profiled_arg_at(i); >>>>>>> >>>>>>> Yes. >>>>>> >>>>>> Okay. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>>> >>>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>>> + if (args_cell > 0) { >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>>> >>>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>>> invocation_counter: 5000 >>>>>>>>>>> backedge_counter: 0 >>>>>>>>>>> mdo size: 444 bytes >>>>>>>>>>> >>>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Oct 18 15:07:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Oct 2013 15:07:06 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <8AC6E3D9-6445-477C-BC68-DFC2BE1FD06B@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <526184DF.80305@oracle.com> <8AC6E3D9-6445-477C-BC68-DFC2BE1FD06B@oracle.com> Message-ID: <5261B10A.7000206@oracle.com> On 10/18/13 2:25 PM, Roland Westrelin wrote: >> You replaced profile_calls() && MethodData::profile_return() with simple profile_return(). But profile_return() does not check profile_calls(). Why? >> > > In profile_calls() && MethodData::profile_return(), the main reason for the profile_calls() was for the env()->comp_level() == CompLevel_full_profile test. > > profile_calls() also tests C1UpdateMethodData && C1ProfileCalls. profile_parameters()/profile_arguments()/profile_return() should probably test C1UpdateMethodData for consistency with other profile_* methods. So I'll add it. Does it really need to test C1ProfileCalls? When would we need to change C1ProfileCalls? Profiling of return/arguments/profiling can be turned on and off with TypeProfileLevel. Aren't C1UpdateMethodData and C1ProfileCalls obsolete options that we could remove now? I think Igor should know the answer. I think for now we need to check C1ProfileCalls. Unfortunately we should avoid removing product flags this late and they are product. File RFE to do it later. Vladimir > > Roland. > >> Thanks, >> Vladimir >> >> On 10/18/13 9:26 AM, Roland Westrelin wrote: >>> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >>> >>> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >>> >>> Roland. >>> >>> >>> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >>> >>>> It is good. Thank you for this. >>>> >>>> Vladimir >>>> >>>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>>> Here is a new webrev with more comments. >>>>> >>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>>> >>>>> Roland. >>>>> >>>>> >>>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>>> >>>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> Thanks for the comments. >>>>>>>>> >>>>>>>>>> I wish you added more comments to the code. >>>>>>>>> >>>>>>>>> Do you want me to send another webrev? >>>>>>>> >>>>>>>> I would wait review from Christian before updating webrev. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>>> >>>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>>> >>>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>>> >>>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>>> >>>>>>>> arg = x->profiled_arg_at(i); >>>>>>> >>>>>>> Yes. >>>>>> >>>>>> Okay. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>>> >>>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>>> + if (args_cell > 0) { >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>>> >>>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>>> invocation_counter: 5000 >>>>>>>>>>> backedge_counter: 0 >>>>>>>>>>> mdo size: 444 bytes >>>>>>>>>>> >>>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From vladimir.kozlov at oracle.com Fri Oct 18 16:04:54 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Oct 2013 16:04:54 -0700 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <52616ED8.9020703@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> Message-ID: <5261BE96.6020500@oracle.com> Roland, I looked on whole changes. Please, switch off UseTypeSpeculation by default as we discussed. I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": + // Return true if profiling provides a type for the argument nb to the I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. compile.cpp next comment is wrong since you keep using CastPP nodes: + // Remove the speculative part of types and clean up the graph from + // the extra CheckCastPP nodes whose only purpose is to carry + // them. Do that early so that optimizations are not disrupted by + // the extra CheckCastPP nodes. 'tmp' is not good name for a 'list': + Unique_Node_List tmp; Split next line: + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. library_call.cpp split next line: + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. Thanks, Vladimir On 10/18/13 10:24 AM, Vladimir Kozlov wrote: > Roland, > > > tap->const_oop() would be non NULL for a Constant only and xk is set > correctly if klass() == tap->klass() > > Lets leave NULL for now because in general meet(con, bot) = bot. It may > change code generation more then other changes and we don't want it now. > > > > > I've been trying to write simple tests to reproduce those failures > without much success. Any suggestion what simple java code I can write > to have something of ptr type AnyNull? > > AnyNull is ptr_dual for NotNull. Meets with it is checked in > Type::meet(). So it should work for tests only with NotNull. > > Vladimir > > On 10/18/13 9:19 AM, Roland Westrelin wrote: >> Hi Vladimir, >> >> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >> wrote: >> >>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>> Here is a new webrev for this: >>>> >>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>> >>>> I applied your suggestions below. >>>> I kept the "speculative" name. "Profiling" in the code indicates >>>> profiling data that we use right away so reusing profiling for this, >>>> I find confusing. >>> >>> Okay. >>> >>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>> problems that need investigation. I did extensive testing with the >>>> CastPPNodes. Can we keep them for now and reconsider that later? >>> >>> Yes, it is fine. >>> >>>> >>>> type.cpp has several generic type system fixes: >>>> >>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>> !klass_is_exact()) { >>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>> 3186 } else { >>> >>> Looks correct but, please, make sure it works for multi-dimensional >>> object arrays. And run full CTW tests and all jtregs. I am concern >>> that sometimes exact Object klass may be not really exact. >> >> Ok. >> >>> >>>> >>>> mimics what we do for instance klass with subclass/superclass when >>>> both subclass and superclass are exact >>>> >>>> 3315 if( this_klass->is_interface() && >>>> !(tinst_klass->is_interface() || >>>> 3316 tinst_klass == >>>> ciEnv::current()->Object_klass())) { >>>> >>>> is required because otherwise if tinst_klass is of an object class, >>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>> this->_ptr and tinst->_ptr which were not swapped. >>> >>> Seems reasonable. >>> >>>> >>>> I also had to make the cases: >>>> >>>> 3818 case AnyNull: >>>> 3819 case TopPTR: >>>> >>>> and >>>> >>>> 3847 case NotNull: >>>> 3848 case BotPTR: >>>> >>>> symmetrical which they are not currently. >>> >>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>> place (it was always false). >>> With your changes the code is still not symmetrical. I think in last >>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>> const_oop() to constructor. This is what we do when tap is Const and >>> 'this' is below. >> >> Wouldn't this be sufficient as a fix? >> >> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >> --- a/src/share/vm/opto/type.cpp >> +++ b/src/share/vm/opto/type.cpp >> @@ -3851,7 +3851,7 @@ >> xk = tap->_klass_is_exact; >> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >> (klass() == tap->klass()); // Only precise for >> identical arrays >> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >> instance_id, speculative); >> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >> lazy_klass, xk, off, instance_id, speculative); >> default: ShouldNotReachHere(); >> } >> } >> >> tap->const_oop() would be non NULL for a Constant only and xk is set >> correctly if klass() == tap->klass() >> >> I've been trying to write simple tests to reproduce those failures >> without much success. Any suggestion what simple java code I can write >> to have something of ptr type AnyNull? >> >> Thanks, >> Roland. >> >>> >>> I need to look on whole changes later. I will send additional comments. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Roland. >>>> >>>>> General notes: >>>>> >>>>> I think 'speculative' is not right word. We get these types from >>>>> profiling when we see only one type. And we use it only after >>>>> generated checks. 'profiled' will be more accurate and clear where >>>>> it comes from. Or other more appropriate name. >>>>> >>>>> You need to add jtreg tests to verify these changes for different >>>>> cases (especially merge points with different profile types). >>>>> >>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>> Phi nodes and further anyway. >>>>> >>>>> Small notes: >>>>> >>>>> c2_globals.hpp: >>>>> >>>>> TypeSpeculation --> UseTypeSpeculation >>>>> >>>>> drop_speculative* --> remove_speculative* >>>>> >>>>> Why change all TypeInstPtr::make() if you have default value set >>>>> for last parameters. >>>>> >>>>> In a lot of places you use: >>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>> >>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>> use in such cases. >>>>> >>>>> library_call.cpp: typo: >>>>> >>>>> ciKlass* src_k, *dest_k; >>>>> ^ >>>>> regards, >>>>> Vladimir >>>>> >>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>> Roland, >>>>>> >>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>> Regression could be also caused by different inlining >>>>>> (InlineSmallCode) >>>>>> because more uncommon traps are generated. >>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>> am also >>>>>> looking on your extra type profiling changes. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>> Always >>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>> more >>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>> it is. >>>>>>>> >>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>> It's >>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>> experiment >>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>> checks at the profiling points systematically and see what >>>>>>>> impact we >>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>> method >>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>> >>>>>>> This is the kind of results I get with nashorn: >>>>>>> deltablue: >>>>>>> current: 2345 >>>>>>> with type speculation and extra profiling: 2662 >>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>> >>>>>>> RayTrace: >>>>>>> current: 1978 >>>>>>> with type speculation and extra profiling: 2113 >>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>> >>>>>>> Richards: >>>>>>> current: 2222 >>>>>>> with type speculation and extra profiling: 2489 >>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>> >>>>>>> "extra profiling and systematic type checks" is: >>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>> method of the compilation >>>>>>> - type check on return from non inlined calls >>>>>>> >>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>> benchmarks: >>>>>>> >>>>>>> ============================================================================ >>>>>>> >>>>>>> >>>>>>> t >>>>>>> Benchmark Samples Mean Stdev >>>>>>> specjvm98 10 663.84 0.01 >>>>>>> javac 10 385.70 0.05 >>>>>>> db 10 444.51 0.01 >>>>>>> jess 10 699.05 0.00 >>>>>>> jack 10 603.98 0.01 >>>>>>> compress 10 534.99 0.01 >>>>>>> mtrt 10 1694.45 0.01 >>>>>>> mpegaudio 10 866.77 0.00 >>>>>>> ============================================================================ >>>>>>> >>>>>>> >>>>>>> t2 >>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>> Significant >>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>> 0.014 * >>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>> 0.013 * >>>>>>> db 10 444.87 0.01 0.08 >>>>>>> 0.875 * >>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>> 0.000 Yes >>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>> 0.425 * >>>>>>> compress 10 538.06 0.02 0.57 >>>>>>> 0.329 * >>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>> 0.181 * >>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>> 0.001 Yes >>>>>>> ============================================================================ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>> >> From morris.meyer at oracle.com Fri Oct 18 18:49:58 2013 From: morris.meyer at oracle.com (morris.meyer at oracle.com) Date: Sat, 19 Oct 2013 01:49:58 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8008242: VerifyOops is broken on SPARC Message-ID: <20131019015000.E712462563@hg.openjdk.java.net> Changeset: 252d541466ea Author: morris Date: 2013-10-18 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/252d541466ea 8008242: VerifyOops is broken on SPARC Summary: Fixed displacement issues in SPARC macroassembler and ensure that getClass intrinsic temporary result is T_METADATA Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp From roland.westrelin at oracle.com Sat Oct 19 02:52:50 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sat, 19 Oct 2013 11:52:50 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <5261BE96.6020500@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> Message-ID: <27E737CF-6CA9-49E9-ACB7-68BB9B53734F@oracle.com> Thanks for the review, Vladimir. On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: > Roland, > > I looked on whole changes. > > Please, switch off UseTypeSpeculation by default as we discussed. Ok. > > I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. I kind of assumed this would not happen or rarely because it would mean profiling is inaccurate. In GraphKit::record_profile_for_speculation() I could add the cast only if the current type is not exact and the speculative type is not exact. > > ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": > > + // Return true if profiling provides a type for the argument nb to the > > I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. > > It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. > > compile.cpp next comment is wrong since you keep using CastPP nodes: > > + // Remove the speculative part of types and clean up the graph from > + // the extra CheckCastPP nodes whose only purpose is to carry > + // them. Do that early so that optimizations are not disrupted by > + // the extra CheckCastPP nodes. > > 'tmp' is not good name for a 'list': > + Unique_Node_List tmp; > > Split next line: > > + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { > > > doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). > > graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. > > library_call.cpp split next line: > > + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); > > > parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. You're right that it doesn't always work as expected. I'll create new LoadKlass etc. Roland. > > Thanks, > Vladimir > > On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >> Roland, >> >> > tap->const_oop() would be non NULL for a Constant only and xk is set >> correctly if klass() == tap->klass() >> >> Lets leave NULL for now because in general meet(con, bot) = bot. It may >> change code generation more then other changes and we don't want it now. >> >> > >> > I've been trying to write simple tests to reproduce those failures >> without much success. Any suggestion what simple java code I can write >> to have something of ptr type AnyNull? >> >> AnyNull is ptr_dual for NotNull. Meets with it is checked in >> Type::meet(). So it should work for tests only with NotNull. >> >> Vladimir >> >> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>> wrote: >>> >>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>> Here is a new webrev for this: >>>>> >>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>> >>>>> I applied your suggestions below. >>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>> profiling data that we use right away so reusing profiling for this, >>>>> I find confusing. >>>> >>>> Okay. >>>> >>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>> problems that need investigation. I did extensive testing with the >>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>> >>>> Yes, it is fine. >>>> >>>>> >>>>> type.cpp has several generic type system fixes: >>>>> >>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>> !klass_is_exact()) { >>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>> 3186 } else { >>>> >>>> Looks correct but, please, make sure it works for multi-dimensional >>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>> that sometimes exact Object klass may be not really exact. >>> >>> Ok. >>> >>>> >>>>> >>>>> mimics what we do for instance klass with subclass/superclass when >>>>> both subclass and superclass are exact >>>>> >>>>> 3315 if( this_klass->is_interface() && >>>>> !(tinst_klass->is_interface() || >>>>> 3316 tinst_klass == >>>>> ciEnv::current()->Object_klass())) { >>>>> >>>>> is required because otherwise if tinst_klass is of an object class, >>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>> this->_ptr and tinst->_ptr which were not swapped. >>>> >>>> Seems reasonable. >>>> >>>>> >>>>> I also had to make the cases: >>>>> >>>>> 3818 case AnyNull: >>>>> 3819 case TopPTR: >>>>> >>>>> and >>>>> >>>>> 3847 case NotNull: >>>>> 3848 case BotPTR: >>>>> >>>>> symmetrical which they are not currently. >>>> >>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>> place (it was always false). >>>> With your changes the code is still not symmetrical. I think in last >>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>> const_oop() to constructor. This is what we do when tap is Const and >>>> 'this' is below. >>> >>> Wouldn't this be sufficient as a fix? >>> >>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>> --- a/src/share/vm/opto/type.cpp >>> +++ b/src/share/vm/opto/type.cpp >>> @@ -3851,7 +3851,7 @@ >>> xk = tap->_klass_is_exact; >>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>> (klass() == tap->klass()); // Only precise for >>> identical arrays >>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>> instance_id, speculative); >>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>> lazy_klass, xk, off, instance_id, speculative); >>> default: ShouldNotReachHere(); >>> } >>> } >>> >>> tap->const_oop() would be non NULL for a Constant only and xk is set >>> correctly if klass() == tap->klass() >>> >>> I've been trying to write simple tests to reproduce those failures >>> without much success. Any suggestion what simple java code I can write >>> to have something of ptr type AnyNull? >>> >>> Thanks, >>> Roland. >>> >>>> >>>> I need to look on whole changes later. I will send additional comments. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>>> General notes: >>>>>> >>>>>> I think 'speculative' is not right word. We get these types from >>>>>> profiling when we see only one type. And we use it only after >>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>> it comes from. Or other more appropriate name. >>>>>> >>>>>> You need to add jtreg tests to verify these changes for different >>>>>> cases (especially merge points with different profile types). >>>>>> >>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>> Phi nodes and further anyway. >>>>>> >>>>>> Small notes: >>>>>> >>>>>> c2_globals.hpp: >>>>>> >>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>> >>>>>> drop_speculative* --> remove_speculative* >>>>>> >>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>> for last parameters. >>>>>> >>>>>> In a lot of places you use: >>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>> >>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>> use in such cases. >>>>>> >>>>>> library_call.cpp: typo: >>>>>> >>>>>> ciKlass* src_k, *dest_k; >>>>>> ^ >>>>>> regards, >>>>>> Vladimir >>>>>> >>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>> Roland, >>>>>>> >>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>> Regression could be also caused by different inlining >>>>>>> (InlineSmallCode) >>>>>>> because more uncommon traps are generated. >>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>> am also >>>>>>> looking on your extra type profiling changes. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>> Always >>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>> more >>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>> it is. >>>>>>>>> >>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>> It's >>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>> experiment >>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>> impact we >>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>> method >>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>> >>>>>>>> This is the kind of results I get with nashorn: >>>>>>>> deltablue: >>>>>>>> current: 2345 >>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>> >>>>>>>> RayTrace: >>>>>>>> current: 1978 >>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>> >>>>>>>> Richards: >>>>>>>> current: 2222 >>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>> >>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>> method of the compilation >>>>>>>> - type check on return from non inlined calls >>>>>>>> >>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>> benchmarks: >>>>>>>> >>>>>>>> ============================================================================ >>>>>>>> >>>>>>>> >>>>>>>> t >>>>>>>> Benchmark Samples Mean Stdev >>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>> javac 10 385.70 0.05 >>>>>>>> db 10 444.51 0.01 >>>>>>>> jess 10 699.05 0.00 >>>>>>>> jack 10 603.98 0.01 >>>>>>>> compress 10 534.99 0.01 >>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>> ============================================================================ >>>>>>>> >>>>>>>> >>>>>>>> t2 >>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>> Significant >>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>> 0.014 * >>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>> 0.013 * >>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>> 0.875 * >>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>> 0.000 Yes >>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>> 0.425 * >>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>> 0.329 * >>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>> 0.181 * >>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>> 0.001 Yes >>>>>>>> ============================================================================ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>> >>> From roland.westrelin at oracle.com Sat Oct 19 03:14:07 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Sat, 19 Oct 2013 12:14:07 +0200 Subject: RFR(M): 8024069: replace_in_map() should operate on parent maps In-Reply-To: <781B3A40-F1DE-4318-9B84-A4F8FEFCB759@oracle.com> References: <525C79EB.8040008@oracle.com> <029D8A93-DE63-4DE8-AB01-CD68913F890C@oracle.com> <525DB90B.5010800@oracle.com> <525E4055.6090508@oracle.com> <758AA228-C0CD-40A9-960A-019A4F0DDAA6@oracle.com> <525E47A3.80103@oracle.com> <3B5A17FD-B2B3-465B-905E-AC655BFF8A95@oracle.com> <781B3A40-F1DE-4318-9B84-A4F8FEFCB759@oracle.com> Message-ID: <4FA1BD28-1552-49F7-AE17-6A6FF688B0A2@oracle.com> On Oct 18, 2013, at 7:31 PM, Christian Thalinger wrote: > src/share/vm/opto/c2_globals.hpp: > > + product(bool, ReplaceInParentMaps, false, \ > + "Propagate type improvements in callers of inlinee if possible") > > As I hope the limitation to JSR 292 goes away in the future I'd like to be this flag an experimental flag. Removing product flags is non-trivial. Will do that change. Thanks for the review. Roland. > > Otherwise this looks good. > > On Oct 16, 2013, at 9:04 AM, Roland Westrelin wrote: > >>>>> I know we are rushing currently so we don't have time to do proper generic fix. >>>>> Can you do it only for JSR292 methods where you see this pattern and preferably under flag? >>>>> The less we change common code now is better. >>>> >>>> What about I don't try to restrict it to JSR292 methods (I'm concerned that if I'm too restrictive we can't even turn it on to see if it helps) but put it under a flag that is off by default? And then when type speculation is on, turning type speculation on turns this on as well? >>> >>> Yes, it is fine under flag. >> >> Here is a new webrev for this. The change is under a flag. It's off by default. I removed the useless library intrinsic changes. I now use parser->caller()->map(). >> >> http://cr.openjdk.java.net/~roland/8024069/webrev.01/ >> >> Roland. >> >>> >>> Vladimir >>> >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/16/13 12:15 AM, Roland Westrelin wrote: >>>>>> >>>>>> On Oct 15, 2013, at 11:52 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> On 10/15/13 3:31 AM, Roland Westrelin wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Thanks for reviewing this. >>>>>>>> >>>>>>>>> Why in LateInlineCallGenerator::do_late_inline() you pass NULL?: >>>>>>>>> _inline_cg->generate(jvms, NULL); >>>>>>>> >>>>>>>> What else could be passed? Parsing of callers is over and we don't have any Parse object to pass. It's too late to do the replace in the callers. Or am I missing something? >>>>>>> >>>>>>> Yes, you are right. But you still have exit.jvms in which you can do replacement. >>>>>> >>>>>> Do you mean in the graph that is already built by the time the late inlining starts? That's true. I don't have a fix for that. >>>>>> >>>>>>> >>>>>>>> >>>>>>>>> In general, why we should care about intrinsics? There should be no inlining in them. And we will get speculative argument for instrinsics without recording parent parser in them. If we ignore intrinsics, we will need only cases when is_Parse() returns Parse object and we don't need parent_parser(). What I am missing? >>>>>>>> >>>>>>>> You're right. We don't need to care about intrinsics. >>>>>>>> >>>>>>>> So in GraphKit::replace_in_map(). this: >>>>>>>> >>>>>>>> if (parser == NULL) { >>>>>>>> parser = parent_parser(); >>>>>>>> } >>>>>>>> >>>>>>>> is not needed but we still need the parent_parser() method to iterate over parsers. parent_parser() only needs to be defined in Parse. >>>>>>>> >>>>>>>>> Also why not use parser->caller()->map()? jvms() comes from GraphKit and if there was not inlined call before map() will point to it (deep clone) instead of the parent's map. >>>>>>>> >>>>>>>> I don't see a reason not to use parser->caller()->map(), indeed. I'll do the change. This change I don't understand why it matters either. >>>>>>>> >>>>>>>>> >>>>>>>>> And I don't understand where 1) requirement comes from. >>>>>>>> >>>>>>>> If we have something like this: >>>>>>>> >>>>>>>> void m(A a) { >>>>>>>> if (some_condition) { >>>>>>>> B b = (B)a; >>>>>>>> } else { >>>>>>>> // some other stuff >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> then we'll replace a with (B)a in the map of the if branch but we cannot replace a with (B)a in caller of m because it's only true under some particular control. >>>>>>> >>>>>>> What about this case? We should be keeping the cast: >>>>>>> >>>>>>> void m(A a) { >>>>>>> if (some_condition) { >>>>>>> // some other stuff >>>>>>> } >>>>>>> B b = (B)a; >>>>>>> } >>>>>>> >>>>>> >>>>>> This case we could handle in my change by skipping over simple ifs. >>>>>> >>>>>>> I think you doing it in reverse order. You need to check that (B)a reaches exit point, it should not be matter what happened before. In your testcase there should be merge point after 'else' where the cast is invalidated (local will be dead or type will be widen). >>>>>> >>>>>> >>>>>> For a generic fix, I totally agree than I'm doing it in the reverse order. This is not a generic fix. It works on a pattern that I've seen several times with JSR292 where we have a chain of simple methods which ends with a method that does a type check and the type benefits outside the method but we can't take advantage of it. >>>>>> >>>>>> void m(A a) { >>>>>> B b = (B)b; >>>>>> // maybe some more stuff after >>>>>> } >>>>>> >>>>>> If the check above always succeeds then we do the replace_in_map() and whatever happens after won't change the fact that the type check has succeeded. To me it's a limited but valid transformation. >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> I am fine with moving is_uncommon_trap_*() mathods. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/12/13 2:31 PM, Roland Westrelin wrote: >>>>>>>>>> The improved type coming from a type check when it is done inside an inlined method may be lost once compilation exits from the inlinee because GraphKit::replace_in_map() doesn't update the maps of caller methods. >>>>>>>>>> >>>>>>>>>> When updating the parent maps, the replacement must be safe. This is done 1) by following the control edges to check that the control of the inlinee's map post dominate the control of the parent's maps 2) not doing any update in parent maps if the replace_in_map is called inside a PreserveJVMState block because PreserveJVMState doesn't do a deep copy of the caller states. The update itself must be done in the exits maps of the Parsers of the caller. I've added code to chain them together so that replace_in_map can iterate over the Parsers of callers. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~roland/8024069/webrev.00/ >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From roland.westrelin at oracle.com Sat Oct 19 06:05:00 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Sat, 19 Oct 2013 13:05:00 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8024069: replace_in_map() should operate on parent maps Message-ID: <20131019130527.3E0706256C@hg.openjdk.java.net> Changeset: 3213ba4d3dff Author: roland Date: 2013-10-19 12:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3213ba4d3dff 8024069: replace_in_map() should operate on parent maps Summary: type information gets lost because replace_in_map() doesn't update parent maps Reviewed-by: kvn, twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp From igor.ignatyev at oracle.com Sat Oct 19 19:34:03 2013 From: igor.ignatyev at oracle.com (igor.ignatyev at oracle.com) Date: Sun, 20 Oct 2013 02:34:03 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131020023409.E4FB36257F@hg.openjdk.java.net> Changeset: 19c5a042b0b3 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/19c5a042b0b3 8026414: [TESTBUG] Tests for Tiered/NonTiered levels Reviewed-by: twisti, iveresov + test/compiler/tiered/CompLevelsTest.java + test/compiler/tiered/NonTieredLevelsTest.java + test/compiler/tiered/TieredLevelsTest.java Changeset: 600c83f8e6a5 Author: iignatyev Date: 2013-10-19 21:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/600c83f8e6a5 8023318: compiler/whitebox tests timeout with enabled TieredCompilation Reviewed-by: kvn, twisti ! test/compiler/whitebox/CompilerWhiteBoxTest.java From igor.veresov at oracle.com Sun Oct 20 01:18:48 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Sun, 20 Oct 2013 08:18:48 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 40 new changesets Message-ID: <20131020082104.3441062589@hg.openjdk.java.net> Changeset: b4a4fdc1f464 Author: coleenp Date: 2013-10-09 21:45 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b4a4fdc1f464 8025185: MethodHandleInError and MethodTypeInError not handled in ConstantPool::compare_entry_to and copy_entry_to Summary: Add missing cases. Reviewed-by: sspitsyn, dcubed ! src/share/vm/oops/constantPool.cpp Changeset: e831448418ac Author: coleenp Date: 2013-10-09 22:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e831448418ac Merge Changeset: cd7ea1d79dac Author: sla Date: 2013-10-11 13:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cd7ea1d79dac 8026199: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Compilation failed Summary: Fixed a compilation failure due to changed method name Reviewed-by: sla, jbachorik Contributed-by: fredrik.arvidsson at oracle.com ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 539144972c1e Author: sla Date: 2013-10-11 14:08 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/539144972c1e 8024425: VM_HeapDumper doesn't put anonymous classes in the heap dump Summary: Switched from using SystemDictionary to using ClassLoaderDataGraph to get the anonymous classes included. Reviewed-by: sla, sspitsyn Contributed-by: fredrik.arvidsson at oracle.com ! src/share/vm/services/heapDumper.cpp Changeset: 301ece1880ad Author: sla Date: 2013-10-11 14:57 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/301ece1880ad Merge Changeset: 28ca974cc21a Author: coleenp Date: 2013-10-11 11:23 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/28ca974cc21a 8022592: assert at constantTag.cpp:57: ShouldNotReachHere() Summary: more missing cases for JVM_CONSTANT_Method{Handle,Type}InError Reviewed-by: hseigel, dcubed ! src/share/vm/oops/constantPool.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 26ae62bc26c4 Author: coleenp Date: 2013-10-11 15:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/26ae62bc26c4 Merge Changeset: 0db3ba3f6870 Author: hseigel Date: 2013-10-11 15:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0db3ba3f6870 8026041: JVM crashes with assert "assert(is_updated()) failed: must not be clear" with -XX:+PrintGCApplicationConcurrentTime in -Xcomp mode Summary: Prior to printing the time interval in RuntimeService::record_safepoint_begin(), check first that VM initialization is complete. Reviewed-by: coleenp, dholmes, sla, ctornqvi Contributed-by: lois.foltan at oracle.com ! src/share/vm/services/runtimeService.cpp Changeset: df268195b0ea Author: hseigel Date: 2013-10-11 17:08 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/df268195b0ea Merge Changeset: 41459da469ae Author: ccheung Date: 2013-10-11 18:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/41459da469ae Merge Changeset: 83dbf427fedd Author: ccheung Date: 2013-10-11 22:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/83dbf427fedd Merge Changeset: 3e265ce4d2dd Author: hseigel Date: 2013-10-12 13:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3e265ce4d2dd 8025942: os::Bsd::available_memory() needs implementation Summary: Implement using the host_statistics64() api. Reviewed-by: dsamersoff, morris, dholmes, coleenp, hseigel, dcubed Contributed-by: gerard.ziemski at oracle.com ! src/os/bsd/vm/os_bsd.cpp Changeset: d37a0525c0fe Author: hseigel Date: 2013-10-12 15:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d37a0525c0fe 8024667: VM crashes with "assert(method() != NULL) failed: must have set method" Summary: Check if data is in shared spaces before deallocating it. Reviewed-by: coleenp, dcubed ! src/share/vm/memory/metadataFactory.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 2f8728d92483 Author: acorn Date: 2013-10-14 21:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2f8728d92483 8026299: invokespecial gets ICCE when it should get AME. Reviewed-by: ccheung, coleenp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp Changeset: f509b8f4699b Author: dcubed Date: 2013-10-15 08:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f509b8f4699b 7165611: implement Full Debug Symbols on MacOS X hotspot Summary: Add MacOS X FDS support to hotspot; add minimal MacOS X FDS import support to jdk; add MacOS X FDS support to install; add MacOS X FDS support to root. Reviewed-by: erikj, sla, dholmes, rdurbin, tbell, ihse ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/universal.gmk ! make/bsd/makefiles/vm.make ! make/defs.make Changeset: e8703d708e6e Author: ccheung Date: 2013-10-16 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e8703d708e6e Merge Changeset: 8f4bb1773fd9 Author: iveresov Date: 2013-10-17 10:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f4bb1773fd9 Merge ! src/share/vm/interpreter/linkResolver.cpp - test/compiler/8013496/Test8013496.sh Changeset: 7114c4597ae3 Author: acorn Date: 2013-10-17 23:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7114c4597ae3 8026365: NoClassDefinitionFound for anonymous class invokespecial. Reviewed-by: dcubed, kamg ! src/share/vm/classfile/verifier.cpp ! test/TEST.groups Changeset: 9c8289162268 Author: jwilhelm Date: 2013-10-11 16:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9c8289162268 8024776: Max/MinHeapFreeRatio descriptions should be more precise Summary: Descriptions for Max/MinHeapFreeRatio updated Reviewed-by: ehelin, jmasa ! src/share/vm/runtime/globals.hpp Changeset: 2382ff14d889 Author: jwilhelm Date: 2013-10-12 05:08 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2382ff14d889 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24f32d09a0d7 Author: jwilhelm Date: 2013-10-12 00:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/24f32d09a0d7 8023643: G1 assert failed when NewSize was specified greater than MaxNewSize Summary: Exit with an error if incompatible NewSize and MaxNeSize are set Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp Changeset: d6818f623792 Author: tschatzl Date: 2013-10-15 11:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d6818f623792 8026186: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Compilation failed Summary: After a method rename in JDK-8014905 the mentioned test did not compile any more. Fix the uses of the affected method. Reviewed-by: jwilhelm, mgerdin, jmasa ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: 027006a47a6d Author: sjohanss Date: 2013-10-14 14:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/027006a47a6d 8025661: Ill-formed -Xminf and -Xmaxf options values interpreted as 0 Summary: Using strtod() instead of atof() when parsing -Xminf and -Xmaxf. Reviewed-by: brutisso, pliden ! src/share/vm/runtime/arguments.cpp + test/gc/arguments/TestHeapFreeRatio.java Changeset: 82fcc0567fef Author: mgerdin Date: 2013-10-15 04:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/82fcc0567fef Merge Changeset: 6f1919cfd18c Author: pliden Date: 2013-10-15 11:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6f1919cfd18c 8023158: hotspot/test/gc/7168848/HumongousAlloc.java fails 14 full gcs, expect 0 full gcs Reviewed-by: brutisso, tschatzl ! test/TEST.groups - test/gc/7168848/HumongousAlloc.java + test/gc/g1/TestHumongousAllocInitialMark.java Changeset: bfd52054aeb8 Author: pliden Date: 2013-10-15 11:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bfd52054aeb8 8024632: Description of InitialSurvivorRatio flag in globals.hpp is incorrect Reviewed-by: brutisso, tschatzl, kmo, tamao ! src/share/vm/runtime/globals.hpp Changeset: 041c5da41ac4 Author: pliden Date: 2013-10-15 11:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/041c5da41ac4 8024634: gc/startup_warnings tests can fail due to unrelated warnings Reviewed-by: brutisso, jwilhelm, tamao ! test/gc/startup_warnings/TestCMS.java ! test/gc/startup_warnings/TestCMSNoIncrementalMode.java ! test/gc/startup_warnings/TestG1.java ! test/gc/startup_warnings/TestParNewCMS.java ! test/gc/startup_warnings/TestParallelGC.java ! test/gc/startup_warnings/TestParallelScavengeSerialOld.java ! test/gc/startup_warnings/TestSerialGC.java Changeset: f16726924734 Author: stefank Date: 2013-10-15 07:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f16726924734 Merge - test/gc/7168848/HumongousAlloc.java Changeset: bdfbb1fb19ca Author: stefank Date: 2013-10-15 14:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bdfbb1fb19ca 8026391: The Metachunk header wastes memory Reviewed-by: coleenp, jmasa ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeList.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ec2e26e26183 Author: stefank Date: 2013-10-15 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ec2e26e26183 8026392: Metachunks and Metablocks are using a too large alignment Reviewed-by: coleenp, jmasa ! src/share/vm/memory/metachunk.cpp Changeset: 9e5fadad7fdf Author: tschatzl Date: 2013-10-16 11:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9e5fadad7fdf 8025925: jmap fails with "field _length not found in type HeapRegionSeq" Summary: The change JDK-7163191 changed the data layout of a class that is referenced by the java code of the SA agent. This fix synchronizes the SA agent with that change. Reviewed-by: sla, mgerdin + agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 28df60a5badf Author: stefank Date: 2013-10-17 08:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/28df60a5badf 8026707: JDK-8026391 broke the optimized build target Reviewed-by: mgerdin, coleenp ! src/share/vm/memory/metachunk.hpp Changeset: 94c0343b1887 Author: stefank Date: 2013-10-17 08:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/94c0343b1887 8026715: Remove the MetaDataDeallocateALot develop flag Reviewed-by: coleenp, mgerdin ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/globals.hpp Changeset: bf9e50c573ad Author: jmasa Date: 2013-10-17 06:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf9e50c573ad 8025635: SoftReferences are not cleared before metaspace OOME are thrown Reviewed-by: jcoomes, tamao, tschatzl, stefank ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp Changeset: c51cd6af7e61 Author: jcoomes Date: 2013-10-18 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c51cd6af7e61 Merge ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: aeae561a6d0b Author: cl Date: 2013-10-17 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/aeae561a6d0b Added tag jdk8-b112 for changeset 0ed9a90f45e1 ! .hgtags Changeset: 23b8db5ea31d Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/23b8db5ea31d Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: e8cbdc701bfb Author: amurillo Date: 2013-10-18 21:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e8cbdc701bfb Added tag hs25-b55 for changeset 23b8db5ea31d ! .hgtags Changeset: d6d8aeb2c2d4 Author: amurillo Date: 2013-10-19 08:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d6d8aeb2c2d4 8026928: new hotspot build - hs25-b56 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e842cc2d2dfb Author: iveresov Date: 2013-10-19 22:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e842cc2d2dfb Merge From igor.ignatyev at oracle.com Sun Oct 20 04:04:12 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 20 Oct 2013 15:04:12 +0400 Subject: RFR(XXS) : 8026865 : [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Message-ID: <5263B8AC.8040500@oracle.com> Hi all, Please review patch: Problem: 'compiler/print/PrintInlining.java' use '-XX:+PrintInlining', but doesn't specify '-XX:+UnlockDiagnosticVMOptions', so it fails on product builds Fix: added '-XX:+UnlockDiagnosticVMOptions' webrev: http://cr.openjdk.java.net/~iignatyev/8026865/webrev.00/ jbs: https://bugs.openjdk.java.net/browse/JDK-8026865 testing: failing test -- Best regards, Igor Ignatyev From igor.veresov at oracle.com Sun Oct 20 04:19:09 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 20 Oct 2013 04:19:09 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <5261B10A.7000206@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <526184DF.80305@oracle.com> <8AC6E3D9-6445-477C-BC68-DFC2BE1FD06B@oracle.com> <5261B10A.7000206@oracle.com> Message-ID: On Oct 18, 2013, at 3:07 PM, Vladimir Kozlov wrote: > On 10/18/13 2:25 PM, Roland Westrelin wrote: >>> You replaced profile_calls() && MethodData::profile_return() with simple profile_return(). But profile_return() does not check profile_calls(). Why? >>> >> >> In profile_calls() && MethodData::profile_return(), the main reason for the profile_calls() was for the env()->comp_level() == CompLevel_full_profile test. >> >> profile_calls() also tests C1UpdateMethodData && C1ProfileCalls. profile_parameters()/profile_arguments()/profile_return() should probably test C1UpdateMethodData for consistency with other profile_* methods. So I'll add it. Does it really need to test C1ProfileCalls? When would we need to change C1ProfileCalls? Profiling of return/arguments/profiling can be turned on and off with TypeProfileLevel. Aren't C1UpdateMethodData and C1ProfileCalls obsolete options that we could remove now? > > I think Igor should know the answer. I think for now we need to check C1ProfileCalls. > Yes, checking C1UpdateMethodData is a good thing to do for consistency. I don't think it needs to check C1ProfileCalls - that's to guard the receiver profiling code generation (perhaps not the best choice of option name). The original intention behind these flags was to turn off the new parts of profiling that were being added in C1 independently to debug problems more easily. If we want to follow the pattern, then we would need to add more C1ProfileX options. Otherwise the current code + C1UpdateMethodData checking is fine. igor > Unfortunately we should avoid removing product flags this late and they are product. File RFE to do it later. > > Vladimir > >> >> Roland. >> >>> Thanks, >>> Vladimir >>> >>> On 10/18/13 9:26 AM, Roland Westrelin wrote: >>>> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >>>> >>>> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >>>> >>>> Roland. >>>> >>>> >>>> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >>>> >>>>> It is good. Thank you for this. >>>>> >>>>> Vladimir >>>>> >>>>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>>>> Here is a new webrev with more comments. >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>>>> >>>>>> Roland. >>>>>> >>>>>> >>>>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>>>> >>>>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>>>> >>>>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>>>> Hi Vladimir, >>>>>>>>>> >>>>>>>>>> Thanks for the comments. >>>>>>>>>> >>>>>>>>>>> I wish you added more comments to the code. >>>>>>>>>> >>>>>>>>>> Do you want me to send another webrev? >>>>>>>>> >>>>>>>>> I would wait review from Christian before updating webrev. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>>>> >>>>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>>>> >>>>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>>>> >>>>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>>>> >>>>>>>>> arg = x->profiled_arg_at(i); >>>>>>>> >>>>>>>> Yes. >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>>>> >>>>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>>>> + if (args_cell > 0) { >>>>>>>>>> >>>>>>>>>> Ok. >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>>>> >>>>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>>>> invocation_counter: 5000 >>>>>>>>>>>> backedge_counter: 0 >>>>>>>>>>>> mdo size: 444 bytes >>>>>>>>>>>> >>>>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>>>> >>>>>>>>>>>> Roland. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From christian.thalinger at oracle.com Sun Oct 20 20:17:47 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sun, 20 Oct 2013 20:17:47 -0700 Subject: RFR(XXS) : 8026865 : [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions In-Reply-To: <5263B8AC.8040500@oracle.com> References: <5263B8AC.8040500@oracle.com> Message-ID: <4F1A672F-007B-47D3-9422-3703790EEED5@oracle.com> Looks good. On Oct 20, 2013, at 4:04 AM, Igor Ignatyev wrote: > Hi all, > > Please review patch: > > Problem: > 'compiler/print/PrintInlining.java' use '-XX:+PrintInlining', but doesn't specify '-XX:+UnlockDiagnosticVMOptions', so it fails on product builds > > Fix: > added '-XX:+UnlockDiagnosticVMOptions' > > webrev: http://cr.openjdk.java.net/~iignatyev/8026865/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8026865 > testing: failing test > -- > Best regards, > Igor Ignatyev From igor.veresov at oracle.com Sun Oct 20 21:29:42 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 20 Oct 2013 21:29:42 -0700 Subject: RFR(XXS) : 8026865 : [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions In-Reply-To: <5263B8AC.8040500@oracle.com> References: <5263B8AC.8040500@oracle.com> Message-ID: <7FCDAA4D-C67E-44FC-8409-9AFBAAB0BA2F@oracle.com> Looks fine. igor On Oct 20, 2013, at 4:04 AM, Igor Ignatyev wrote: > Hi all, > > Please review patch: > > Problem: > 'compiler/print/PrintInlining.java' use '-XX:+PrintInlining', but doesn't specify '-XX:+UnlockDiagnosticVMOptions', so it fails on product builds > > Fix: > added '-XX:+UnlockDiagnosticVMOptions' > > webrev: http://cr.openjdk.java.net/~iignatyev/8026865/webrev.00/ > jbs: https://bugs.openjdk.java.net/browse/JDK-8026865 > testing: failing test > -- > Best regards, > Igor Ignatyev From albert.noll at oracle.com Mon Oct 21 02:54:03 2013 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 21 Oct 2013 11:54:03 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Message-ID: <5264F9BB.7040104@oracle.com> Hi, could I have reviews for this small patch? bug: https://bugs.openjdk.java.net/browse/JDK-8026949 webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ Problem: 8023014 introduced a wrong warning: Initialization of C1 thread failed (no space to run compilers) when the VM is started with -Xint Solution: Do not start compiler threads if VM is started with -Xint Testing: -Xint flag does not print out the false warning. Tested flag combinations: -XX:+TieredCompilation -Xint (-server / -client) -XX:-TieredCompilation -Xint (-server / -client) Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131021/7f03d8d5/attachment.html From igor.ignatyev at oracle.com Mon Oct 21 05:23:41 2013 From: igor.ignatyev at oracle.com (igor.ignatyev at oracle.com) Date: Mon, 21 Oct 2013 12:23:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Message-ID: <20131021122402.C4820625B5@hg.openjdk.java.net> Changeset: 52575a17a36c Author: iignatyev Date: 2013-10-21 09:21 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/52575a17a36c 8026865: [TESTBUG] 'compiler/print/PrintInlining.java' should specify -XX:+UnlockDiagnosticVMOptions Reviewed-by: twisti, iveresov ! test/compiler/print/PrintInlining.java From rickard.backman at oracle.com Mon Oct 21 06:39:33 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 21 Oct 2013 15:39:33 +0200 Subject: RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Message-ID: <20131021133933.GB13244@rbackman> Hi, can I have reviews for this small change? The problem is we are moving a Phi node that is both input and output to a MathExactNode. Unfortunately cr.openjdk.java.net is down at the moment. I'm pasting the diff below. diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp --- a/src/share/vm/opto/compile.cpp +++ b/src/share/vm/opto/compile.cpp @@ -3004,6 +3004,10 @@ if (result != NULL) { for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) { Node* out = result->fast_out(j); + // Phi nodes shouldn't be moved. They would only match below if they + // had the same control as the MathExactNode. The only time that + // would happen is if the Phi is also an input to the MathExact + if (!out->is_Phi()) { if (out->in(0) == NULL) { out->set_req(0, non_throwing); } else if (out->in(0) == ctrl) { @@ -3012,6 +3016,7 @@ } } } + } break; default: assert( !n->is_Call(), "" ); Thank you /R From niclas.adlertz at oracle.com Mon Oct 21 07:08:54 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Mon, 21 Oct 2013 16:08:54 +0200 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL Message-ID: <52653576.8020600@oracle.com> Hi all, Now that more nodes can be rematerialized due to fix JDK-8022783, a rematerialized node can have a spilled live range as input even when rematerializing input for phi nodes (in the Phi Node Splitting pass). Prior to the JDK-8013830 and JDK-8005956 fixes, the Reachblock pointer could be wrong (hence the warning in JDK-8013830). Now, we pass in the correct block-reaches, i.e. the reaches for the 'pred' block. Kind Regards, Niclas Adlertz JBS: https://bugs.openjdk.java.net/browse/JDK-8026939 WEBREV: cr.openjdk.net is down so I'm pasting the diff here: diff -r 52575a17a36c src/share/vm/opto/reg_split.cpp --- a/src/share/vm/opto/reg_split.cpp Mon Oct 21 09:21:41 2013 +0400 +++ b/src/share/vm/opto/reg_split.cpp Mon Oct 21 15:34:42 2013 +0200 @@ -365,7 +365,6 @@ } if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { - assert(Reachblock != NULL, "Reachblock must be non-NULL"); Node *rdef = Reachblock[lrg2reach[lidx]]; if (rdef) { spill->set_req(i, rdef); @@ -476,7 +475,6 @@ uint bidx, pidx, slidx, insidx, inpidx, twoidx; uint non_phi = 1, spill_cnt = 0; - Node **Reachblock; Node *n1, *n2, *n3; Node_List *defs,*phis; bool *UPblock; @@ -559,7 +557,7 @@ b = _cfg.get_block(bidx); // Reaches & UP arrays for this block - Reachblock = Reaches[b->_pre_order]; + Node** Reachblock = Reaches[b->_pre_order]; UPblock = UP[b->_pre_order]; // Reset counter of start of non-Phi nodes in block non_phi = 1; @@ -1315,6 +1313,7 @@ pidx = pred->_pre_order; // Grab reaching def Node *def = Reaches[pidx][slidx]; + Node** Reachblock = Reaches[pidx]; assert( def, "must have reaching def" ); // If input up/down sense and reg-pressure DISagree if (def->rematerialize()) { @@ -1327,8 +1326,7 @@ _lrg_map.find(pred->get_node(insert - 1)) >= lrgs_before_phi_split) { insert--; } - // since the def cannot contain any live range input, we can pass in NULL as Reachlock parameter - def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, NULL, false); + def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, Reachblock, false); if (!def) { return 0; // Bail out } From roland.westrelin at oracle.com Mon Oct 21 09:19:16 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 Oct 2013 18:19:16 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <526184DF.80305@oracle.com> <8AC6E3D9-6445-477C-BC68-DFC2BE1FD06B@oracle.com> <5261B10A.7000206@oracle.com> Message-ID: <0AEB8D70-BF39-4791-9E41-E94D80F44EDA@oracle.com> > Yes, checking C1UpdateMethodData is a good thing to do for consistency. I don't think it needs to check C1ProfileCalls - that's to guard the receiver profiling code generation (perhaps not the best choice of option name). The original intention behind these flags was to turn off the new parts of profiling that were being added in C1 independently to debug problems more easily. If we want to follow the pattern, then we would need to add more C1ProfileX options. Otherwise the current code + C1UpdateMethodData checking is fine. Thanks Igor. I added C1UpdateMethodData and left C1ProfileCalls out. TypeProfileLevel makes it possible to turn profiling on and off. I think it's good enough for debugging. Roland. From roland.westrelin at oracle.com Mon Oct 21 12:34:27 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 Oct 2013 21:34:27 +0200 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <5CC33BCB-733F-4822-8F01-E4102626766A@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <5CC33BCB-733F-4822-8F01-E4102626766A@oracle.com> Message-ID: <86D191A6-1A6A-48A6-B9AF-B3C3531A47AA@oracle.com> Here is new webrev: http://cr.openjdk.java.net/~roland/8026251/webrev.04/ See inlined: On Oct 18, 2013, at 7:23 PM, Christian Thalinger wrote: > Since InterpreterMacroAssembler::profile_parameters_type is basically them exact same code (except movl/neql vs. movq/negq and rdi vs. r14) can we create new files: > > src/cpu/x86/vm/interp_masm_x86.{cpp,hpp} > > and put the method there? I did a quick experiment locally and there is no problem. We should stop duplicating code. I moved all the new profiling code to the new files. > > src/share/vm/oops/methodData.hpp: > > + // Offset with the MDO for the area dedicated to > + // parameters. -1 if no parameter profiling. > + int _parameters_type_data_di; > > What's "di"? Please rename. > > src/share/vm/runtime/globals.hpp: > > + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ > > Typo "js292". Maybe use "=" instead of "->". > > Are we printing the flag comments somewhere? If yes, then printing this will look very odd: -XX:+PrintFlagsWithComments does. I improved the formatting so that when printed it doesn't look too bad. Roland. > > ! "=XYZ, with Z, Type profiling of arguments at call" \ > ! " Y, Type profiling of return value at call" \ > ! " X, Type profiling of parameters to methods" \ > + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ > > Since it will be one string without new lines or spaces. Same with this one: > > + product(intx, TypeProfileParmsLimit, 2, \ > + "max number of incoming parameters to consider for type profiling"\ > + "-1 for all") \ > > Otherwise this looks good. > > On Oct 18, 2013, at 9:26 AM, Roland Westrelin wrote: > >> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >> >> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >> >> Roland. >> >> >> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >> >>> It is good. Thank you for this. >>> >>> Vladimir >>> >>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>> Here is a new webrev with more comments. >>>> >>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>> >>>> Roland. >>>> >>>> >>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>> >>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>> >>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>> >>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> Thanks for the comments. >>>>>>>> >>>>>>>>> I wish you added more comments to the code. >>>>>>>> >>>>>>>> Do you want me to send another webrev? >>>>>>> >>>>>>> I would wait review from Christian before updating webrev. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>> >>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>> >>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>> >>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>> >>>>>>> arg = x->profiled_arg_at(i); >>>>>> >>>>>> Yes. >>>>> >>>>> Okay. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>> >>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>> + if (args_cell > 0) { >>>>>>>> >>>>>>>> Ok. >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>> >>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>> >>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>> invocation_counter: 5000 >>>>>>>>>> backedge_counter: 0 >>>>>>>>>> mdo size: 444 bytes >>>>>>>>>> >>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From roland.westrelin at oracle.com Mon Oct 21 13:10:27 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 21 Oct 2013 22:10:27 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <5261BE96.6020500@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> Message-ID: <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> Here is a new webrev that should address all comments: http://cr.openjdk.java.net/~roland/8024070/webrev.02/ Roland. On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: > Roland, > > I looked on whole changes. > > Please, switch off UseTypeSpeculation by default as we discussed. > > I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. > > ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": > > + // Return true if profiling provides a type for the argument nb to the > > I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. > > It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. > > compile.cpp next comment is wrong since you keep using CastPP nodes: > > + // Remove the speculative part of types and clean up the graph from > + // the extra CheckCastPP nodes whose only purpose is to carry > + // them. Do that early so that optimizations are not disrupted by > + // the extra CheckCastPP nodes. > > 'tmp' is not good name for a 'list': > + Unique_Node_List tmp; > > Split next line: > > + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { > > > doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). > > graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. > > library_call.cpp split next line: > > + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); > > > parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. > > Thanks, > Vladimir > > On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >> Roland, >> >> > tap->const_oop() would be non NULL for a Constant only and xk is set >> correctly if klass() == tap->klass() >> >> Lets leave NULL for now because in general meet(con, bot) = bot. It may >> change code generation more then other changes and we don't want it now. >> >> > >> > I've been trying to write simple tests to reproduce those failures >> without much success. Any suggestion what simple java code I can write >> to have something of ptr type AnyNull? >> >> AnyNull is ptr_dual for NotNull. Meets with it is checked in >> Type::meet(). So it should work for tests only with NotNull. >> >> Vladimir >> >> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>> Hi Vladimir, >>> >>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>> wrote: >>> >>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>> Here is a new webrev for this: >>>>> >>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>> >>>>> I applied your suggestions below. >>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>> profiling data that we use right away so reusing profiling for this, >>>>> I find confusing. >>>> >>>> Okay. >>>> >>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>> problems that need investigation. I did extensive testing with the >>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>> >>>> Yes, it is fine. >>>> >>>>> >>>>> type.cpp has several generic type system fixes: >>>>> >>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>> !klass_is_exact()) { >>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>> 3186 } else { >>>> >>>> Looks correct but, please, make sure it works for multi-dimensional >>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>> that sometimes exact Object klass may be not really exact. >>> >>> Ok. >>> >>>> >>>>> >>>>> mimics what we do for instance klass with subclass/superclass when >>>>> both subclass and superclass are exact >>>>> >>>>> 3315 if( this_klass->is_interface() && >>>>> !(tinst_klass->is_interface() || >>>>> 3316 tinst_klass == >>>>> ciEnv::current()->Object_klass())) { >>>>> >>>>> is required because otherwise if tinst_klass is of an object class, >>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>> this->_ptr and tinst->_ptr which were not swapped. >>>> >>>> Seems reasonable. >>>> >>>>> >>>>> I also had to make the cases: >>>>> >>>>> 3818 case AnyNull: >>>>> 3819 case TopPTR: >>>>> >>>>> and >>>>> >>>>> 3847 case NotNull: >>>>> 3848 case BotPTR: >>>>> >>>>> symmetrical which they are not currently. >>>> >>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>> place (it was always false). >>>> With your changes the code is still not symmetrical. I think in last >>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>> const_oop() to constructor. This is what we do when tap is Const and >>>> 'this' is below. >>> >>> Wouldn't this be sufficient as a fix? >>> >>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>> --- a/src/share/vm/opto/type.cpp >>> +++ b/src/share/vm/opto/type.cpp >>> @@ -3851,7 +3851,7 @@ >>> xk = tap->_klass_is_exact; >>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>> (klass() == tap->klass()); // Only precise for >>> identical arrays >>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>> instance_id, speculative); >>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>> lazy_klass, xk, off, instance_id, speculative); >>> default: ShouldNotReachHere(); >>> } >>> } >>> >>> tap->const_oop() would be non NULL for a Constant only and xk is set >>> correctly if klass() == tap->klass() >>> >>> I've been trying to write simple tests to reproduce those failures >>> without much success. Any suggestion what simple java code I can write >>> to have something of ptr type AnyNull? >>> >>> Thanks, >>> Roland. >>> >>>> >>>> I need to look on whole changes later. I will send additional comments. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Roland. >>>>> >>>>>> General notes: >>>>>> >>>>>> I think 'speculative' is not right word. We get these types from >>>>>> profiling when we see only one type. And we use it only after >>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>> it comes from. Or other more appropriate name. >>>>>> >>>>>> You need to add jtreg tests to verify these changes for different >>>>>> cases (especially merge points with different profile types). >>>>>> >>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>> Phi nodes and further anyway. >>>>>> >>>>>> Small notes: >>>>>> >>>>>> c2_globals.hpp: >>>>>> >>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>> >>>>>> drop_speculative* --> remove_speculative* >>>>>> >>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>> for last parameters. >>>>>> >>>>>> In a lot of places you use: >>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>> >>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>> use in such cases. >>>>>> >>>>>> library_call.cpp: typo: >>>>>> >>>>>> ciKlass* src_k, *dest_k; >>>>>> ^ >>>>>> regards, >>>>>> Vladimir >>>>>> >>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>> Roland, >>>>>>> >>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>> Regression could be also caused by different inlining >>>>>>> (InlineSmallCode) >>>>>>> because more uncommon traps are generated. >>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>> am also >>>>>>> looking on your extra type profiling changes. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>> Always >>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>> more >>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>> it is. >>>>>>>>> >>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>> It's >>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>> experiment >>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>> impact we >>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>> method >>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>> >>>>>>>> This is the kind of results I get with nashorn: >>>>>>>> deltablue: >>>>>>>> current: 2345 >>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>> >>>>>>>> RayTrace: >>>>>>>> current: 1978 >>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>> >>>>>>>> Richards: >>>>>>>> current: 2222 >>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>> >>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>> method of the compilation >>>>>>>> - type check on return from non inlined calls >>>>>>>> >>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>> benchmarks: >>>>>>>> >>>>>>>> ============================================================================ >>>>>>>> >>>>>>>> >>>>>>>> t >>>>>>>> Benchmark Samples Mean Stdev >>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>> javac 10 385.70 0.05 >>>>>>>> db 10 444.51 0.01 >>>>>>>> jess 10 699.05 0.00 >>>>>>>> jack 10 603.98 0.01 >>>>>>>> compress 10 534.99 0.01 >>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>> ============================================================================ >>>>>>>> >>>>>>>> >>>>>>>> t2 >>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>> Significant >>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>> 0.014 * >>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>> 0.013 * >>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>> 0.875 * >>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>> 0.000 Yes >>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>> 0.425 * >>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>> 0.329 * >>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>> 0.181 * >>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>> 0.001 Yes >>>>>>>> ============================================================================ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Roland. >>>>>>>> >>>>> >>> From igor.veresov at oracle.com Mon Oct 21 16:24:17 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 21 Oct 2013 16:24:17 -0700 Subject: RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here In-Reply-To: <20131021133933.GB13244@rbackman> References: <20131021133933.GB13244@rbackman> Message-ID: <1A884EF1-E1EC-4189-A756-B571A1897F7B@oracle.com> Would it be prudent to verify (via an assert) all these assumptions about the graph shape you list in the comments? igor On Oct 21, 2013, at 6:39 AM, Rickard B?ckman wrote: > Hi, > > can I have reviews for this small change? > The problem is we are moving a Phi node that is both input and output to > a MathExactNode. > > Unfortunately cr.openjdk.java.net is down at the moment. I'm pasting the > diff below. > > diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp > +++ b/src/share/vm/opto/compile.cpp > @@ -3004,6 +3004,10 @@ > if (result != NULL) { > for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) { > Node* out = result->fast_out(j); > + // Phi nodes shouldn't be moved. They would only match below if they > + // had the same control as the MathExactNode. The only time that > + // would happen is if the Phi is also an input to the MathExact > + if (!out->is_Phi()) { > if (out->in(0) == NULL) { > out->set_req(0, non_throwing); > } else if (out->in(0) == ctrl) { > @@ -3012,6 +3016,7 @@ > } > } > } > + } > break; > default: > assert( !n->is_Call(), "" ); > > > Thank you > /R From christian.thalinger at oracle.com Mon Oct 21 20:15:16 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Oct 2013 20:15:16 -0700 Subject: RFR(M): 8026251: New type profiling points: parameters to methods In-Reply-To: <86D191A6-1A6A-48A6-B9AF-B3C3531A47AA@oracle.com> References: <365AD588-49BD-443D-AFEC-4B1CCD997B88@oracle.com> <525C2BA5.7010100@oracle.com> <14F32DA1-5F4C-4E9C-BD2F-74EFEBC07802@oracle.com> <525C59B9.9050705@oracle.com> <14116E05-4B50-448B-AC38-1F7A8C9034BE@oracle.com> <525DACB8.9070400@oracle.com> <454E9901-EEA2-4C76-9D9F-FD8098B78ABD@oracle.com> <52609163.3070800@oracle.com> <3C97CC3C-0596-427F-A707-402E208C0D15@oracle.com> <5CC33BCB-733F-4822-8F01-E4102626766A@oracle.com> <86D191A6-1A6A-48A6-B9AF-B3C3531A47AA@oracle.com> Message-ID: <23B99612-88F1-477F-BE2C-2EBC6DD5302D@oracle.com> On Oct 21, 2013, at 12:34 PM, Roland Westrelin wrote: > > Here is new webrev: > > http://cr.openjdk.java.net/~roland/8026251/webrev.04/ > > See inlined: > > On Oct 18, 2013, at 7:23 PM, Christian Thalinger wrote: > >> Since InterpreterMacroAssembler::profile_parameters_type is basically them exact same code (except movl/neql vs. movq/negq and rdi vs. r14) can we create new files: >> >> src/cpu/x86/vm/interp_masm_x86.{cpp,hpp} >> >> and put the method there? I did a quick experiment locally and there is no problem. We should stop duplicating code. > > I moved all the new profiling code to the new files. Nice! Thanks for doing this. > >> >> src/share/vm/oops/methodData.hpp: >> >> + // Offset with the MDO for the area dedicated to >> + // parameters. -1 if no parameter profiling. >> + int _parameters_type_data_di; >> >> What's "di"? Please rename. >> >> src/share/vm/runtime/globals.hpp: >> >> + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ >> >> Typo "js292". Maybe use "=" instead of "->". >> >> Are we printing the flag comments somewhere? If yes, then printing this will look very odd: > > -XX:+PrintFlagsWithComments does. I improved the formatting so that when printed it doesn't look too bad. + product(intx, TypeProfileParmsLimit, 2, \ + "max number of incoming parameters to consider for type profiling, "\ + "-1 for all") \ + \ Could you align the "\" at the end of the lines? No need for a new webrev. Otherwise this looks good. > > Roland. > >> >> ! "=XYZ, with Z, Type profiling of arguments at call" \ >> ! " Y, Type profiling of return value at call" \ >> ! " X, Type profiling of parameters to methods" \ >> + "X, Y and Z in 0->off ; 1->js292 only; 2->all methods") \ >> >> Since it will be one string without new lines or spaces. Same with this one: >> >> + product(intx, TypeProfileParmsLimit, 2, \ >> + "max number of incoming parameters to consider for type profiling"\ >> + "-1 for all") \ >> >> Otherwise this looks good. >> >> On Oct 18, 2013, at 9:26 AM, Roland Westrelin wrote: >> >>> Here is a new webrev with a small change. I added profile_parameters()/profile_arguments()/profile_return() methods to Compilation and GraphBuilder similarly to what is done for other profiling (profile_calls() etc.) and used them instead of calling directly MethodData::profile_parameters(). Code for profiling parameters on method entry in c1_LIRGenerator.cpp could end up trying to do the profiling even for compilations that didn't have profiling enabled because it wouldn't check compilation level. >>> >>> http://cr.openjdk.java.net/~roland/8026251/webrev.03/ >>> >>> Roland. >>> >>> >>> On Oct 18, 2013, at 3:39 AM, Vladimir Kozlov wrote: >>> >>>> It is good. Thank you for this. >>>> >>>> Vladimir >>>> >>>> On 10/17/13 11:44 AM, Roland Westrelin wrote: >>>>> Here is a new webrev with more comments. >>>>> >>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.02/ >>>>> >>>>> Roland. >>>>> >>>>> >>>>> On Oct 15, 2013, at 10:59 PM, Vladimir Kozlov wrote: >>>>> >>>>>> On 10/14/13 2:19 PM, Roland Westrelin wrote: >>>>>>> >>>>>>> On Oct 14, 2013, at 10:53 PM, Vladimir Kozlov wrote: >>>>>>> >>>>>>>> On 10/14/13 12:57 PM, Roland Westrelin wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> Thanks for the comments. >>>>>>>>> >>>>>>>>>> I wish you added more comments to the code. >>>>>>>>> >>>>>>>>> Do you want me to send another webrev? >>>>>>>> >>>>>>>> I would wait review from Christian before updating webrev. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Assembler. mdp points to array_len cell so your TypeStackSlotEntries access is off by 1. >>>>>>>>>> >>>>>>>>>> c1_GraphBuilder.cpp Why you need changes in args_list_for_profiling()? Why profiling parameter affects number of profiled arguments? >>>>>>>>> >>>>>>>>> To profile parameters on entry to inlined methods. The receiver is profiled as an incoming parameter so even if TypeProfileArgsLimit == TypeProfileParmsLimit, the number of arguments required for profiling is not necessarily the same for the arguments at a call and the parameters at the same call. >>>>>>>> >>>>>>>> Is next the code in profile_parameters_at_call() where Values* generated by args_list_for_profiling() are used?: >>>>>>>> >>>>>>>> arg = x->profiled_arg_at(i); >>>>>>> >>>>>>> Yes. >>>>>> >>>>>> Okay. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> >>>>>>>>>> methodData.cpp Rename args_cell to params_cell: >>>>>>>>>> >>>>>>>>>> + int args_cell = ParametersTypeData::compute_cell_count(method()); >>>>>>>>>> + if (args_cell > 0) { >>>>>>>>> >>>>>>>>> Ok. >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/14/13 4:59 AM, Roland Westrelin wrote: >>>>>>>>>>> The last of the series of new type profiling points. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~roland/8026251/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The output of PrintMethodData is: >>>>>>>>>>> >>>>>>>>>>> TestProfiling.m1(Ljava/lang/Object;JLjava/lang/Object;LTestProfiling$C;I)Ljava/lang/Object; >>>>>>>>>>> interpreter_invocation_count: 5000 >>>>>>>>>>> invocation_counter: 5000 >>>>>>>>>>> backedge_counter: 0 >>>>>>>>>>> mdo size: 444 bytes >>>>>>>>>>> >>>>>>>>>>> parameter types 0: stack(0) 'TestProfiling' >>>>>>>>>>> 1: stack(1) 'TestProfiling$A' >>>>>>>>>>> >>>>>>>>>>> Roland. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From christian.thalinger at oracle.com Mon Oct 21 20:27:01 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Oct 2013 20:27:01 -0700 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL In-Reply-To: <52653576.8020600@oracle.com> References: <52653576.8020600@oracle.com> Message-ID: <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> What testing did you do? On Oct 21, 2013, at 7:08 AM, Niclas Adlertz wrote: > Hi all, > > Now that more nodes can be rematerialized due to fix JDK-8022783, a rematerialized node can have a spilled live range as input even when rematerializing input for phi nodes (in the Phi Node Splitting pass). > Prior to the JDK-8013830 and JDK-8005956 fixes, the Reachblock pointer could be wrong (hence the warning in JDK-8013830). Now, we pass in the correct block-reaches, i.e. the reaches for the 'pred' block. > > Kind Regards, > Niclas Adlertz > > JBS: https://bugs.openjdk.java.net/browse/JDK-8026939 > WEBREV: cr.openjdk.net is down so I'm pasting the diff here: > > diff -r 52575a17a36c src/share/vm/opto/reg_split.cpp > --- a/src/share/vm/opto/reg_split.cpp Mon Oct 21 09:21:41 2013 +0400 > +++ b/src/share/vm/opto/reg_split.cpp Mon Oct 21 15:34:42 2013 +0200 > @@ -365,7 +365,6 @@ > } > if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { > - assert(Reachblock != NULL, "Reachblock must be non-NULL"); > Node *rdef = Reachblock[lrg2reach[lidx]]; > if (rdef) { > spill->set_req(i, rdef); > @@ -476,7 +475,6 @@ > uint bidx, pidx, slidx, insidx, inpidx, twoidx; > uint non_phi = 1, spill_cnt = 0; > - Node **Reachblock; > Node *n1, *n2, *n3; > Node_List *defs,*phis; > bool *UPblock; > @@ -559,7 +557,7 @@ > b = _cfg.get_block(bidx); > // Reaches & UP arrays for this block > - Reachblock = Reaches[b->_pre_order]; > + Node** Reachblock = Reaches[b->_pre_order]; > UPblock = UP[b->_pre_order]; > // Reset counter of start of non-Phi nodes in block > non_phi = 1; > @@ -1315,6 +1313,7 @@ > pidx = pred->_pre_order; > // Grab reaching def > Node *def = Reaches[pidx][slidx]; > + Node** Reachblock = Reaches[pidx]; > assert( def, "must have reaching def" ); > // If input up/down sense and reg-pressure DISagree > if (def->rematerialize()) { > @@ -1327,8 +1326,7 @@ > _lrg_map.find(pred->get_node(insert - 1)) >= lrgs_before_phi_split) { > insert--; > } > - // since the def cannot contain any live range input, we can pass in NULL as Reachlock parameter > - def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, NULL, false); > + def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, Reachblock, false); > if (!def) { > return 0; // Bail out > } From christian.thalinger at oracle.com Mon Oct 21 20:54:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 21 Oct 2013 20:54:34 -0700 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <5264F9BB.7040104@oracle.com> References: <5264F9BB.7040104@oracle.com> Message-ID: I think this is good. There might be a better place to put: + // No need for compiler threads if the VM is started with -Xint + if (Arguments::mode() == Arguments::_int) { + return 0; + } but I wouldn't know. On Oct 21, 2013, at 2:54 AM, Albert Noll wrote: > Hi, > > could I have reviews for this small patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8026949 > webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ > > Problem: 8023014 introduced a wrong warning: Initialization of C1 thread failed (no space to run compilers) when the VM is started > with -Xint > > Solution: Do not start compiler threads if VM is started with -Xint > > Testing: -Xint flag does not print out the false warning. Tested flag combinations: > -XX:+TieredCompilation -Xint (-server / -client) > -XX:-TieredCompilation -Xint (-server / -client) > > > Many thanks in advance, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131021/00af7dcf/attachment.html From igor.veresov at oracle.com Mon Oct 21 21:17:19 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 21 Oct 2013 21:17:19 -0700 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <5264F9BB.7040104@oracle.com> References: <5264F9BB.7040104@oracle.com> Message-ID: <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> If think you can just use the existing "UseCompiler" flag, that we set to false when -Xint is specified and just not call init_compiler_threads() if UseCompiler == false. igor On Oct 21, 2013, at 2:54 AM, Albert Noll wrote: > Hi, > > could I have reviews for this small patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8026949 > webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ > > Problem: 8023014 introduced a wrong warning: Initialization of C1 thread failed (no space to run compilers) when the VM is started > with -Xint > > Solution: Do not start compiler threads if VM is started with -Xint > > Testing: -Xint flag does not print out the false warning. Tested flag combinations: > -XX:+TieredCompilation -Xint (-server / -client) > -XX:-TieredCompilation -Xint (-server / -client) > > > Many thanks in advance, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131021/00824db9/attachment.html From igor.veresov at oracle.com Mon Oct 21 22:31:38 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 22 Oct 2013 05:31:38 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131022053204.19DED625EE@hg.openjdk.java.net> Changeset: 384c92148c68 Author: amurillo Date: 2013-10-21 14:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/384c92148c68 8023496: [jprt] build and test solaris 64-bits only Reviewed-by: tbell, jcoomes ! make/jprt.properties Changeset: 4748b3308cda Author: iveresov Date: 2013-10-21 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4748b3308cda Merge From rickard.backman at oracle.com Mon Oct 21 22:48:35 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 22 Oct 2013 07:48:35 +0200 Subject: RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here In-Reply-To: <1A884EF1-E1EC-4189-A756-B571A1897F7B@oracle.com> References: <20131021133933.GB13244@rbackman> <1A884EF1-E1EC-4189-A756-B571A1897F7B@oracle.com> Message-ID: <20131022054835.GC13244@rbackman> Igor, it would be easy to check that the control of a phi isn't NULL. If we have an out edge from the MathExact and the Phi and MathExact have the same control checking that it is also used as an input is a bit more work since there can be nodes in between. Should I add a graph traversal? Thanks /R On 10/21, Igor Veresov wrote: > Would it be prudent to verify (via an assert) all these assumptions about the graph shape you list in the comments? > > igor > > On Oct 21, 2013, at 6:39 AM, Rickard B?ckman wrote: > > > Hi, > > > > can I have reviews for this small change? > > The problem is we are moving a Phi node that is both input and output to > > a MathExactNode. > > > > Unfortunately cr.openjdk.java.net is down at the moment. I'm pasting the > > diff below. > > > > diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp > > --- a/src/share/vm/opto/compile.cpp > > +++ b/src/share/vm/opto/compile.cpp > > @@ -3004,6 +3004,10 @@ > > if (result != NULL) { > > for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) { > > Node* out = result->fast_out(j); > > + // Phi nodes shouldn't be moved. They would only match below if they > > + // had the same control as the MathExactNode. The only time that > > + // would happen is if the Phi is also an input to the MathExact > > + if (!out->is_Phi()) { > > if (out->in(0) == NULL) { > > out->set_req(0, non_throwing); > > } else if (out->in(0) == ctrl) { > > @@ -3012,6 +3016,7 @@ > > } > > } > > } > > + } > > break; > > default: > > assert( !n->is_Call(), "" ); > > > > > > Thank you > > /R > /R From albert.noll at oracle.com Mon Oct 21 23:15:59 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 22 Oct 2013 08:15:59 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> References: <5264F9BB.7040104@oracle.com> <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> Message-ID: <5266181F.1070408@oracle.com> Christian, Igor, thanks for the reviews. There seems to be an ambiguity between -Xint and -XX:+UseCompiler. Whether we use a compiler or not, depends on the order in which the arguments are given. I am not exactly sure why we have the -XX:(+/-)UseCompiler flag at all, also as a product flag. The reason why I added the checks when we determine the number of compiler threads is that we do not generate the compiler objects (they are not needed). Also, the number of compiler threads is set correctly. The solution proposed by Igor is simpler. If the above issues do not matter, I would also opt for the simple solution. Best, Albert On 22.10.2013 06:17, Igor Veresov wrote: > If think you can just use the existing "UseCompiler" flag, that we set > to false when -Xint is specified and just not call > init_compiler_threads() if UseCompiler == false. > > igor > > On Oct 21, 2013, at 2:54 AM, Albert Noll > wrote: > >> Hi, >> >> could I have reviews for this small patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >> >> >> Problem: 8023014 introduced a wrong warning: Initialization of C1 >> thread failed (no space to run compilers) when the VM is started >> with -Xint >> >> Solution: Do not start compiler threads if VM is started with -Xint >> >> Testing: -Xint flag does not print out the false warning. Tested flag >> combinations: >> -XX:+TieredCompilation -Xint (-server / -client) >> -XX:-TieredCompilation -Xint (-server / -client) >> >> >> Many thanks in advance, >> Albert >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/6ade0aa5/attachment-0001.html From igor.veresov at oracle.com Mon Oct 21 23:41:20 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 21 Oct 2013 23:41:20 -0700 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <5266181F.1070408@oracle.com> References: <5264F9BB.7040104@oracle.com> <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> <5266181F.1070408@oracle.com> Message-ID: Another trivial fix option is to just bail out of CompileBroker::compilation_init() is UseCompiler is false. To avoid initializing the compiler objects and all.. igor On Oct 21, 2013, at 11:15 PM, Albert Noll wrote: > Christian, Igor, thanks for the reviews. > > There seems to be an ambiguity between -Xint and -XX:+UseCompiler. Whether we use a compiler or > not, depends on the order in which the arguments are given. I am not exactly sure why we have > the -XX:(+/-)UseCompiler flag at all, also as a product flag. > > The reason why I added the checks when we determine the number of compiler threads is that we > do not generate the compiler objects (they are not needed). Also, the number of compiler threads > is set correctly. > > The solution proposed by Igor is simpler. If the above issues do not matter, I would also opt for the > simple solution. > > Best, > Albert > > > On 22.10.2013 06:17, Igor Veresov wrote: >> If think you can just use the existing "UseCompiler" flag, that we set to false when -Xint is specified and just not call init_compiler_threads() if UseCompiler == false. >> >> igor >> >> On Oct 21, 2013, at 2:54 AM, Albert Noll wrote: >> >>> Hi, >>> >>> could I have reviews for this small patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>> >>> Problem: 8023014 introduced a wrong warning: Initialization of C1 thread failed (no space to run compilers) when the VM is started >>> with -Xint >>> >>> Solution: Do not start compiler threads if VM is started with -Xint >>> >>> Testing: -Xint flag does not print out the false warning. Tested flag combinations: >>> -XX:+TieredCompilation -Xint (-server / -client) >>> -XX:-TieredCompilation -Xint (-server / -client) >>> >>> >>> Many thanks in advance, >>> Albert >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131021/f8d20069/attachment.html From igor.veresov at oracle.com Mon Oct 21 23:43:41 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 21 Oct 2013 23:43:41 -0700 Subject: RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here In-Reply-To: <20131022054835.GC13244@rbackman> References: <20131021133933.GB13244@rbackman> <1A884EF1-E1EC-4189-A756-B571A1897F7B@oracle.com> <20131022054835.GC13244@rbackman> Message-ID: <5C19AE99-F391-4EE5-8DC6-BAA6BBB48539@oracle.com> Thanks for the explanation. No, I think it'll be too complicated. Looks good. igor On Oct 21, 2013, at 10:48 PM, Rickard B?ckman wrote: > Igor, > > it would be easy to check that the control of a phi isn't NULL. > If we have an out edge from the MathExact and the Phi and MathExact have the same control checking that it is also used as an input is a bit more work since there can be nodes in between. > Should I add a graph traversal? > > Thanks > /R > > > On 10/21, Igor Veresov wrote: >> Would it be prudent to verify (via an assert) all these assumptions about the graph shape you list in the comments? >> >> igor >> >> On Oct 21, 2013, at 6:39 AM, Rickard B?ckman wrote: >> >>> Hi, >>> >>> can I have reviews for this small change? >>> The problem is we are moving a Phi node that is both input and output to >>> a MathExactNode. >>> >>> Unfortunately cr.openjdk.java.net is down at the moment. I'm pasting the >>> diff below. >>> >>> diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp >>> --- a/src/share/vm/opto/compile.cpp >>> +++ b/src/share/vm/opto/compile.cpp >>> @@ -3004,6 +3004,10 @@ >>> if (result != NULL) { >>> for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) { >>> Node* out = result->fast_out(j); >>> + // Phi nodes shouldn't be moved. They would only match below if they >>> + // had the same control as the MathExactNode. The only time that >>> + // would happen is if the Phi is also an input to the MathExact >>> + if (!out->is_Phi()) { >>> if (out->in(0) == NULL) { >>> out->set_req(0, non_throwing); >>> } else if (out->in(0) == ctrl) { >>> @@ -3012,6 +3016,7 @@ >>> } >>> } >>> } >>> + } >>> break; >>> default: >>> assert( !n->is_Call(), "" ); >>> >>> >>> Thank you >>> /R >> > /R From roland.westrelin at oracle.com Tue Oct 22 00:37:52 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Oct 2013 09:37:52 +0200 Subject: RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here In-Reply-To: <20131021133933.GB13244@rbackman> References: <20131021133933.GB13244@rbackman> Message-ID: <1F798322-FD10-493E-927A-CDCEBFA8F28C@oracle.com> > diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp > --- a/src/share/vm/opto/compile.cpp > +++ b/src/share/vm/opto/compile.cpp > @@ -3004,6 +3004,10 @@ > if (result != NULL) { > for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) { > Node* out = result->fast_out(j); > + // Phi nodes shouldn't be moved. They would only match below if they > + // had the same control as the MathExactNode. The only time that > + // would happen is if the Phi is also an input to the MathExact > + if (!out->is_Phi()) { > if (out->in(0) == NULL) { > out->set_req(0, non_throwing); > } else if (out->in(0) == ctrl) { > @@ -3012,6 +3016,7 @@ > } > } > } > + } > break; > default: > assert( !n->is_Call(), "" ); That looks good to me. Roland. From rickard.backman at oracle.com Tue Oct 22 00:48:41 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 22 Oct 2013 09:48:41 +0200 Subject: RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here In-Reply-To: <1F798322-FD10-493E-927A-CDCEBFA8F28C@oracle.com> References: <20131021133933.GB13244@rbackman> <1F798322-FD10-493E-927A-CDCEBFA8F28C@oracle.com> Message-ID: <20131022074841.GD13244@rbackman> Roland, thanks for the review. On 10/22, Roland Westrelin wrote: > > diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp > > --- a/src/share/vm/opto/compile.cpp > > +++ b/src/share/vm/opto/compile.cpp > > @@ -3004,6 +3004,10 @@ > > if (result != NULL) { > > for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) { > > Node* out = result->fast_out(j); > > + // Phi nodes shouldn't be moved. They would only match below if they > > + // had the same control as the MathExactNode. The only time that > > + // would happen is if the Phi is also an input to the MathExact > > + if (!out->is_Phi()) { > > if (out->in(0) == NULL) { > > out->set_req(0, non_throwing); > > } else if (out->in(0) == ctrl) { > > @@ -3012,6 +3016,7 @@ > > } > > } > > } > > + } > > break; > > default: > > assert( !n->is_Call(), "" ); > > That looks good to me. > > Roland. /R From rickard.backman at oracle.com Tue Oct 22 00:48:59 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 22 Oct 2013 09:48:59 +0200 Subject: RFR(XS): 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here In-Reply-To: <5C19AE99-F391-4EE5-8DC6-BAA6BBB48539@oracle.com> References: <20131021133933.GB13244@rbackman> <1A884EF1-E1EC-4189-A756-B571A1897F7B@oracle.com> <20131022054835.GC13244@rbackman> <5C19AE99-F391-4EE5-8DC6-BAA6BBB48539@oracle.com> Message-ID: <20131022074859.GE13244@rbackman> Igor, thanks for the review! On 10/21, Igor Veresov wrote: > Thanks for the explanation. No, I think it'll be too complicated. Looks good. > > igor > > On Oct 21, 2013, at 10:48 PM, Rickard B?ckman wrote: > > > Igor, > > > > it would be easy to check that the control of a phi isn't NULL. > > If we have an out edge from the MathExact and the Phi and MathExact have the same control checking that it is also used as an input is a bit more work since there can be nodes in between. > > Should I add a graph traversal? > > > > Thanks > > /R > > > > > > On 10/21, Igor Veresov wrote: > >> Would it be prudent to verify (via an assert) all these assumptions about the graph shape you list in the comments? > >> > >> igor > >> > >> On Oct 21, 2013, at 6:39 AM, Rickard B?ckman wrote: > >> > >>> Hi, > >>> > >>> can I have reviews for this small change? > >>> The problem is we are moving a Phi node that is both input and output to > >>> a MathExactNode. > >>> > >>> Unfortunately cr.openjdk.java.net is down at the moment. I'm pasting the > >>> diff below. > >>> > >>> diff --git a/src/share/vm/opto/compile.cpp b/src/share/vm/opto/compile.cpp > >>> --- a/src/share/vm/opto/compile.cpp > >>> +++ b/src/share/vm/opto/compile.cpp > >>> @@ -3004,6 +3004,10 @@ > >>> if (result != NULL) { > >>> for (DUIterator_Fast jmax, j = result->fast_outs(jmax); j < jmax; j++) { > >>> Node* out = result->fast_out(j); > >>> + // Phi nodes shouldn't be moved. They would only match below if they > >>> + // had the same control as the MathExactNode. The only time that > >>> + // would happen is if the Phi is also an input to the MathExact > >>> + if (!out->is_Phi()) { > >>> if (out->in(0) == NULL) { > >>> out->set_req(0, non_throwing); > >>> } else if (out->in(0) == ctrl) { > >>> @@ -3012,6 +3016,7 @@ > >>> } > >>> } > >>> } > >>> + } > >>> break; > >>> default: > >>> assert( !n->is_Call(), "" ); > >>> > >>> > >>> Thank you > >>> /R > >> > > /R > /R From niclas.adlertz at oracle.com Tue Oct 22 02:35:23 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 22 Oct 2013 11:35:23 +0200 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL In-Reply-To: <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> References: <52653576.8020600@oracle.com> <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> Message-ID: <526646DB.5020206@oracle.com> CTW and JPRT doesn't trigger this (that's why it was pushed unnoticed). However, I have tested 'java/lang/Character/CheckScript.java' with this fix and it now works. (java/lang/Character/CheckScript.java was a failing test in nightlies) Kind Regards, Niclas Adlertz On 2013-10-22 05:27, Christian Thalinger wrote: > What testing did you do? > > On Oct 21, 2013, at 7:08 AM, Niclas Adlertz wrote: > >> Hi all, >> >> Now that more nodes can be rematerialized due to fix JDK-8022783, a rematerialized node can have a spilled live range as input even when rematerializing input for phi nodes (in the Phi Node Splitting pass). >> Prior to the JDK-8013830 and JDK-8005956 fixes, the Reachblock pointer could be wrong (hence the warning in JDK-8013830). Now, we pass in the correct block-reaches, i.e. the reaches for the 'pred' block. >> >> Kind Regards, >> Niclas Adlertz >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8026939 >> WEBREV: cr.openjdk.net is down so I'm pasting the diff here: >> >> diff -r 52575a17a36c src/share/vm/opto/reg_split.cpp >> --- a/src/share/vm/opto/reg_split.cpp Mon Oct 21 09:21:41 2013 +0400 >> +++ b/src/share/vm/opto/reg_split.cpp Mon Oct 21 15:34:42 2013 +0200 >> @@ -365,7 +365,6 @@ >> } >> if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { >> - assert(Reachblock != NULL, "Reachblock must be non-NULL"); >> Node *rdef = Reachblock[lrg2reach[lidx]]; >> if (rdef) { >> spill->set_req(i, rdef); >> @@ -476,7 +475,6 @@ >> uint bidx, pidx, slidx, insidx, inpidx, twoidx; >> uint non_phi = 1, spill_cnt = 0; >> - Node **Reachblock; >> Node *n1, *n2, *n3; >> Node_List *defs,*phis; >> bool *UPblock; >> @@ -559,7 +557,7 @@ >> b = _cfg.get_block(bidx); >> // Reaches & UP arrays for this block >> - Reachblock = Reaches[b->_pre_order]; >> + Node** Reachblock = Reaches[b->_pre_order]; >> UPblock = UP[b->_pre_order]; >> // Reset counter of start of non-Phi nodes in block >> non_phi = 1; >> @@ -1315,6 +1313,7 @@ >> pidx = pred->_pre_order; >> // Grab reaching def >> Node *def = Reaches[pidx][slidx]; >> + Node** Reachblock = Reaches[pidx]; >> assert( def, "must have reaching def" ); >> // If input up/down sense and reg-pressure DISagree >> if (def->rematerialize()) { >> @@ -1327,8 +1326,7 @@ >> _lrg_map.find(pred->get_node(insert - 1)) >= lrgs_before_phi_split) { >> insert--; >> } >> - // since the def cannot contain any live range input, we can pass in NULL as Reachlock parameter >> - def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, NULL, false); >> + def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, Reachblock, false); >> if (!def) { >> return 0; // Bail out >> } > From niclas.adlertz at oracle.com Tue Oct 22 02:55:09 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 22 Oct 2013 11:55:09 +0200 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL In-Reply-To: <526646DB.5020206@oracle.com> References: <52653576.8020600@oracle.com> <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> <526646DB.5020206@oracle.com> Message-ID: <52664B7D.9040302@oracle.com> Here is the webrev now that cr.openjdk.java.net is up. http://cr.openjdk.java.net/~adlertz/JDK-8026939/webrev00/webrev/ Kind Regards, Niclas Adlertz On 2013-10-22 11:35, Niclas Adlertz wrote: > CTW and JPRT doesn't trigger this (that's why it was pushed unnoticed). > However, I have tested 'java/lang/Character/CheckScript.java' with this fix and it now works. > > (java/lang/Character/CheckScript.java was a failing test in nightlies) > > Kind Regards, > Niclas Adlertz > > On 2013-10-22 05:27, Christian Thalinger wrote: >> What testing did you do? >> >> On Oct 21, 2013, at 7:08 AM, Niclas Adlertz wrote: >> >>> Hi all, >>> >>> Now that more nodes can be rematerialized due to fix JDK-8022783, a rematerialized node can have a spilled live range as input even when rematerializing input for phi nodes (in the Phi Node Splitting pass). >>> Prior to the JDK-8013830 and JDK-8005956 fixes, the Reachblock pointer could be wrong (hence the warning in JDK-8013830). Now, we pass in the correct block-reaches, i.e. the reaches for the 'pred' block. >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8026939 >>> WEBREV: cr.openjdk.net is down so I'm pasting the diff here: >>> >>> diff -r 52575a17a36c src/share/vm/opto/reg_split.cpp >>> --- a/src/share/vm/opto/reg_split.cpp Mon Oct 21 09:21:41 2013 +0400 >>> +++ b/src/share/vm/opto/reg_split.cpp Mon Oct 21 15:34:42 2013 +0200 >>> @@ -365,7 +365,6 @@ >>> } >>> if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { >>> - assert(Reachblock != NULL, "Reachblock must be non-NULL"); >>> Node *rdef = Reachblock[lrg2reach[lidx]]; >>> if (rdef) { >>> spill->set_req(i, rdef); >>> @@ -476,7 +475,6 @@ >>> uint bidx, pidx, slidx, insidx, inpidx, twoidx; >>> uint non_phi = 1, spill_cnt = 0; >>> - Node **Reachblock; >>> Node *n1, *n2, *n3; >>> Node_List *defs,*phis; >>> bool *UPblock; >>> @@ -559,7 +557,7 @@ >>> b = _cfg.get_block(bidx); >>> // Reaches & UP arrays for this block >>> - Reachblock = Reaches[b->_pre_order]; >>> + Node** Reachblock = Reaches[b->_pre_order]; >>> UPblock = UP[b->_pre_order]; >>> // Reset counter of start of non-Phi nodes in block >>> non_phi = 1; >>> @@ -1315,6 +1313,7 @@ >>> pidx = pred->_pre_order; >>> // Grab reaching def >>> Node *def = Reaches[pidx][slidx]; >>> + Node** Reachblock = Reaches[pidx]; >>> assert( def, "must have reaching def" ); >>> // If input up/down sense and reg-pressure DISagree >>> if (def->rematerialize()) { >>> @@ -1327,8 +1326,7 @@ >>> _lrg_map.find(pred->get_node(insert - 1)) >= lrgs_before_phi_split) { >>> insert--; >>> } >>> - // since the def cannot contain any live range input, we can pass in NULL as Reachlock parameter >>> - def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, NULL, false); >>> + def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, Reachblock, false); >>> if (!def) { >>> return 0; // Bail out >>> } >> > From roland.westrelin at oracle.com Tue Oct 22 04:27:56 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Oct 2013 13:27:56 +0200 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL In-Reply-To: <52664B7D.9040302@oracle.com> References: <52653576.8020600@oracle.com> <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> <526646DB.5020206@oracle.com> <52664B7D.9040302@oracle.com> Message-ID: <29B1CF83-C46D-4024-84B8-7F033E227650@oracle.com> > http://cr.openjdk.java.net/~adlertz/JDK-8026939/webrev00/webrev/ That looks good to me. Roland. From niclas.adlertz at oracle.com Tue Oct 22 04:30:54 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Tue, 22 Oct 2013 13:30:54 +0200 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL In-Reply-To: <29B1CF83-C46D-4024-84B8-7F033E227650@oracle.com> References: <52653576.8020600@oracle.com> <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> <526646DB.5020206@oracle.com> <52664B7D.9040302@oracle.com> <29B1CF83-C46D-4024-84B8-7F033E227650@oracle.com> Message-ID: <526661EE.3040706@oracle.com> Thanks Roland. Kind Regards, Niclas Adlertz On 2013-10-22 13:27, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~adlertz/JDK-8026939/webrev00/webrev/ > > That looks good to me. > > Roland. > From albert.noll at oracle.com Tue Oct 22 06:15:21 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 22 Oct 2013 15:15:21 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: References: <5264F9BB.7040104@oracle.com> <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> <5266181F.1070408@oracle.com> Message-ID: <52667A69.4000900@oracle.com> Thanks Igor. This is a good solution. Here is the webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ Best, Albert On 22.10.2013 08:41, Igor Veresov wrote: > Another trivial fix option is to just bail out > of CompileBroker::compilation_init() is UseCompiler is false. To avoid > initializing the compiler objects and all.. > > igor > > On Oct 21, 2013, at 11:15 PM, Albert Noll > wrote: > >> Christian, Igor, thanks for the reviews. >> >> There seems to be an ambiguity between -Xint and -XX:+UseCompiler. >> Whether we use a compiler or >> not, depends on the order in which the arguments are given. I am not >> exactly sure why we have >> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >> >> The reason why I added the checks when we determine the number of >> compiler threads is that we >> do not generate the compiler objects (they are not needed). Also, the >> number of compiler threads >> is set correctly. >> >> The solution proposed by Igor is simpler. If the above issues do not >> matter, I would also opt for the >> simple solution. >> >> Best, >> Albert >> >> >> On 22.10.2013 06:17, Igor Veresov wrote: >>> If think you can just use the existing "UseCompiler" flag, that we >>> set to false when -Xint is specified and just not call >>> init_compiler_threads() if UseCompiler == false. >>> >>> igor >>> >>> On Oct 21, 2013, at 2:54 AM, Albert Noll >> > wrote: >>> >>>> Hi, >>>> >>>> could I have reviews for this small patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>> >>>> >>>> Problem: 8023014 introduced a wrong warning: Initialization of C1 >>>> thread failed (no space to run compilers) when the VM is started >>>> with -Xint >>>> >>>> Solution: Do not start compiler threads if VM is started with -Xint >>>> >>>> Testing: -Xint flag does not print out the false warning. Tested >>>> flag combinations: >>>> -XX:+TieredCompilation -Xint (-server / -client) >>>> -XX:-TieredCompilation -Xint (-server / -client) >>>> >>>> >>>> Many thanks in advance, >>>> Albert >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/124ec54e/attachment.html From roland.westrelin at oracle.com Tue Oct 22 06:38:57 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Oct 2013 15:38:57 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> Message-ID: The UseTypeSpeculation in the webrev is diagnostic which doesn't make much sense. Shouldn't I make it product or maybe experimental? Roland. On Oct 21, 2013, at 10:10 PM, Roland Westrelin wrote: > Here is a new webrev that should address all comments: > > http://cr.openjdk.java.net/~roland/8024070/webrev.02/ > > Roland. > > > On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: > >> Roland, >> >> I looked on whole changes. >> >> Please, switch off UseTypeSpeculation by default as we discussed. >> >> I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. >> >> ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": >> >> + // Return true if profiling provides a type for the argument nb to the >> >> I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. >> >> It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. >> >> compile.cpp next comment is wrong since you keep using CastPP nodes: >> >> + // Remove the speculative part of types and clean up the graph from >> + // the extra CheckCastPP nodes whose only purpose is to carry >> + // them. Do that early so that optimizations are not disrupted by >> + // the extra CheckCastPP nodes. >> >> 'tmp' is not good name for a 'list': >> + Unique_Node_List tmp; >> >> Split next line: >> >> + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { >> >> >> doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). >> >> graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. >> >> library_call.cpp split next line: >> >> + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); >> >> >> parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. >> >> Thanks, >> Vladimir >> >> On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >>> Roland, >>> >>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>> correctly if klass() == tap->klass() >>> >>> Lets leave NULL for now because in general meet(con, bot) = bot. It may >>> change code generation more then other changes and we don't want it now. >>> >>>> >>>> I've been trying to write simple tests to reproduce those failures >>> without much success. Any suggestion what simple java code I can write >>> to have something of ptr type AnyNull? >>> >>> AnyNull is ptr_dual for NotNull. Meets with it is checked in >>> Type::meet(). So it should work for tests only with NotNull. >>> >>> Vladimir >>> >>> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>>> Here is a new webrev for this: >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>>> >>>>>> I applied your suggestions below. >>>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>>> profiling data that we use right away so reusing profiling for this, >>>>>> I find confusing. >>>>> >>>>> Okay. >>>>> >>>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>>> problems that need investigation. I did extensive testing with the >>>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>>> >>>>> Yes, it is fine. >>>>> >>>>>> >>>>>> type.cpp has several generic type system fixes: >>>>>> >>>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>>> !klass_is_exact()) { >>>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>>> 3186 } else { >>>>> >>>>> Looks correct but, please, make sure it works for multi-dimensional >>>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>>> that sometimes exact Object klass may be not really exact. >>>> >>>> Ok. >>>> >>>>> >>>>>> >>>>>> mimics what we do for instance klass with subclass/superclass when >>>>>> both subclass and superclass are exact >>>>>> >>>>>> 3315 if( this_klass->is_interface() && >>>>>> !(tinst_klass->is_interface() || >>>>>> 3316 tinst_klass == >>>>>> ciEnv::current()->Object_klass())) { >>>>>> >>>>>> is required because otherwise if tinst_klass is of an object class, >>>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>>> this->_ptr and tinst->_ptr which were not swapped. >>>>> >>>>> Seems reasonable. >>>>> >>>>>> >>>>>> I also had to make the cases: >>>>>> >>>>>> 3818 case AnyNull: >>>>>> 3819 case TopPTR: >>>>>> >>>>>> and >>>>>> >>>>>> 3847 case NotNull: >>>>>> 3848 case BotPTR: >>>>>> >>>>>> symmetrical which they are not currently. >>>>> >>>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>>> place (it was always false). >>>>> With your changes the code is still not symmetrical. I think in last >>>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>>> const_oop() to constructor. This is what we do when tap is Const and >>>>> 'this' is below. >>>> >>>> Wouldn't this be sufficient as a fix? >>>> >>>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>>> --- a/src/share/vm/opto/type.cpp >>>> +++ b/src/share/vm/opto/type.cpp >>>> @@ -3851,7 +3851,7 @@ >>>> xk = tap->_klass_is_exact; >>>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>>> (klass() == tap->klass()); // Only precise for >>>> identical arrays >>>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>>> instance_id, speculative); >>>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>>> lazy_klass, xk, off, instance_id, speculative); >>>> default: ShouldNotReachHere(); >>>> } >>>> } >>>> >>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>> correctly if klass() == tap->klass() >>>> >>>> I've been trying to write simple tests to reproduce those failures >>>> without much success. Any suggestion what simple java code I can write >>>> to have something of ptr type AnyNull? >>>> >>>> Thanks, >>>> Roland. >>>> >>>>> >>>>> I need to look on whole changes later. I will send additional comments. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>>> General notes: >>>>>>> >>>>>>> I think 'speculative' is not right word. We get these types from >>>>>>> profiling when we see only one type. And we use it only after >>>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>>> it comes from. Or other more appropriate name. >>>>>>> >>>>>>> You need to add jtreg tests to verify these changes for different >>>>>>> cases (especially merge points with different profile types). >>>>>>> >>>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>>> Phi nodes and further anyway. >>>>>>> >>>>>>> Small notes: >>>>>>> >>>>>>> c2_globals.hpp: >>>>>>> >>>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>>> >>>>>>> drop_speculative* --> remove_speculative* >>>>>>> >>>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>>> for last parameters. >>>>>>> >>>>>>> In a lot of places you use: >>>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>>> >>>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>>> use in such cases. >>>>>>> >>>>>>> library_call.cpp: typo: >>>>>>> >>>>>>> ciKlass* src_k, *dest_k; >>>>>>> ^ >>>>>>> regards, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>>> Roland, >>>>>>>> >>>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>>> Regression could be also caused by different inlining >>>>>>>> (InlineSmallCode) >>>>>>>> because more uncommon traps are generated. >>>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>>> am also >>>>>>>> looking on your extra type profiling changes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>>> Always >>>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>>> more >>>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>>> it is. >>>>>>>>>> >>>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>>> It's >>>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>>> experiment >>>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>>> impact we >>>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>>> method >>>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>>> >>>>>>>>> This is the kind of results I get with nashorn: >>>>>>>>> deltablue: >>>>>>>>> current: 2345 >>>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>>> >>>>>>>>> RayTrace: >>>>>>>>> current: 1978 >>>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>>> >>>>>>>>> Richards: >>>>>>>>> current: 2222 >>>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>>> >>>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>>> method of the compilation >>>>>>>>> - type check on return from non inlined calls >>>>>>>>> >>>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>>> benchmarks: >>>>>>>>> >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> t >>>>>>>>> Benchmark Samples Mean Stdev >>>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>>> javac 10 385.70 0.05 >>>>>>>>> db 10 444.51 0.01 >>>>>>>>> jess 10 699.05 0.00 >>>>>>>>> jack 10 603.98 0.01 >>>>>>>>> compress 10 534.99 0.01 >>>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> t2 >>>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>>> Significant >>>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>>> 0.014 * >>>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>>> 0.013 * >>>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>>> 0.875 * >>>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>>> 0.000 Yes >>>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>>> 0.425 * >>>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>>> 0.329 * >>>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>>> 0.181 * >>>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>>> 0.001 Yes >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>> >>>> > From rickard.backman at oracle.com Tue Oct 22 06:56:35 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 22 Oct 2013 15:56:35 +0200 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> Message-ID: <20131022135635.GF13244@rbackman> Christian, new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ (I missed x86_32.ad when generating it, but everything else should be there). I removed the timeouts, they were remains of another attempt at writing tests. Thanks On 10/18, Christian Thalinger wrote: > src/share/vm/opto/library_call.cpp: > > + Node* arg1 = argument(0); // type long > + // argument(1) == TOP > + Node* arg2 = argument(2); // type long > + // argument(4) == TOP > > The "argument(4)" comment it wrong; should be 3. > > + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); > > Remove the extra spaces. > > src/share/vm/opto/mathexactnode.hpp: > > + MathExactNode(Node* ctrl, Node* n1); > MathExactNode(Node* ctrl, Node* in1, Node* in2); > > Should "n1" be "in1"? Or maybe just "n". > > These have two copyright headers: > > test/compiler/intrinsics/mathexact/IncExactITest.java > test/compiler/intrinsics/mathexact/IncExactLTest.java > > It seems all of the tests have a wrong bug number: > > 26 * @bug 8024924 > > or > > 26 * @bug 8025657 > > test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: > > 28 * @compile MulExactIRepeatTest.java > > That one doesn't compile Verify.java. Please check all of the test files for these issue. > > In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? > > The question is do we really need individual test files for these? I don't object just mentioning it. > > On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: > > > Hi, can I get reviews for the following change: > > > > This change creates intrinsics for addExact(long, long), subtractExact, > > negateExact, incrementExact, decrementExact and multiplyExact. > > > > The intrinsics are only added on x86 and only 64-bit has the intrinsics > > for the long-versions. (32-bit only has int-versions). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > > Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > > > > Thanks > > /R > /R From rickard.backman at oracle.com Tue Oct 22 06:59:21 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 22 Oct 2013 15:59:21 +0200 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <526158D2.8080601@oracle.com> References: <20131018093454.GC17703@rbackman> <526158D2.8080601@oracle.com> Message-ID: <20131022135921.GG13244@rbackman> Vladimir, new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ (Forgot to add x86_32.ad to that one though). The reason I didn't implement mulexact(reg, mem) was that we didn't have imull and imulq for (reg, mem). I've added those now. I also noticed that we never generated *Exact(reg, mem) because of a problem in Matcher::find_shared. Since the *Exact nodes have two outputs all inputs of *Exact will be marked as shared. I decided to only push the *Exact-node for the Result unless only the FlagsProj is used. Thanks On 10/18, Vladimir Kozlov wrote: > Rickard, > > is_MathExactOpcode() could be replaced by adding the node to > DEFINE_CLASS_ID structure as you did with FlagsProj. is_MathExact() > will be true for all its subclasses. > > Put MathExactNode() constructors together. > > In library_call.cpp can you name Integer version of method with I: > inline_math_addExactI() to be symmetrical with Long version. And I > don't think you need separate methods for increment and decrement - > path flag to add and sub method. > > Why you did not implement mulexact(reg, mem) mach nodes? > > Otherwise it is good. > > Thanks, > Vladimir > > On 10/18/13 2:34 AM, Rickard B?ckman wrote: > >Hi, can I get reviews for the following change: > > > >This change creates intrinsics for addExact(long, long), subtractExact, > >negateExact, incrementExact, decrementExact and multiplyExact. > > > >The intrinsics are only added on x86 and only 64-bit has the intrinsics > >for the long-versions. (32-bit only has int-versions). > > > >Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > >Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > > > >Thanks > >/R > > /R From albert.noll at oracle.com Tue Oct 22 07:23:17 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 22 Oct 2013 16:23:17 +0200 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Message-ID: <52668A55.40605@oracle.com> Hi all, I worked on this bug for some time but so far I was not able to determine its root cause. However, I have found a work around that hides the problem. Since it is important for the embedded version of hotspot to work with small code cache sizes + nashorn, I would suggest to apply this workaround, and file another bug that investigates the problem (e.g., a P4) that we can defer. bug: https://bugs.openjdk.java.net/browse/JDK-8026407 webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ problem: If we do not create native wrapper for method handle intrinsics, we get segfaults in compiled code. Also, if -XX:VerifyAdapterCalls is enabled, we get: assert(false) failed: DEBUG MESSAGE: i2c adapter must return to an interpreter frame The bug seems to be specific to method handle intrinsics. I assume that we either call the wrong entry point to a compiled method, or there is a bug somewhere in the generated adapters. Method handle intrinsics are treated specifically in various parts of the code and I do not yet really understand everything. solution: As mentioned above, the solution is a workaround and does not solve the real problem. Nevertheless it improves stability of hotspot and the impact of the proposed changes are marginal. testing: Running nashorn with small code cache size (3m) on PPC and x86 There will be a separate mail for closed part changes. Many thanks in advance, Albert P.S.: If anyone has an idea of where the problem could be, please let me know! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/04c2e1a9/attachment.html From roland.westrelin at oracle.com Tue Oct 22 06:59:49 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Tue, 22 Oct 2013 13:59:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026251: New type profiling points: parameters to methods Message-ID: <20131022135952.73B3862617@hg.openjdk.java.net> Changeset: 5ccbab1c69f3 Author: roland Date: 2013-10-22 09:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5ccbab1c69f3 8026251: New type profiling points: parameters to methods Summary: x86 interpreter and c1 type profiling for parameters on method entries Reviewed-by: kvn, twisti ! src/cpu/x86/vm/bytecodeInterpreter_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp + src/cpu/x86/vm/interp_masm_x86.cpp + src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp From roland.westrelin at oracle.com Tue Oct 22 09:26:53 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Oct 2013 18:26:53 +0200 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <52668A55.40605@oracle.com> References: <52668A55.40605@oracle.com> Message-ID: <24E3D0D5-D29A-4245-88E1-D1B33EF8B1A2@oracle.com> > webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ That looks ok to me. Roland. From roland.westrelin at oracle.com Tue Oct 22 09:27:30 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Oct 2013 18:27:30 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <52667A69.4000900@oracle.com> References: <5264F9BB.7040104@oracle.com> <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> <5266181F.1070408@oracle.com> <52667A69.4000900@oracle.com> Message-ID: > http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ What kind of testing have you done? Roland. From rickard.backman at oracle.com Tue Oct 22 09:37:06 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 22 Oct 2013 16:37:06 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131022163723.D217C6262A@hg.openjdk.java.net> Changeset: 435c7b4577cd Author: rbackman Date: 2013-10-21 15:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/435c7b4577cd 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Reviewed-by: iveresov, roland ! src/share/vm/opto/compile.cpp Changeset: 36e17466dd39 Author: rbackman Date: 2013-10-22 14:02 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/36e17466dd39 Merge From igor.veresov at oracle.com Tue Oct 22 10:12:34 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Oct 2013 10:12:34 -0700 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <52667A69.4000900@oracle.com> References: <5264F9BB.7040104@oracle.com> <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> <5266181F.1070408@oracle.com> <52667A69.4000900@oracle.com> Message-ID: <47541191-2FC3-4CD6-AF6A-58C0ECC45F64@oracle.com> Looks good. igor On Oct 22, 2013, at 6:15 AM, Albert Noll wrote: > Thanks Igor. This is a good solution. > > Here is the webrev: > http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ > > Best, > Albert > > On 22.10.2013 08:41, Igor Veresov wrote: >> Another trivial fix option is to just bail out of CompileBroker::compilation_init() is UseCompiler is false. To avoid initializing the compiler objects and all.. >> >> igor >> >> On Oct 21, 2013, at 11:15 PM, Albert Noll wrote: >> >>> Christian, Igor, thanks for the reviews. >>> >>> There seems to be an ambiguity between -Xint and -XX:+UseCompiler. Whether we use a compiler or >>> not, depends on the order in which the arguments are given. I am not exactly sure why we have >>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>> >>> The reason why I added the checks when we determine the number of compiler threads is that we >>> do not generate the compiler objects (they are not needed). Also, the number of compiler threads >>> is set correctly. >>> >>> The solution proposed by Igor is simpler. If the above issues do not matter, I would also opt for the >>> simple solution. >>> >>> Best, >>> Albert >>> >>> >>> On 22.10.2013 06:17, Igor Veresov wrote: >>>> If think you can just use the existing "UseCompiler" flag, that we set to false when -Xint is specified and just not call init_compiler_threads() if UseCompiler == false. >>>> >>>> igor >>>> >>>> On Oct 21, 2013, at 2:54 AM, Albert Noll wrote: >>>> >>>>> Hi, >>>>> >>>>> could I have reviews for this small patch? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>> >>>>> Problem: 8023014 introduced a wrong warning: Initialization of C1 thread failed (no space to run compilers) when the VM is started >>>>> with -Xint >>>>> >>>>> Solution: Do not start compiler threads if VM is started with -Xint >>>>> >>>>> Testing: -Xint flag does not print out the false warning. Tested flag combinations: >>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>> >>>>> >>>>> Many thanks in advance, >>>>> Albert >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/1aaece70/attachment-0001.html From albert.noll at oracle.com Tue Oct 22 11:03:52 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 22 Oct 2013 20:03:52 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <47541191-2FC3-4CD6-AF6A-58C0ECC45F64@oracle.com> References: <5264F9BB.7040104@oracle.com> <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> <5266181F.1070408@oracle.com> <52667A69.4000900@oracle.com> <47541191-2FC3-4CD6-AF6A-58C0ECC45F64@oracle.com> Message-ID: <5266BE08.90609@oracle.com> Roland, Igor, thanks for looking at this. I tested the patch as follows: java -Xint -version .. make sure that output does not appear java -Xcomp -version make sure that compiler(s) are working Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and -Xcomp and -Xmixed) Seems to work fine. Best, Albert On 22.10.2013 19:12, Igor Veresov wrote: > Looks good. > > igor > > On Oct 22, 2013, at 6:15 AM, Albert Noll > wrote: > >> Thanks Igor. This is a good solution. >> >> Here is the webrev: >> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >> >> >> Best, >> Albert >> >> On 22.10.2013 08:41, Igor Veresov wrote: >>> Another trivial fix option is to just bail out >>> of CompileBroker::compilation_init() is UseCompiler is false. To >>> avoid initializing the compiler objects and all.. >>> >>> igor >>> >>> On Oct 21, 2013, at 11:15 PM, Albert Noll >> > wrote: >>> >>>> Christian, Igor, thanks for the reviews. >>>> >>>> There seems to be an ambiguity between -Xint and -XX:+UseCompiler. >>>> Whether we use a compiler or >>>> not, depends on the order in which the arguments are given. I am >>>> not exactly sure why we have >>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>> >>>> The reason why I added the checks when we determine the number of >>>> compiler threads is that we >>>> do not generate the compiler objects (they are not needed). Also, >>>> the number of compiler threads >>>> is set correctly. >>>> >>>> The solution proposed by Igor is simpler. If the above issues do >>>> not matter, I would also opt for the >>>> simple solution. >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>> If think you can just use the existing "UseCompiler" flag, that we >>>>> set to false when -Xint is specified and just not call >>>>> init_compiler_threads() if UseCompiler == false. >>>>> >>>>> igor >>>>> >>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>> > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> could I have reviews for this small patch? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>> >>>>>> >>>>>> Problem: 8023014 introduced a wrong warning: Initialization of C1 >>>>>> thread failed (no space to run compilers) when the VM is started >>>>>> with -Xint >>>>>> >>>>>> Solution: Do not start compiler threads if VM is started with -Xint >>>>>> >>>>>> Testing: -Xint flag does not print out the false warning. Tested >>>>>> flag combinations: >>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>> >>>>>> >>>>>> Many thanks in advance, >>>>>> Albert >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/2eac33ca/attachment.html From albert.noll at oracle.com Tue Oct 22 11:05:31 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 22 Oct 2013 20:05:31 +0200 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <24E3D0D5-D29A-4245-88E1-D1B33EF8B1A2@oracle.com> References: <52668A55.40605@oracle.com> <24E3D0D5-D29A-4245-88E1-D1B33EF8B1A2@oracle.com> Message-ID: <5266BE6B.2030901@oracle.com> Thank you, Roland. Best, Albert On 22.10.2013 18:26, Roland Westrelin wrote: >> webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ > That looks ok to me. > > Roland. From igor.veresov at oracle.com Tue Oct 22 11:17:40 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Oct 2013 11:17:40 -0700 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <52668A55.40605@oracle.com> References: <52668A55.40605@oracle.com> Message-ID: <19038A39-0BB7-4B47-97EB-BD016289A487@oracle.com> What if there's no space to create the wrapper? Do we crash? I guess the workaround is ok for now, but please file a new bug to investigate. igor On Oct 22, 2013, at 7:23 AM, Albert Noll wrote: > Hi all, > > I worked on this bug for some time but so far I was not able to determine its root cause. > However, I have found a work around that hides the problem. Since it is important > for the embedded version of hotspot to work with small code cache sizes + nashorn, > I would suggest to apply this workaround, and file another bug that investigates the problem > (e.g., a P4) that we can defer. > > bug: https://bugs.openjdk.java.net/browse/JDK-8026407 > webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ > > problem: If we do not create native wrapper for method handle intrinsics, we get > segfaults in compiled code. Also, if -XX:VerifyAdapterCalls is enabled, we > get: > > assert(false) failed: DEBUG MESSAGE: i2c adapter must return to an interpreter frame > > The bug seems to be specific to method handle intrinsics. I assume that we either call > the wrong entry point to a compiled method, or there is a bug somewhere in the generated > adapters. Method handle intrinsics are treated specifically in various parts of the code and > I do not yet really understand everything. > > solution: As mentioned above, the solution is a workaround and does not solve the real problem. > Nevertheless it improves stability of hotspot and the impact of the proposed changes are > marginal. > > testing: Running nashorn with small code cache size (3m) on PPC and x86 > > There will be a separate mail for closed part changes. > > Many thanks in advance, > Albert > > P.S.: If anyone has an idea of where the problem could be, please let me know! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/5c464282/attachment.html From roland.westrelin at oracle.com Tue Oct 22 11:18:22 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 22 Oct 2013 20:18:22 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <5266BE08.90609@oracle.com> References: <5264F9BB.7040104@oracle.com> <036ABA06-5E21-426F-B07E-F98D98195AC7@oracle.com> <5266181F.1070408@oracle.com> <52667A69.4000900@oracle.com> <47541191-2FC3-4CD6-AF6A-58C0ECC45F64@oracle.com> <5266BE08.90609@oracle.com> Message-ID: > I tested the patch as follows: > > java -Xint -version .. make sure that output does not appear > java -Xcomp -version make sure that compiler(s) are working > > Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and -Xcomp and -Xmixed) Ok. I think the change is ok. Roland. From igor.ignatyev at oracle.com Tue Oct 22 11:34:32 2013 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Tue, 22 Oct 2013 22:34:32 +0400 Subject: =?utf-8?B?UmU6IFJGUihTKTogODAyNjk0OTogLVhpbnQgZmxhZyBwcmludHMgd3Jvbmcgd2Fy?= =?utf-8?B?bmluZzogSW5pdGlhbGl6YXRpb24gb2YgQzEgdGhyZWFkIGZhaWxlZCAobm8gc3Bh?= =?utf-8?B?Y2UgdG8gcnVuIGNvbXBpbGVycyk=?= Message-ID: <201310221834.r9MIYXIh009147@userz7021.oracle.com> Albert, please add a jtreg test for this change. I think it is very easy: just start 'java -version' as a external process and check its output in 'Xint' and '-Xcomp' cases. If you don't think so, please file a RFE to add regression test and assign it to me. Thanks. - Igor ----- Reply message ----- From: "Albert Noll" To: "Igor Veresov" Cc: "hotspot-compiler-dev at openjdk.java.net" Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Date: Tue, Oct 22, 2013 22:03 Roland, Igor, thanks for looking at this. I tested the patch as follows: java -Xint -version .. make sure that output does not appear java -Xcomp -version make sure that compiler(s) are working Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and -Xcomp and -Xmixed) Seems to work fine. Best, Albert On 22.10.2013 19:12, Igor Veresov wrote: Looks good. igor On Oct 22, 2013, at 6:15 AM, Albert Noll wrote: Thanks Igor. This is a good solution. Here is the webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ Best, Albert On 22.10.2013 08:41, Igor Veresov wrote: Another trivial fix option is to just bail out of CompileBroker::compilation_init() is UseCompiler is false. To avoid initializing the compiler objects and all.. igor On Oct 21, 2013, at 11:15 PM, Albert Noll wrote: Christian, Igor, thanks for the reviews. There seems to be an ambiguity between -Xint and -XX:+UseCompiler. Whether we use a compiler or not, depends on the order in which the arguments are given. I am not exactly sure why we have the -XX:(+/-)UseCompiler flag at all, also as a product flag. The reason why I added the checks when we determine the number of compiler threads is that we do not generate the compiler objects (they are not needed). Also, the number of compiler threads is set correctly. The solution proposed by Igor is simpler. If the above issues do not matter, I would also opt for the simple solution. Best, Albert On 22.10.2013 06:17, Igor Veresov wrote: If think you can just use the existing "UseCompiler" flag, that we set to false when -Xint is specified and just not call init_compiler_threads() if UseCompiler == false. igor On Oct 21, 2013, at 2:54 AM, Albert Noll wrote: Hi, could I have reviews for this small patch? bug: https://bugs.openjdk.java.net/browse/JDK-8026949 webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ Problem: 8023014 introduced a wrong warning: Initialization of C1 thread failed (no space to run compilers) when the VM is started with -Xint Solution: Do not start compiler threads if VM is started with -Xint Testing: -Xint flag does not print out the false warning. Tested flag combinations: -XX:+TieredCompilation -Xint (-server / -client) -XX:-TieredCompilation -Xint (-server / -client) Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/5618c839/attachment.html From albert.noll at oracle.com Tue Oct 22 11:47:28 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 22 Oct 2013 20:47:28 +0200 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <19038A39-0BB7-4B47-97EB-BD016289A487@oracle.com> References: <52668A55.40605@oracle.com> <19038A39-0BB7-4B47-97EB-BD016289A487@oracle.com> Message-ID: <5266C840.7020801@oracle.com> Hi Igor, thanks for looking at the patch. You are right. If there is not enough free space in the code cache to generate the wrapper, we might crash again. However, it did not show up during the tests. I'll file a new bug (P4?) to further investigate. Best, Albert On 22.10.2013 20:17, Igor Veresov wrote: > What if there's no space to create the wrapper? Do we crash? > I guess the workaround is ok for now, but please file a new bug to > investigate. > > igor > > On Oct 22, 2013, at 7:23 AM, Albert Noll > wrote: > >> Hi all, >> >> I worked on this bug for some time but so far I was not able to >> determine its root cause. >> However, I have found a work around that hides the problem. Since it >> is important >> for the embedded version of hotspot to work with small code cache >> sizes + nashorn, >> I would suggest to apply this workaround, and file another bug that >> investigates the problem >> (e.g., a P4) that we can defer. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8026407 >> webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ >> >> >> problem: If we do not create native wrapper for method handle >> intrinsics, we get >> segfaults in compiled code. Also, if >> -XX:VerifyAdapterCalls is enabled, we >> get: >> >> assert(false) failed: DEBUG MESSAGE: i2c adapter must >> return to an interpreter frame >> >> The bug seems to be specific to method handle >> intrinsics. I assume that we either call >> the wrong entry point to a compiled method, or there >> is a bug somewhere in the generated >> adapters. Method handle intrinsics are treated >> specifically in various parts of the code and >> I do not yet really understand everything. >> >> solution: As mentioned above, the solution is a workaround and does >> not solve the real problem. >> Nevertheless it improves stability of hotspot and the >> impact of the proposed changes are >> marginal. >> >> testing: Running nashorn with small code cache size (3m) on PPC and x86 >> >> There will be a separate mail for closed part changes. >> >> Many thanks in advance, >> Albert >> >> P.S.: If anyone has an idea of where the problem could be, please let >> me know! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/6e66d5f2/attachment-0001.html From albert.noll at oracle.com Tue Oct 22 12:18:36 2013 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 22 Oct 2013 21:18:36 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Message-ID: <5266CF8C.70305@oracle.com> Hi, sure, here is the patch including the test: http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ Best, Albert On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: > Albert, please add a jtreg test for this change. I think it is very > easy: just start 'java -version' as a external process and check its > output in 'Xint' and '-Xcomp' cases. If you don't think so, please > file a RFE to add regression test and assign it to me. > > Thanks. > - Igor > > ----- Reply message ----- > From: "Albert Noll" > To: "Igor Veresov" > Cc: "hotspot-compiler-dev at openjdk.java.net" > > Subject: RFR(S): 8026949: -Xint flag prints wrong warning: > Initialization of C1 thread failed (no space to run compilers) > Date: Tue, Oct 22, 2013 22:03 > > Roland, Igor, thanks for looking at this. > > I tested the patch as follows: > > java -Xint -version .. make sure that output does not appear > java -Xcomp -version make sure that compiler(s) are working > > Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and > -Xcomp and -Xmixed) > > Seems to work fine. > > Best, > Albert > > On 22.10.2013 19:12, Igor Veresov wrote: >> Looks good. >> >> igor >> >> On Oct 22, 2013, at 6:15 AM, Albert Noll > > wrote: >> >>> Thanks Igor. This is a good solution. >>> >>> Here is the webrev: >>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>> >>> >>> Best, >>> Albert >>> >>> On 22.10.2013 08:41, Igor Veresov wrote: >>>> Another trivial fix option is to just bail out >>>> of CompileBroker::compilation_init() is UseCompiler is false. To >>>> avoid initializing the compiler objects and all.. >>>> >>>> igor >>>> >>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>> > wrote: >>>> >>>>> Christian, Igor, thanks for the reviews. >>>>> >>>>> There seems to be an ambiguity between -Xint and -XX:+UseCompiler. >>>>> Whether we use a compiler or >>>>> not, depends on the order in which the arguments are given. I am >>>>> not exactly sure why we have >>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>> >>>>> The reason why I added the checks when we determine the number of >>>>> compiler threads is that we >>>>> do not generate the compiler objects (they are not needed). Also, >>>>> the number of compiler threads >>>>> is set correctly. >>>>> >>>>> The solution proposed by Igor is simpler. If the above issues do >>>>> not matter, I would also opt for the >>>>> simple solution. >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>> If think you can just use the existing "UseCompiler" flag, that >>>>>> we set to false when -Xint is specified and just not call >>>>>> init_compiler_threads() if UseCompiler == false. >>>>>> >>>>>> igor >>>>>> >>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> could I have reviews for this small patch? >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of >>>>>>> C1 thread failed (no space to run compilers) when the VM is started >>>>>>> with -Xint >>>>>>> >>>>>>> Solution: Do not start compiler threads if VM is started with -Xint >>>>>>> >>>>>>> Testing: -Xint flag does not print out the false warning. Tested >>>>>>> flag combinations: >>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>> >>>>>>> >>>>>>> Many thanks in advance, >>>>>>> Albert >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/6d2c41a0/attachment.html From chris.plummer at oracle.com Tue Oct 22 14:12:16 2013 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 22 Oct 2013 14:12:16 -0700 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <5266C840.7020801@oracle.com> References: <52668A55.40605@oracle.com> <19038A39-0BB7-4B47-97EB-BD016289A487@oracle.com> <5266C840.7020801@oracle.com> Message-ID: <5266EA30.4040107@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/d6b1027a/attachment.html From christian.thalinger at oracle.com Tue Oct 22 15:26:51 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 15:26:51 -0700 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <20131022135635.GF13244@rbackman> References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> <20131022135635.GF13244@rbackman> Message-ID: Looks good. Not sure about the FlagsProj push change; Vladimir should look at this as well. On Oct 22, 2013, at 6:56 AM, Rickard B?ckman wrote: > Christian, > > new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ > The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ > (I missed x86_32.ad when generating it, but everything else should be > there). > > I removed the timeouts, they were remains of another attempt at writing > tests. > > Thanks > > On 10/18, Christian Thalinger wrote: >> src/share/vm/opto/library_call.cpp: >> >> + Node* arg1 = argument(0); // type long >> + // argument(1) == TOP >> + Node* arg2 = argument(2); // type long >> + // argument(4) == TOP >> >> The "argument(4)" comment it wrong; should be 3. >> >> + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); >> >> Remove the extra spaces. >> >> src/share/vm/opto/mathexactnode.hpp: >> >> + MathExactNode(Node* ctrl, Node* n1); >> MathExactNode(Node* ctrl, Node* in1, Node* in2); >> >> Should "n1" be "in1"? Or maybe just "n". >> >> These have two copyright headers: >> >> test/compiler/intrinsics/mathexact/IncExactITest.java >> test/compiler/intrinsics/mathexact/IncExactLTest.java >> >> It seems all of the tests have a wrong bug number: >> >> 26 * @bug 8024924 >> >> or >> >> 26 * @bug 8025657 >> >> test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: >> >> 28 * @compile MulExactIRepeatTest.java >> >> That one doesn't compile Verify.java. Please check all of the test files for these issue. >> >> In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? >> >> The question is do we really need individual test files for these? I don't object just mentioning it. >> >> On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: >> >>> Hi, can I get reviews for the following change: >>> >>> This change creates intrinsics for addExact(long, long), subtractExact, >>> negateExact, incrementExact, decrementExact and multiplyExact. >>> >>> The intrinsics are only added on x86 and only 64-bit has the intrinsics >>> for the long-versions. (32-bit only has int-versions). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 >>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ >>> >>> Thanks >>> /R >> > /R From christian.thalinger at oracle.com Tue Oct 22 15:31:28 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 15:31:28 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM Message-ID: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8026328 http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ 8026328: Setting a breakpoint on invokedynamic crashes the JVM Reviewed-by: Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. From john.r.rose at oracle.com Tue Oct 22 16:11:44 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 22 Oct 2013 16:11:44 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> References: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> Message-ID: Reviewed. Nice fix, and very nice cleanups. Thanks for nuking those stray "0xFF" constants along the way. ? John On Oct 22, 2013, at 3:31 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8026328 > http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ > > 8026328: Setting a breakpoint on invokedynamic crashes the JVM > Reviewed-by: > > Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. > > The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. > > There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. > From christian.thalinger at oracle.com Tue Oct 22 16:16:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 16:16:38 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: References: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> Message-ID: On Oct 22, 2013, at 4:11 PM, John Rose wrote: > Reviewed. Nice fix, and very nice cleanups. Thank you, John. > > Thanks for nuking those stray "0xFF" constants along the way. Yeah, it's easier to understand now. > > ? John > > On Oct 22, 2013, at 3:31 PM, Christian Thalinger wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8026328 >> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >> >> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >> Reviewed-by: >> >> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >> >> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >> >> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >> > From christian.thalinger at oracle.com Tue Oct 22 16:25:22 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 16:25:22 -0700 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <52668A55.40605@oracle.com> References: <52668A55.40605@oracle.com> Message-ID: On Oct 22, 2013, at 7:23 AM, Albert Noll wrote: > Hi all, > > I worked on this bug for some time but so far I was not able to determine its root cause. > However, I have found a work around that hides the problem. Since it is important > for the embedded version of hotspot to work with small code cache sizes + nashorn, > I would suggest to apply this workaround, and file another bug that investigates the problem > (e.g., a P4) that we can defer. > > bug: https://bugs.openjdk.java.net/browse/JDK-8026407 > webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ > > problem: If we do not create native wrapper for method handle intrinsics, we get > segfaults in compiled code. Also, if -XX:VerifyAdapterCalls is enabled, we > get: > > assert(false) failed: DEBUG MESSAGE: i2c adapter must return to an interpreter frame > > The bug seems to be specific to method handle intrinsics. I assume that we either call > the wrong entry point to a compiled method, or there is a bug somewhere in the generated > adapters. Method handle intrinsics are treated specifically in various parts of the code and > I do not yet really understand everything. I can tell you why (as could John): in order to properly handle the appendix argument for out-of-line calls we are using a small trampoline that pops off the appendix argument and jumps to the target (see gen_special_dispatch in SharedRuntime). Since normal compiled-to-compiled calls are not able to handle such a thing we MUST generate an adapter in this case. If we can't generate one and use it we can not execute the out-of-line method handle calls. > > solution: As mentioned above, the solution is a workaround and does not solve the real problem. > Nevertheless it improves stability of hotspot and the impact of the proposed changes are > marginal. > > testing: Running nashorn with small code cache size (3m) on PPC and x86 > > There will be a separate mail for closed part changes. > > Many thanks in advance, > Albert > > P.S.: If anyone has an idea of where the problem could be, please let me know! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/655a36a0/attachment.html From christian.thalinger at oracle.com Tue Oct 22 17:20:26 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 17:20:26 -0700 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL In-Reply-To: <526646DB.5020206@oracle.com> References: <52653576.8020600@oracle.com> <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> <526646DB.5020206@oracle.com> Message-ID: <964BAA72-4A00-4AC2-A87D-A6FBE2605B02@oracle.com> On Oct 22, 2013, at 2:35 AM, Niclas Adlertz wrote: > CTW and JPRT doesn't trigger this (that's why it was pushed unnoticed). > However, I have tested 'java/lang/Character/CheckScript.java' with this fix and it now works. > > (java/lang/Character/CheckScript.java was a failing test in nightlies) Okay. Looks good. > > Kind Regards, > Niclas Adlertz > > On 2013-10-22 05:27, Christian Thalinger wrote: >> What testing did you do? >> >> On Oct 21, 2013, at 7:08 AM, Niclas Adlertz wrote: >> >>> Hi all, >>> >>> Now that more nodes can be rematerialized due to fix JDK-8022783, a rematerialized node can have a spilled live range as input even when rematerializing input for phi nodes (in the Phi Node Splitting pass). >>> Prior to the JDK-8013830 and JDK-8005956 fixes, the Reachblock pointer could be wrong (hence the warning in JDK-8013830). Now, we pass in the correct block-reaches, i.e. the reaches for the 'pred' block. >>> >>> Kind Regards, >>> Niclas Adlertz >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8026939 >>> WEBREV: cr.openjdk.net is down so I'm pasting the diff here: >>> >>> diff -r 52575a17a36c src/share/vm/opto/reg_split.cpp >>> --- a/src/share/vm/opto/reg_split.cpp Mon Oct 21 09:21:41 2013 +0400 >>> +++ b/src/share/vm/opto/reg_split.cpp Mon Oct 21 15:34:42 2013 +0200 >>> @@ -365,7 +365,6 @@ >>> } >>> if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { >>> - assert(Reachblock != NULL, "Reachblock must be non-NULL"); >>> Node *rdef = Reachblock[lrg2reach[lidx]]; >>> if (rdef) { >>> spill->set_req(i, rdef); >>> @@ -476,7 +475,6 @@ >>> uint bidx, pidx, slidx, insidx, inpidx, twoidx; >>> uint non_phi = 1, spill_cnt = 0; >>> - Node **Reachblock; >>> Node *n1, *n2, *n3; >>> Node_List *defs,*phis; >>> bool *UPblock; >>> @@ -559,7 +557,7 @@ >>> b = _cfg.get_block(bidx); >>> // Reaches & UP arrays for this block >>> - Reachblock = Reaches[b->_pre_order]; >>> + Node** Reachblock = Reaches[b->_pre_order]; >>> UPblock = UP[b->_pre_order]; >>> // Reset counter of start of non-Phi nodes in block >>> non_phi = 1; >>> @@ -1315,6 +1313,7 @@ >>> pidx = pred->_pre_order; >>> // Grab reaching def >>> Node *def = Reaches[pidx][slidx]; >>> + Node** Reachblock = Reaches[pidx]; >>> assert( def, "must have reaching def" ); >>> // If input up/down sense and reg-pressure DISagree >>> if (def->rematerialize()) { >>> @@ -1327,8 +1326,7 @@ >>> _lrg_map.find(pred->get_node(insert - 1)) >= lrgs_before_phi_split) { >>> insert--; >>> } >>> - // since the def cannot contain any live range input, we can pass in NULL as Reachlock parameter >>> - def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, NULL, false); >>> + def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, Reachblock, false); >>> if (!def) { >>> return 0; // Bail out >>> } >> > From christian.thalinger at oracle.com Tue Oct 22 17:31:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 17:31:40 -0700 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> Message-ID: <50ACE1D5-6570-44B8-AB20-60F98B941259@oracle.com> On Oct 22, 2013, at 6:38 AM, Roland Westrelin wrote: > The UseTypeSpeculation in the webrev is diagnostic which doesn't make much sense. Shouldn't I make it product or maybe experimental? Yeah, I agree. We'd need something like diagnostic but for non-diagnostic flags. experimental is probably the closest we have right now. > > Roland. > > On Oct 21, 2013, at 10:10 PM, Roland Westrelin wrote: > >> Here is a new webrev that should address all comments: >> >> http://cr.openjdk.java.net/~roland/8024070/webrev.02/ >> >> Roland. >> >> >> On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: >> >>> Roland, >>> >>> I looked on whole changes. >>> >>> Please, switch off UseTypeSpeculation by default as we discussed. >>> >>> I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. >>> >>> ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": >>> >>> + // Return true if profiling provides a type for the argument nb to the >>> >>> I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. >>> >>> It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. >>> >>> compile.cpp next comment is wrong since you keep using CastPP nodes: >>> >>> + // Remove the speculative part of types and clean up the graph from >>> + // the extra CheckCastPP nodes whose only purpose is to carry >>> + // them. Do that early so that optimizations are not disrupted by >>> + // the extra CheckCastPP nodes. >>> >>> 'tmp' is not good name for a 'list': >>> + Unique_Node_List tmp; >>> >>> Split next line: >>> >>> + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { >>> >>> >>> doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). >>> >>> graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. >>> >>> library_call.cpp split next line: >>> >>> + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); >>> >>> >>> parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >>>> Roland, >>>> >>>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>> correctly if klass() == tap->klass() >>>> >>>> Lets leave NULL for now because in general meet(con, bot) = bot. It may >>>> change code generation more then other changes and we don't want it now. >>>> >>>>> >>>>> I've been trying to write simple tests to reproduce those failures >>>> without much success. Any suggestion what simple java code I can write >>>> to have something of ptr type AnyNull? >>>> >>>> AnyNull is ptr_dual for NotNull. Meets with it is checked in >>>> Type::meet(). So it should work for tests only with NotNull. >>>> >>>> Vladimir >>>> >>>> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>>>> Here is a new webrev for this: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>>>> >>>>>>> I applied your suggestions below. >>>>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>>>> profiling data that we use right away so reusing profiling for this, >>>>>>> I find confusing. >>>>>> >>>>>> Okay. >>>>>> >>>>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>>>> problems that need investigation. I did extensive testing with the >>>>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>>>> >>>>>> Yes, it is fine. >>>>>> >>>>>>> >>>>>>> type.cpp has several generic type system fixes: >>>>>>> >>>>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>>>> !klass_is_exact()) { >>>>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>>>> 3186 } else { >>>>>> >>>>>> Looks correct but, please, make sure it works for multi-dimensional >>>>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>>>> that sometimes exact Object klass may be not really exact. >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>>> >>>>>>> mimics what we do for instance klass with subclass/superclass when >>>>>>> both subclass and superclass are exact >>>>>>> >>>>>>> 3315 if( this_klass->is_interface() && >>>>>>> !(tinst_klass->is_interface() || >>>>>>> 3316 tinst_klass == >>>>>>> ciEnv::current()->Object_klass())) { >>>>>>> >>>>>>> is required because otherwise if tinst_klass is of an object class, >>>>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>>>> this->_ptr and tinst->_ptr which were not swapped. >>>>>> >>>>>> Seems reasonable. >>>>>> >>>>>>> >>>>>>> I also had to make the cases: >>>>>>> >>>>>>> 3818 case AnyNull: >>>>>>> 3819 case TopPTR: >>>>>>> >>>>>>> and >>>>>>> >>>>>>> 3847 case NotNull: >>>>>>> 3848 case BotPTR: >>>>>>> >>>>>>> symmetrical which they are not currently. >>>>>> >>>>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>>>> place (it was always false). >>>>>> With your changes the code is still not symmetrical. I think in last >>>>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>>>> const_oop() to constructor. This is what we do when tap is Const and >>>>>> 'this' is below. >>>>> >>>>> Wouldn't this be sufficient as a fix? >>>>> >>>>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>>>> --- a/src/share/vm/opto/type.cpp >>>>> +++ b/src/share/vm/opto/type.cpp >>>>> @@ -3851,7 +3851,7 @@ >>>>> xk = tap->_klass_is_exact; >>>>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>>>> (klass() == tap->klass()); // Only precise for >>>>> identical arrays >>>>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>>>> instance_id, speculative); >>>>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>>>> lazy_klass, xk, off, instance_id, speculative); >>>>> default: ShouldNotReachHere(); >>>>> } >>>>> } >>>>> >>>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>>> correctly if klass() == tap->klass() >>>>> >>>>> I've been trying to write simple tests to reproduce those failures >>>>> without much success. Any suggestion what simple java code I can write >>>>> to have something of ptr type AnyNull? >>>>> >>>>> Thanks, >>>>> Roland. >>>>> >>>>>> >>>>>> I need to look on whole changes later. I will send additional comments. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> General notes: >>>>>>>> >>>>>>>> I think 'speculative' is not right word. We get these types from >>>>>>>> profiling when we see only one type. And we use it only after >>>>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>>>> it comes from. Or other more appropriate name. >>>>>>>> >>>>>>>> You need to add jtreg tests to verify these changes for different >>>>>>>> cases (especially merge points with different profile types). >>>>>>>> >>>>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>>>> Phi nodes and further anyway. >>>>>>>> >>>>>>>> Small notes: >>>>>>>> >>>>>>>> c2_globals.hpp: >>>>>>>> >>>>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>>>> >>>>>>>> drop_speculative* --> remove_speculative* >>>>>>>> >>>>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>>>> for last parameters. >>>>>>>> >>>>>>>> In a lot of places you use: >>>>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>>>> >>>>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>>>> use in such cases. >>>>>>>> >>>>>>>> library_call.cpp: typo: >>>>>>>> >>>>>>>> ciKlass* src_k, *dest_k; >>>>>>>> ^ >>>>>>>> regards, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>>>> Roland, >>>>>>>>> >>>>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>>>> Regression could be also caused by different inlining >>>>>>>>> (InlineSmallCode) >>>>>>>>> because more uncommon traps are generated. >>>>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>>>> am also >>>>>>>>> looking on your extra type profiling changes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>>>> Always >>>>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>>>> more >>>>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>>>> it is. >>>>>>>>>>> >>>>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>>>> It's >>>>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>>>> experiment >>>>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>>>> impact we >>>>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>>>> method >>>>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>>>> >>>>>>>>>> This is the kind of results I get with nashorn: >>>>>>>>>> deltablue: >>>>>>>>>> current: 2345 >>>>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>>>> >>>>>>>>>> RayTrace: >>>>>>>>>> current: 1978 >>>>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>>>> >>>>>>>>>> Richards: >>>>>>>>>> current: 2222 >>>>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>>>> >>>>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>>>> method of the compilation >>>>>>>>>> - type check on return from non inlined calls >>>>>>>>>> >>>>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>>>> benchmarks: >>>>>>>>>> >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> t >>>>>>>>>> Benchmark Samples Mean Stdev >>>>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>>>> javac 10 385.70 0.05 >>>>>>>>>> db 10 444.51 0.01 >>>>>>>>>> jess 10 699.05 0.00 >>>>>>>>>> jack 10 603.98 0.01 >>>>>>>>>> compress 10 534.99 0.01 >>>>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> t2 >>>>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>>>> Significant >>>>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>>>> 0.014 * >>>>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>>>> 0.013 * >>>>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>>>> 0.875 * >>>>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>>>> 0.000 Yes >>>>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>>>> 0.425 * >>>>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>>>> 0.329 * >>>>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>>>> 0.181 * >>>>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>>>> 0.001 Yes >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>> >>>>> >> > From christian.thalinger at oracle.com Tue Oct 22 17:40:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 17:40:53 -0700 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> Message-ID: Thanks for the Doxygen comments! These are the best ones we have so far! src/share/vm/opto/phaseX.cpp: + /** + *Remove the speculative part of all types that we know of + */ Add a space after "*" and get rid of the comment in the header file. Otherwise this looks good. On Oct 21, 2013, at 1:10 PM, Roland Westrelin wrote: > Here is a new webrev that should address all comments: > > http://cr.openjdk.java.net/~roland/8024070/webrev.02/ > > Roland. > > > On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: > >> Roland, >> >> I looked on whole changes. >> >> Please, switch off UseTypeSpeculation by default as we discussed. >> >> I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. >> >> ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": >> >> + // Return true if profiling provides a type for the argument nb to the >> >> I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. >> >> It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. >> >> compile.cpp next comment is wrong since you keep using CastPP nodes: >> >> + // Remove the speculative part of types and clean up the graph from >> + // the extra CheckCastPP nodes whose only purpose is to carry >> + // them. Do that early so that optimizations are not disrupted by >> + // the extra CheckCastPP nodes. >> >> 'tmp' is not good name for a 'list': >> + Unique_Node_List tmp; >> >> Split next line: >> >> + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { >> >> >> doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). >> >> graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. >> >> library_call.cpp split next line: >> >> + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); >> >> >> parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. >> >> Thanks, >> Vladimir >> >> On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >>> Roland, >>> >>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>> correctly if klass() == tap->klass() >>> >>> Lets leave NULL for now because in general meet(con, bot) = bot. It may >>> change code generation more then other changes and we don't want it now. >>> >>>> >>>> I've been trying to write simple tests to reproduce those failures >>> without much success. Any suggestion what simple java code I can write >>> to have something of ptr type AnyNull? >>> >>> AnyNull is ptr_dual for NotNull. Meets with it is checked in >>> Type::meet(). So it should work for tests only with NotNull. >>> >>> Vladimir >>> >>> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>>> Here is a new webrev for this: >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>>> >>>>>> I applied your suggestions below. >>>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>>> profiling data that we use right away so reusing profiling for this, >>>>>> I find confusing. >>>>> >>>>> Okay. >>>>> >>>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>>> problems that need investigation. I did extensive testing with the >>>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>>> >>>>> Yes, it is fine. >>>>> >>>>>> >>>>>> type.cpp has several generic type system fixes: >>>>>> >>>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>>> !klass_is_exact()) { >>>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>>> 3186 } else { >>>>> >>>>> Looks correct but, please, make sure it works for multi-dimensional >>>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>>> that sometimes exact Object klass may be not really exact. >>>> >>>> Ok. >>>> >>>>> >>>>>> >>>>>> mimics what we do for instance klass with subclass/superclass when >>>>>> both subclass and superclass are exact >>>>>> >>>>>> 3315 if( this_klass->is_interface() && >>>>>> !(tinst_klass->is_interface() || >>>>>> 3316 tinst_klass == >>>>>> ciEnv::current()->Object_klass())) { >>>>>> >>>>>> is required because otherwise if tinst_klass is of an object class, >>>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>>> this->_ptr and tinst->_ptr which were not swapped. >>>>> >>>>> Seems reasonable. >>>>> >>>>>> >>>>>> I also had to make the cases: >>>>>> >>>>>> 3818 case AnyNull: >>>>>> 3819 case TopPTR: >>>>>> >>>>>> and >>>>>> >>>>>> 3847 case NotNull: >>>>>> 3848 case BotPTR: >>>>>> >>>>>> symmetrical which they are not currently. >>>>> >>>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>>> place (it was always false). >>>>> With your changes the code is still not symmetrical. I think in last >>>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>>> const_oop() to constructor. This is what we do when tap is Const and >>>>> 'this' is below. >>>> >>>> Wouldn't this be sufficient as a fix? >>>> >>>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>>> --- a/src/share/vm/opto/type.cpp >>>> +++ b/src/share/vm/opto/type.cpp >>>> @@ -3851,7 +3851,7 @@ >>>> xk = tap->_klass_is_exact; >>>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>>> (klass() == tap->klass()); // Only precise for >>>> identical arrays >>>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>>> instance_id, speculative); >>>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>>> lazy_klass, xk, off, instance_id, speculative); >>>> default: ShouldNotReachHere(); >>>> } >>>> } >>>> >>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>> correctly if klass() == tap->klass() >>>> >>>> I've been trying to write simple tests to reproduce those failures >>>> without much success. Any suggestion what simple java code I can write >>>> to have something of ptr type AnyNull? >>>> >>>> Thanks, >>>> Roland. >>>> >>>>> >>>>> I need to look on whole changes later. I will send additional comments. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>>> General notes: >>>>>>> >>>>>>> I think 'speculative' is not right word. We get these types from >>>>>>> profiling when we see only one type. And we use it only after >>>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>>> it comes from. Or other more appropriate name. >>>>>>> >>>>>>> You need to add jtreg tests to verify these changes for different >>>>>>> cases (especially merge points with different profile types). >>>>>>> >>>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>>> Phi nodes and further anyway. >>>>>>> >>>>>>> Small notes: >>>>>>> >>>>>>> c2_globals.hpp: >>>>>>> >>>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>>> >>>>>>> drop_speculative* --> remove_speculative* >>>>>>> >>>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>>> for last parameters. >>>>>>> >>>>>>> In a lot of places you use: >>>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>>> >>>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>>> use in such cases. >>>>>>> >>>>>>> library_call.cpp: typo: >>>>>>> >>>>>>> ciKlass* src_k, *dest_k; >>>>>>> ^ >>>>>>> regards, >>>>>>> Vladimir >>>>>>> >>>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>>> Roland, >>>>>>>> >>>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>>> Regression could be also caused by different inlining >>>>>>>> (InlineSmallCode) >>>>>>>> because more uncommon traps are generated. >>>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>>> am also >>>>>>>> looking on your extra type profiling changes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>>> Always >>>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>>> more >>>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>>> it is. >>>>>>>>>> >>>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>>> It's >>>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>>> experiment >>>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>>> impact we >>>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>>> method >>>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>>> >>>>>>>>> This is the kind of results I get with nashorn: >>>>>>>>> deltablue: >>>>>>>>> current: 2345 >>>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>>> >>>>>>>>> RayTrace: >>>>>>>>> current: 1978 >>>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>>> >>>>>>>>> Richards: >>>>>>>>> current: 2222 >>>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>>> >>>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>>> method of the compilation >>>>>>>>> - type check on return from non inlined calls >>>>>>>>> >>>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>>> benchmarks: >>>>>>>>> >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> t >>>>>>>>> Benchmark Samples Mean Stdev >>>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>>> javac 10 385.70 0.05 >>>>>>>>> db 10 444.51 0.01 >>>>>>>>> jess 10 699.05 0.00 >>>>>>>>> jack 10 603.98 0.01 >>>>>>>>> compress 10 534.99 0.01 >>>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> t2 >>>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>>> Significant >>>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>>> 0.014 * >>>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>>> 0.013 * >>>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>>> 0.875 * >>>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>>> 0.000 Yes >>>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>>> 0.425 * >>>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>>> 0.329 * >>>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>>> 0.181 * >>>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>>> 0.001 Yes >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Roland. >>>>>>>>> >>>>>> >>>> > From christian.thalinger at oracle.com Tue Oct 22 17:45:51 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 17:45:51 -0700 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <5266CF8C.70305@oracle.com> References: <5266CF8C.70305@oracle.com> Message-ID: <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> 44 // Check that the outputs are equal 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { Is this testing the full output or only the first line? Because the outputs are not equal: $ java -Xint -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, interpreted mode) $ java -Xcomp -version java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, compiled mode) On Oct 22, 2013, at 12:18 PM, Albert Noll wrote: > Hi, > > sure, here is the patch including the test: > > http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ > > Best, > Albert > > On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >> Albert, please add a jtreg test for this change. I think it is very easy: just start 'java -version' as a external process and check its output in 'Xint' and '-Xcomp' cases. If you don't think so, please file a RFE to add regression test and assign it to me. >> >> Thanks. >> - Igor >> >> ----- Reply message ----- >> From: "Albert Noll" >> To: "Igor Veresov" >> Cc: "hotspot-compiler-dev at openjdk.java.net" >> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) >> Date: Tue, Oct 22, 2013 22:03 >> >> Roland, Igor, thanks for looking at this. >> >> I tested the patch as follows: >> >> java -Xint -version .. make sure that output does not appear >> java -Xcomp -version make sure that compiler(s) are working >> >> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and -Xcomp and -Xmixed) >> >> Seems to work fine. >> >> Best, >> Albert >> >> On 22.10.2013 19:12, Igor Veresov wrote: >>> Looks good. >>> >>> igor >>> >>> On Oct 22, 2013, at 6:15 AM, Albert Noll wrote: >>> >>>> Thanks Igor. This is a good solution. >>>> >>>> Here is the webrev: >>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>> >>>> Best, >>>> Albert >>>> >>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>> Another trivial fix option is to just bail out of CompileBroker::compilation_init() is UseCompiler is false. To avoid initializing the compiler objects and all.. >>>>> >>>>> igor >>>>> >>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll wrote: >>>>> >>>>>> Christian, Igor, thanks for the reviews. >>>>>> >>>>>> There seems to be an ambiguity between -Xint and -XX:+UseCompiler. Whether we use a compiler or >>>>>> not, depends on the order in which the arguments are given. I am not exactly sure why we have >>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>> >>>>>> The reason why I added the checks when we determine the number of compiler threads is that we >>>>>> do not generate the compiler objects (they are not needed). Also, the number of compiler threads >>>>>> is set correctly. >>>>>> >>>>>> The solution proposed by Igor is simpler. If the above issues do not matter, I would also opt for the >>>>>> simple solution. >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>> If think you can just use the existing "UseCompiler" flag, that we set to false when -Xint is specified and just not call init_compiler_threads() if UseCompiler == false. >>>>>>> >>>>>>> igor >>>>>>> >>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> could I have reviews for this small patch? >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>> >>>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of C1 thread failed (no space to run compilers) when the VM is started >>>>>>>> with -Xint >>>>>>>> >>>>>>>> Solution: Do not start compiler threads if VM is started with -Xint >>>>>>>> >>>>>>>> Testing: -Xint flag does not print out the false warning. Tested flag combinations: >>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>> >>>>>>>> >>>>>>>> Many thanks in advance, >>>>>>>> Albert >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/f2e78e29/attachment-0001.html From igor.veresov at oracle.com Tue Oct 22 20:18:45 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Oct 2013 20:18:45 -0700 Subject: RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 Message-ID: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit. Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support. Webrev: http://cr.openjdk.java.net/~iveresov/8026495/ Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress igor From christian.thalinger at oracle.com Tue Oct 22 20:24:49 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 20:24:49 -0700 Subject: RFR (S): 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Message-ID: <49C3E7CB-2FFF-4C53-B171-B9EFFC6DFB73@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8026502 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: There are two sides to this fix: 1) hardening the VM so it doesn't fall over input it shouldn't get: diff -r 36e17466dd39 src/share/vm/classfile/systemDictionary.cpp --- a/src/share/vm/classfile/systemDictionary.cpp Tue Oct 22 14:02:15 2013 +0000 +++ b/src/share/vm/classfile/systemDictionary.cpp Tue Oct 22 20:17:52 2013 -0700 @@ -2360,6 +2360,11 @@ methodHandle SystemDictionary::find_meth objArrayHandle appendix_box = oopFactory::new_objArray(SystemDictionary::Object_klass(), 1, CHECK_(empty)); assert(appendix_box->obj_at(0) == NULL, ""); + // This should not happen. JDK code should take care of that. + if (accessing_klass.is_null() || method_type.is_null()) { + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad invokehandle", empty); + } + // call java.lang.invoke.MethodHandleNatives::linkMethod(... String, MethodType) -> MemberName JavaCallArguments args; args.push_oop(accessing_klass()->java_mirror()); @@ -2485,6 +2490,9 @@ Handle SystemDictionary::link_method_han Handle type; if (signature->utf8_length() > 0 && signature->byte_at(0) == '(') { type = find_method_handle_type(signature, caller, CHECK_(empty)); + } else if (caller.is_null()) { + // This should not happen. JDK code should take care of that. + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad MH constant", empty); } else { ResourceMark rm(THREAD); SignatureStream ss(signature, false); @@ -2548,6 +2556,11 @@ methodHandle SystemDictionary::find_dyna Handle method_name = java_lang_String::create_from_symbol(name, CHECK_(empty)); Handle method_type = find_method_handle_type(type, caller, CHECK_(empty)); + // This should not happen. JDK code should take care of that. + if (caller.is_null() || method_type.is_null()) { + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad invokedynamic", empty); + } + objArrayHandle appendix_box = oopFactory::new_objArray(SystemDictionary::Object_klass(), 1, CHECK_(empty)); assert(appendix_box->obj_at(0) == NULL, ""); 2) fix the JDK code so it doesn't pass input to the VM it shouldn't: diff -r 0913c3bab168 src/share/classes/java/lang/invoke/MethodHandles.java --- a/src/share/classes/java/lang/invoke/MethodHandles.java Tue Oct 22 15:12:22 2013 -0700 +++ b/src/share/classes/java/lang/invoke/MethodHandles.java Tue Oct 22 19:49:01 2013 -0700 @@ -1716,6 +1716,13 @@ return mh1; checkSymbolicClass(defc); return mh; } + // Treat MethodHandle.invoke and invokeExact specially. + if (defc == MethodHandle.class && refKind == REF_invokeVirtual) { + mh = findVirtualForMH(member.getName(), member.getMethodType()); + if (mh != null) { + return mh; + } + } MemberName resolved = resolveOrFail(refKind, member); mh = getDirectMethodForConstant(refKind, defc, resolved); if (mh instanceof DirectMethodHandle @@ -1768,12 +1775,6 @@ return mh1; if (MethodHandleNatives.refKindIsField(refKind)) { return getDirectFieldNoSecurityManager(refKind, defc, member); } else if (MethodHandleNatives.refKindIsMethod(refKind)) { - if (defc == MethodHandle.class && refKind == REF_invokeVirtual) { - MethodHandle mh = findVirtualForMH(member.getName(), member.getMethodType()); - if (mh != null) { - return mh; - } - } return getDirectMethodNoSecurityManager(refKind, defc, member, lookupClass); } else if (refKind == REF_newInvokeSpecial) { return getDirectConstructorNoSecurityManager(defc, member); From igor.veresov at oracle.com Tue Oct 22 20:33:13 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Oct 2013 20:33:13 -0700 Subject: RFR (S): 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms In-Reply-To: <49C3E7CB-2FFF-4C53-B171-B9EFFC6DFB73@oracle.com> References: <49C3E7CB-2FFF-4C53-B171-B9EFFC6DFB73@oracle.com> Message-ID: Looks fine. igor On Oct 22, 2013, at 8:24 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8026502 > > 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms > Reviewed-by: > > There are two sides to this fix: > > 1) hardening the VM so it doesn't fall over input it shouldn't get: > > diff -r 36e17466dd39 src/share/vm/classfile/systemDictionary.cpp > --- a/src/share/vm/classfile/systemDictionary.cpp Tue Oct 22 14:02:15 2013 +0000 > +++ b/src/share/vm/classfile/systemDictionary.cpp Tue Oct 22 20:17:52 2013 -0700 > @@ -2360,6 +2360,11 @@ methodHandle SystemDictionary::find_meth > objArrayHandle appendix_box = oopFactory::new_objArray(SystemDictionary::Object_klass(), 1, CHECK_(empty)); > assert(appendix_box->obj_at(0) == NULL, ""); > > + // This should not happen. JDK code should take care of that. > + if (accessing_klass.is_null() || method_type.is_null()) { > + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad invokehandle", empty); > + } > + > // call java.lang.invoke.MethodHandleNatives::linkMethod(... String, MethodType) -> MemberName > JavaCallArguments args; > args.push_oop(accessing_klass()->java_mirror()); > @@ -2485,6 +2490,9 @@ Handle SystemDictionary::link_method_han > Handle type; > if (signature->utf8_length() > 0 && signature->byte_at(0) == '(') { > type = find_method_handle_type(signature, caller, CHECK_(empty)); > + } else if (caller.is_null()) { > + // This should not happen. JDK code should take care of that. > + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad MH constant", empty); > } else { > ResourceMark rm(THREAD); > SignatureStream ss(signature, false); > @@ -2548,6 +2556,11 @@ methodHandle SystemDictionary::find_dyna > Handle method_name = java_lang_String::create_from_symbol(name, CHECK_(empty)); > Handle method_type = find_method_handle_type(type, caller, CHECK_(empty)); > > + // This should not happen. JDK code should take care of that. > + if (caller.is_null() || method_type.is_null()) { > + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad invokedynamic", empty); > + } > + > objArrayHandle appendix_box = oopFactory::new_objArray(SystemDictionary::Object_klass(), 1, CHECK_(empty)); > assert(appendix_box->obj_at(0) == NULL, ""); > > 2) fix the JDK code so it doesn't pass input to the VM it shouldn't: > > diff -r 0913c3bab168 src/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/share/classes/java/lang/invoke/MethodHandles.java Tue Oct 22 15:12:22 2013 -0700 > +++ b/src/share/classes/java/lang/invoke/MethodHandles.java Tue Oct 22 19:49:01 2013 -0700 > @@ -1716,6 +1716,13 @@ return mh1; > checkSymbolicClass(defc); > return mh; > } > + // Treat MethodHandle.invoke and invokeExact specially. > + if (defc == MethodHandle.class && refKind == REF_invokeVirtual) { > + mh = findVirtualForMH(member.getName(), member.getMethodType()); > + if (mh != null) { > + return mh; > + } > + } > MemberName resolved = resolveOrFail(refKind, member); > mh = getDirectMethodForConstant(refKind, defc, resolved); > if (mh instanceof DirectMethodHandle > @@ -1768,12 +1775,6 @@ return mh1; > if (MethodHandleNatives.refKindIsField(refKind)) { > return getDirectFieldNoSecurityManager(refKind, defc, member); > } else if (MethodHandleNatives.refKindIsMethod(refKind)) { > - if (defc == MethodHandle.class && refKind == REF_invokeVirtual) { > - MethodHandle mh = findVirtualForMH(member.getName(), member.getMethodType()); > - if (mh != null) { > - return mh; > - } > - } > return getDirectMethodNoSecurityManager(refKind, defc, member, lookupClass); > } else if (refKind == REF_newInvokeSpecial) { > return getDirectConstructorNoSecurityManager(defc, member); > > From christian.thalinger at oracle.com Tue Oct 22 20:33:16 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 20:33:16 -0700 Subject: RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 In-Reply-To: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> References: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> Message-ID: src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: + #ifdef _LP64 + Register thread = r15_thread; + #else __ get_thread(rsi); ! __ movptr(rax, Address(rsi, JavaThread::exception_oop_offset())); __ movptr(Address(rsi, JavaThread::exception_oop_offset()), (intptr_t)NULL_WORD); ! __ movptr(Address(rsi, JavaThread::exception_pc_offset()), (intptr_t)NULL_WORD); ! Register thread = rsi; + #endif I'd prefer using LP64_ONLY and NOT_LP64 on one line. src/share/vm/c1/c1_LIRGenerator.cpp: if (x->pass_thread()) { ! signature->append(T_ADDRESS); ! signature->append(LP64_ONLY(T_LONG) NOT_LP64(T_INT)); // thread args->append(getThreadPointer()); } Why can it not be T_ADDRESS? On Oct 22, 2013, at 8:18 PM, Igor Veresov wrote: > A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit. > Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support. > > Webrev: http://cr.openjdk.java.net/~iveresov/8026495/ > > Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress > > igor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/d21c4582/attachment.html From igor.veresov at oracle.com Tue Oct 22 21:35:42 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Oct 2013 21:35:42 -0700 Subject: RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 In-Reply-To: References: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> Message-ID: <2A138BBF-F333-4EFD-BFC6-C94DFCB2F941@oracle.com> On Oct 22, 2013, at 8:33 PM, Christian Thalinger wrote: > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: > + #ifdef _LP64 > + Register thread = r15_thread; > + #else > __ get_thread(rsi); > ! __ movptr(rax, Address(rsi, JavaThread::exception_oop_offset())); > __ movptr(Address(rsi, JavaThread::exception_oop_offset()), (intptr_t)NULL_WORD); > ! __ movptr(Address(rsi, JavaThread::exception_pc_offset()), (intptr_t)NULL_WORD); > ! Register thread = rsi; > + #endif > I'd prefer using LP64_ONLY and NOT_LP64 on one line. There is get_thread() on 32bit, it's not going to be one line. But I agree it's better looking. Review updated in-place. > > src/share/vm/c1/c1_LIRGenerator.cpp: > if (x->pass_thread()) { > ! signature->append(T_ADDRESS); > ! signature->append(LP64_ONLY(T_LONG) NOT_LP64(T_INT)); // thread > args->append(getThreadPointer()); > } > Why can it not be T_ADDRESS? It can, but getThreadPointer() returns either T_INT or T_LONG (probably historically) and I'd like it to be consistent. Speaking of T_ADDRESS, this change also fixes the size of the T_ADDRESS spill, which was always 4 bytes. igor > > On Oct 22, 2013, at 8:18 PM, Igor Veresov wrote: > >> A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit. >> Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8026495/ >> >> Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress >> >> igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/c0f91cd7/attachment-0001.html From john.r.rose at oracle.com Tue Oct 22 21:45:49 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 22 Oct 2013 21:45:49 -0700 Subject: RFR (S): 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms In-Reply-To: <49C3E7CB-2FFF-4C53-B171-B9EFFC6DFB73@oracle.com> References: <49C3E7CB-2FFF-4C53-B171-B9EFFC6DFB73@oracle.com> Message-ID: Re-viewed. In both senses, since I've viewed that change already. ? John On Oct 22, 2013, at 8:24 PM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8026502 > > 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms > Reviewed-by: > > There are two sides to this fix: > > 1) hardening the VM so it doesn't fall over input it shouldn't get: > > diff -r 36e17466dd39 src/share/vm/classfile/systemDictionary.cpp > --- a/src/share/vm/classfile/systemDictionary.cpp Tue Oct 22 14:02:15 2013 +0000 > +++ b/src/share/vm/classfile/systemDictionary.cpp Tue Oct 22 20:17:52 2013 -0700 > @@ -2360,6 +2360,11 @@ methodHandle SystemDictionary::find_meth > objArrayHandle appendix_box = oopFactory::new_objArray(SystemDictionary::Object_klass(), 1, CHECK_(empty)); > assert(appendix_box->obj_at(0) == NULL, ""); > > + // This should not happen. JDK code should take care of that. > + if (accessing_klass.is_null() || method_type.is_null()) { > + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad invokehandle", empty); > + } > + > // call java.lang.invoke.MethodHandleNatives::linkMethod(... String, MethodType) -> MemberName > JavaCallArguments args; > args.push_oop(accessing_klass()->java_mirror()); > @@ -2485,6 +2490,9 @@ Handle SystemDictionary::link_method_han > Handle type; > if (signature->utf8_length() > 0 && signature->byte_at(0) == '(') { > type = find_method_handle_type(signature, caller, CHECK_(empty)); > + } else if (caller.is_null()) { > + // This should not happen. JDK code should take care of that. > + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad MH constant", empty); > } else { > ResourceMark rm(THREAD); > SignatureStream ss(signature, false); > @@ -2548,6 +2556,11 @@ methodHandle SystemDictionary::find_dyna > Handle method_name = java_lang_String::create_from_symbol(name, CHECK_(empty)); > Handle method_type = find_method_handle_type(type, caller, CHECK_(empty)); > > + // This should not happen. JDK code should take care of that. > + if (caller.is_null() || method_type.is_null()) { > + THROW_MSG_(vmSymbols::java_lang_InternalError(), "bad invokedynamic", empty); > + } > + > objArrayHandle appendix_box = oopFactory::new_objArray(SystemDictionary::Object_klass(), 1, CHECK_(empty)); > assert(appendix_box->obj_at(0) == NULL, ""); > > 2) fix the JDK code so it doesn't pass input to the VM it shouldn't: > > diff -r 0913c3bab168 src/share/classes/java/lang/invoke/MethodHandles.java > --- a/src/share/classes/java/lang/invoke/MethodHandles.java Tue Oct 22 15:12:22 2013 -0700 > +++ b/src/share/classes/java/lang/invoke/MethodHandles.java Tue Oct 22 19:49:01 2013 -0700 > @@ -1716,6 +1716,13 @@ return mh1; > checkSymbolicClass(defc); > return mh; > } > + // Treat MethodHandle.invoke and invokeExact specially. > + if (defc == MethodHandle.class && refKind == REF_invokeVirtual) { > + mh = findVirtualForMH(member.getName(), member.getMethodType()); > + if (mh != null) { > + return mh; > + } > + } > MemberName resolved = resolveOrFail(refKind, member); > mh = getDirectMethodForConstant(refKind, defc, resolved); > if (mh instanceof DirectMethodHandle > @@ -1768,12 +1775,6 @@ return mh1; > if (MethodHandleNatives.refKindIsField(refKind)) { > return getDirectFieldNoSecurityManager(refKind, defc, member); > } else if (MethodHandleNatives.refKindIsMethod(refKind)) { > - if (defc == MethodHandle.class && refKind == REF_invokeVirtual) { > - MethodHandle mh = findVirtualForMH(member.getName(), member.getMethodType()); > - if (mh != null) { > - return mh; > - } > - } > return getDirectMethodNoSecurityManager(refKind, defc, member, lookupClass); > } else if (refKind == REF_newInvokeSpecial) { > return getDirectConstructorNoSecurityManager(defc, member); > > From rickard.backman at oracle.com Tue Oct 22 21:52:00 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 23 Oct 2013 06:52:00 +0200 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> <20131022135635.GF13244@rbackman> Message-ID: <20131023045200.GH13244@rbackman> Thank you for the review, Christian. On 10/22, Christian Thalinger wrote: > Looks good. Not sure about the FlagsProj push change; Vladimir should look at this as well. > > On Oct 22, 2013, at 6:56 AM, Rickard B?ckman wrote: > > > Christian, > > > > new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ > > The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ > > (I missed x86_32.ad when generating it, but everything else should be > > there). > > > > I removed the timeouts, they were remains of another attempt at writing > > tests. > > > > Thanks > > > > On 10/18, Christian Thalinger wrote: > >> src/share/vm/opto/library_call.cpp: > >> > >> + Node* arg1 = argument(0); // type long > >> + // argument(1) == TOP > >> + Node* arg2 = argument(2); // type long > >> + // argument(4) == TOP > >> > >> The "argument(4)" comment it wrong; should be 3. > >> > >> + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); > >> > >> Remove the extra spaces. > >> > >> src/share/vm/opto/mathexactnode.hpp: > >> > >> + MathExactNode(Node* ctrl, Node* n1); > >> MathExactNode(Node* ctrl, Node* in1, Node* in2); > >> > >> Should "n1" be "in1"? Or maybe just "n". > >> > >> These have two copyright headers: > >> > >> test/compiler/intrinsics/mathexact/IncExactITest.java > >> test/compiler/intrinsics/mathexact/IncExactLTest.java > >> > >> It seems all of the tests have a wrong bug number: > >> > >> 26 * @bug 8024924 > >> > >> or > >> > >> 26 * @bug 8025657 > >> > >> test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: > >> > >> 28 * @compile MulExactIRepeatTest.java > >> > >> That one doesn't compile Verify.java. Please check all of the test files for these issue. > >> > >> In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? > >> > >> The question is do we really need individual test files for these? I don't object just mentioning it. > >> > >> On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: > >> > >>> Hi, can I get reviews for the following change: > >>> > >>> This change creates intrinsics for addExact(long, long), subtractExact, > >>> negateExact, incrementExact, decrementExact and multiplyExact. > >>> > >>> The intrinsics are only added on x86 and only 64-bit has the intrinsics > >>> for the long-versions. (32-bit only has int-versions). > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > >>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > >>> > >>> Thanks > >>> /R > >> > > /R > /R From john.r.rose at oracle.com Tue Oct 22 22:06:40 2013 From: john.r.rose at oracle.com (John Rose) Date: Tue, 22 Oct 2013 22:06:40 -0700 Subject: RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 In-Reply-To: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> References: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> Message-ID: On Oct 22, 2013, at 8:18 PM, Igor Veresov wrote: > A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit. > Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support. > > Webrev: http://cr.openjdk.java.net/~iveresov/8026495/ > > Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress That's some technical debt there. Thanks for shoveling through it. Perhaps there's more, but this is a good barrow load to wheel away. The biggest surprise was type2spill_size. Wasn't that thing raising warnings since the no-permgen rewrite? Your use of rbx looks OK, but I wish there were a way to assert what you comment about it, that all the C compilers refrain from blowing it. Seems like something that could go wrong later. I looked around for something to grab; nothing in assembler_x86.hpp where the C calling conventions are surveyed, but perhaps we could put something there some day. The *.ad files have the info, but it's hard to get at. Anyway, reviewed. ? John P.S. I personally don't mind stacked NOT_FOO/FOO_ONLY macros if their bodies are tiny and that there are not larger changes nearby. From vladimir.kozlov at oracle.com Tue Oct 22 22:10:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Oct 2013 01:10:31 -0400 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <20131022135635.GF13244@rbackman> References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> <20131022135635.GF13244@rbackman> Message-ID: Richard, Node.hpp and corresponding constructors. You should specify id only for MathExact class since you only need query method for it (no need to specify it for subclasses). The number in DEFINE_CLASS_ID should be 4 (not 7) since the last one (for Membar) was 3. I do not understand your problem with shared nodes (matcher.cpp changes). Sharing means that separate Mach node will be generated (it will not be part of mega Mach node). So I do not see the problem. Is it load nodes you have problem with? Please, explain. About phi node. Look if it is created by spit_through_phi optimization. We should not do that because if addexact, for example, collapsed/folded on one branch how we get flag value from this branch. Thanks, Vladimir > On Oct 22, 2013, at 9:56 AM, Rickard B?ckman wrote: > > Christian, > > new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ > The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ > (I missed x86_32.ad when generating it, but everything else should be > there). > > I removed the timeouts, they were remains of another attempt at writing > tests. > > Thanks > >> On 10/18, Christian Thalinger wrote: >> src/share/vm/opto/library_call.cpp: >> >> + Node* arg1 = argument(0); // type long >> + // argument(1) == TOP >> + Node* arg2 = argument(2); // type long >> + // argument(4) == TOP >> >> The "argument(4)" comment it wrong; should be 3. >> >> + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); >> >> Remove the extra spaces. >> >> src/share/vm/opto/mathexactnode.hpp: >> >> + MathExactNode(Node* ctrl, Node* n1); >> MathExactNode(Node* ctrl, Node* in1, Node* in2); >> >> Should "n1" be "in1"? Or maybe just "n". >> >> These have two copyright headers: >> >> test/compiler/intrinsics/mathexact/IncExactITest.java >> test/compiler/intrinsics/mathexact/IncExactLTest.java >> >> It seems all of the tests have a wrong bug number: >> >> 26 * @bug 8024924 >> >> or >> >> 26 * @bug 8025657 >> >> test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: >> >> 28 * @compile MulExactIRepeatTest.java >> >> That one doesn't compile Verify.java. Please check all of the test files for these issue. >> >> In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? >> >> The question is do we really need individual test files for these? I don't object just mentioning it. >> >>> On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: >>> >>> Hi, can I get reviews for the following change: >>> >>> This change creates intrinsics for addExact(long, long), subtractExact, >>> negateExact, incrementExact, decrementExact and multiplyExact. >>> >>> The intrinsics are only added on x86 and only 64-bit has the intrinsics >>> for the long-versions. (32-bit only has int-versions). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 >>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ >>> >>> Thanks >>> /R > /R From igor.veresov at oracle.com Tue Oct 22 22:20:27 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Oct 2013 22:20:27 -0700 Subject: RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 In-Reply-To: References: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> Message-ID: Thanks, John! igor On Oct 22, 2013, at 10:06 PM, John Rose wrote: > On Oct 22, 2013, at 8:18 PM, Igor Veresov wrote: > >> A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit. >> Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8026495/ >> >> Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress > > That's some technical debt there. Thanks for shoveling through it. Perhaps there's more, but this is a good barrow load to wheel away. > > The biggest surprise was type2spill_size. Wasn't that thing raising warnings since the no-permgen rewrite? > > Your use of rbx looks OK, but I wish there were a way to assert what you comment about it, that all the C compilers refrain from blowing it. Seems like something that could go wrong later. I looked around for something to grab; nothing in assembler_x86.hpp where the C calling conventions are surveyed, but perhaps we could put something there some day. The *.ad files have the info, but it's hard to get at. > > Anyway, reviewed. > > ? John > > P.S. I personally don't mind stacked NOT_FOO/FOO_ONLY macros if their bodies are tiny and that there are not larger changes nearby. From vladimir.kozlov at oracle.com Tue Oct 22 22:23:30 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Oct 2013 01:23:30 -0400 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <20131022135921.GG13244@rbackman> References: <20131018093454.GC17703@rbackman> <526158D2.8080601@oracle.com> <20131022135921.GG13244@rbackman> Message-ID: <2E6DE6D6-ADE5-4F37-AE17-4EC2158220BA@oracle.com> I read this mail after I responded to other one. About shared nodes. Yes, loads are always shared and as result we can not combine them with Exact nodes which also shared, as you noticed. But not marking Exact nodes as shared is incorrect because they produce flags. So for these changes I would suggest to leave it without matching exact(reg, mem) version of Mach nodes. We can do additional optimizations later. Thanks, Vladimir > On Oct 22, 2013, at 9:59 AM, Rickard B?ckman wrote: > > Vladimir, > > new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ > The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ > (Forgot to add x86_32.ad to that one though). > > The reason I didn't implement mulexact(reg, mem) was that we didn't have > imull and imulq for (reg, mem). I've added those now. > I also noticed that we never generated *Exact(reg, mem) because of a > problem in Matcher::find_shared. Since the *Exact nodes have two > outputs all inputs of *Exact will be marked as shared. I decided to > only push the *Exact-node for the Result unless only the FlagsProj > is used. > > Thanks > >> On 10/18, Vladimir Kozlov wrote: >> Rickard, >> >> is_MathExactOpcode() could be replaced by adding the node to >> DEFINE_CLASS_ID structure as you did with FlagsProj. is_MathExact() >> will be true for all its subclasses. >> >> Put MathExactNode() constructors together. >> >> In library_call.cpp can you name Integer version of method with I: >> inline_math_addExactI() to be symmetrical with Long version. And I >> don't think you need separate methods for increment and decrement - >> path flag to add and sub method. >> >> Why you did not implement mulexact(reg, mem) mach nodes? >> >> Otherwise it is good. >> >> Thanks, >> Vladimir >> >>> On 10/18/13 2:34 AM, Rickard B?ckman wrote: >>> Hi, can I get reviews for the following change: >>> >>> This change creates intrinsics for addExact(long, long), subtractExact, >>> negateExact, incrementExact, decrementExact and multiplyExact. >>> >>> The intrinsics are only added on x86 and only 64-bit has the intrinsics >>> for the long-versions. (32-bit only has int-versions). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 >>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ >>> >>> Thanks >>> /R > /R From christian.thalinger at oracle.com Tue Oct 22 22:50:26 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 22 Oct 2013 22:50:26 -0700 Subject: RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 In-Reply-To: <2A138BBF-F333-4EFD-BFC6-C94DFCB2F941@oracle.com> References: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> <2A138BBF-F333-4EFD-BFC6-C94DFCB2F941@oracle.com> Message-ID: On Oct 22, 2013, at 9:35 PM, Igor Veresov wrote: > > On Oct 22, 2013, at 8:33 PM, Christian Thalinger wrote: > >> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: >> + #ifdef _LP64 >> + Register thread = r15_thread; >> + #else >> __ get_thread(rsi); >> ! __ movptr(rax, Address(rsi, JavaThread::exception_oop_offset())); >> __ movptr(Address(rsi, JavaThread::exception_oop_offset()), (intptr_t)NULL_WORD); >> ! __ movptr(Address(rsi, JavaThread::exception_pc_offset()), (intptr_t)NULL_WORD); >> ! Register thread = rsi; >> + #endif >> I'd prefer using LP64_ONLY and NOT_LP64 on one line. > > There is get_thread() on 32bit, it's not going to be one line. But I agree it's better looking. > Review updated in-place. > >> >> src/share/vm/c1/c1_LIRGenerator.cpp: >> if (x->pass_thread()) { >> ! signature->append(T_ADDRESS); >> ! signature->append(LP64_ONLY(T_LONG) NOT_LP64(T_INT)); // thread >> args->append(getThreadPointer()); >> } >> Why can it not be T_ADDRESS? > > It can, but getThreadPointer() returns either T_INT or T_LONG (probably historically) and I'd like it to be consistent. > Speaking of T_ADDRESS, this change also fixes the size of the T_ADDRESS spill, which was always 4 bytes. I see. Makes sense then. Looks good. > > igor > > >> >> On Oct 22, 2013, at 8:18 PM, Igor Veresov wrote: >> >>> A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit. >>> Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8026495/ >>> >>> Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress >>> >>> igor >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/daacc9de/attachment.html From igor.veresov at oracle.com Tue Oct 22 22:51:13 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 22 Oct 2013 22:51:13 -0700 Subject: RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 In-Reply-To: References: <100335E4-F660-40E0-8B9A-B2B0227CF6AB@oracle.com> <2A138BBF-F333-4EFD-BFC6-C94DFCB2F941@oracle.com> Message-ID: <6E8BC8BF-3615-4860-B47F-E062FEA35B8D@oracle.com> Thanks, Chris! On Oct 22, 2013, at 10:50 PM, Christian Thalinger wrote: > > On Oct 22, 2013, at 9:35 PM, Igor Veresov wrote: > >> >> On Oct 22, 2013, at 8:33 PM, Christian Thalinger wrote: >> >>> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: >>> + #ifdef _LP64 >>> + Register thread = r15_thread; >>> + #else >>> __ get_thread(rsi); >>> ! __ movptr(rax, Address(rsi, JavaThread::exception_oop_offset())); >>> __ movptr(Address(rsi, JavaThread::exception_oop_offset()), (intptr_t)NULL_WORD); >>> ! __ movptr(Address(rsi, JavaThread::exception_pc_offset()), (intptr_t)NULL_WORD); >>> ! Register thread = rsi; >>> + #endif >>> I'd prefer using LP64_ONLY and NOT_LP64 on one line. >> >> There is get_thread() on 32bit, it's not going to be one line. But I agree it's better looking. >> Review updated in-place. >> >>> >>> src/share/vm/c1/c1_LIRGenerator.cpp: >>> if (x->pass_thread()) { >>> ! signature->append(T_ADDRESS); >>> ! signature->append(LP64_ONLY(T_LONG) NOT_LP64(T_INT)); // thread >>> args->append(getThreadPointer()); >>> } >>> Why can it not be T_ADDRESS? >> >> It can, but getThreadPointer() returns either T_INT or T_LONG (probably historically) and I'd like it to be consistent. >> Speaking of T_ADDRESS, this change also fixes the size of the T_ADDRESS spill, which was always 4 bytes. > > I see. Makes sense then. Looks good. > >> >> igor >> >> >>> >>> On Oct 22, 2013, at 8:18 PM, Igor Veresov wrote: >>> >>>> A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit. >>>> Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8026495/ >>>> >>>> Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress >>>> >>>> igor >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/4b9f4277/attachment.html From vladimir.kozlov at oracle.com Tue Oct 22 22:54:34 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Oct 2013 01:54:34 -0400 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> Message-ID: Roland, AddP node has 3 edges, you need to set both Address and Base to new obj. There is graphKit::basic_plus_adr(ptr, offset) method which you can use to generate new addP node. Other changes look fine. Thanks, Vladimir > On Oct 21, 2013, at 4:10 PM, Roland Westrelin wrote: > > Here is a new webrev that should address all comments: > > http://cr.openjdk.java.net/~roland/8024070/webrev.02/ > > Roland. > > >> On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: >> >> Roland, >> >> I looked on whole changes. >> >> Please, switch off UseTypeSpeculation by default as we discussed. >> >> I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. >> >> ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": >> >> + // Return true if profiling provides a type for the argument nb to the >> >> I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. >> >> It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. >> >> compile.cpp next comment is wrong since you keep using CastPP nodes: >> >> + // Remove the speculative part of types and clean up the graph from >> + // the extra CheckCastPP nodes whose only purpose is to carry >> + // them. Do that early so that optimizations are not disrupted by >> + // the extra CheckCastPP nodes. >> >> 'tmp' is not good name for a 'list': >> + Unique_Node_List tmp; >> >> Split next line: >> >> + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { >> >> >> doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). >> >> graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. >> >> library_call.cpp split next line: >> >> + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); >> >> >> parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. >> >> Thanks, >> Vladimir >> >>> On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >>> Roland, >>> >>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>> correctly if klass() == tap->klass() >>> >>> Lets leave NULL for now because in general meet(con, bot) = bot. It may >>> change code generation more then other changes and we don't want it now. >>> >>>> >>>> I've been trying to write simple tests to reproduce those failures >>> without much success. Any suggestion what simple java code I can write >>> to have something of ptr type AnyNull? >>> >>> AnyNull is ptr_dual for NotNull. Meets with it is checked in >>> Type::meet(). So it should work for tests only with NotNull. >>> >>> Vladimir >>> >>>> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>>> Hi Vladimir, >>>> >>>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>>> wrote: >>>> >>>>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>>> Here is a new webrev for this: >>>>>> >>>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>>> >>>>>> I applied your suggestions below. >>>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>>> profiling data that we use right away so reusing profiling for this, >>>>>> I find confusing. >>>>> >>>>> Okay. >>>>> >>>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>>> problems that need investigation. I did extensive testing with the >>>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>>> >>>>> Yes, it is fine. >>>>> >>>>>> >>>>>> type.cpp has several generic type system fixes: >>>>>> >>>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>>> !klass_is_exact()) { >>>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>>> 3186 } else { >>>>> >>>>> Looks correct but, please, make sure it works for multi-dimensional >>>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>>> that sometimes exact Object klass may be not really exact. >>>> >>>> Ok. >>>> >>>>> >>>>>> >>>>>> mimics what we do for instance klass with subclass/superclass when >>>>>> both subclass and superclass are exact >>>>>> >>>>>> 3315 if( this_klass->is_interface() && >>>>>> !(tinst_klass->is_interface() || >>>>>> 3316 tinst_klass == >>>>>> ciEnv::current()->Object_klass())) { >>>>>> >>>>>> is required because otherwise if tinst_klass is of an object class, >>>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>>> this->_ptr and tinst->_ptr which were not swapped. >>>>> >>>>> Seems reasonable. >>>>> >>>>>> >>>>>> I also had to make the cases: >>>>>> >>>>>> 3818 case AnyNull: >>>>>> 3819 case TopPTR: >>>>>> >>>>>> and >>>>>> >>>>>> 3847 case NotNull: >>>>>> 3848 case BotPTR: >>>>>> >>>>>> symmetrical which they are not currently. >>>>> >>>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>>> place (it was always false). >>>>> With your changes the code is still not symmetrical. I think in last >>>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>>> const_oop() to constructor. This is what we do when tap is Const and >>>>> 'this' is below. >>>> >>>> Wouldn't this be sufficient as a fix? >>>> >>>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>>> --- a/src/share/vm/opto/type.cpp >>>> +++ b/src/share/vm/opto/type.cpp >>>> @@ -3851,7 +3851,7 @@ >>>> xk = tap->_klass_is_exact; >>>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>>> (klass() == tap->klass()); // Only precise for >>>> identical arrays >>>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>>> instance_id, speculative); >>>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>>> lazy_klass, xk, off, instance_id, speculative); >>>> default: ShouldNotReachHere(); >>>> } >>>> } >>>> >>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>> correctly if klass() == tap->klass() >>>> >>>> I've been trying to write simple tests to reproduce those failures >>>> without much success. Any suggestion what simple java code I can write >>>> to have something of ptr type AnyNull? >>>> >>>> Thanks, >>>> Roland. >>>> >>>>> >>>>> I need to look on whole changes later. I will send additional comments. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Roland. >>>>>> >>>>>>> General notes: >>>>>>> >>>>>>> I think 'speculative' is not right word. We get these types from >>>>>>> profiling when we see only one type. And we use it only after >>>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>>> it comes from. Or other more appropriate name. >>>>>>> >>>>>>> You need to add jtreg tests to verify these changes for different >>>>>>> cases (especially merge points with different profile types). >>>>>>> >>>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>>> Phi nodes and further anyway. >>>>>>> >>>>>>> Small notes: >>>>>>> >>>>>>> c2_globals.hpp: >>>>>>> >>>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>>> >>>>>>> drop_speculative* --> remove_speculative* >>>>>>> >>>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>>> for last parameters. >>>>>>> >>>>>>> In a lot of places you use: >>>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>>> >>>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>>> use in such cases. >>>>>>> >>>>>>> library_call.cpp: typo: >>>>>>> >>>>>>> ciKlass* src_k, *dest_k; >>>>>>> ^ >>>>>>> regards, >>>>>>> Vladimir >>>>>>> >>>>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>>> Roland, >>>>>>>> >>>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>>> Regression could be also caused by different inlining >>>>>>>> (InlineSmallCode) >>>>>>>> because more uncommon traps are generated. >>>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>>> am also >>>>>>>> looking on your extra type profiling changes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>>> Always >>>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>>> more >>>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>>> it is. >>>>>>>>>> >>>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>>> It's >>>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>>> experiment >>>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>>> impact we >>>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>>> method >>>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>>> >>>>>>>>> This is the kind of results I get with nashorn: >>>>>>>>> deltablue: >>>>>>>>> current: 2345 >>>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>>> >>>>>>>>> RayTrace: >>>>>>>>> current: 1978 >>>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>>> >>>>>>>>> Richards: >>>>>>>>> current: 2222 >>>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>>> >>>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>>> method of the compilation >>>>>>>>> - type check on return from non inlined calls >>>>>>>>> >>>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>>> benchmarks: >>>>>>>>> >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> t >>>>>>>>> Benchmark Samples Mean Stdev >>>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>>> javac 10 385.70 0.05 >>>>>>>>> db 10 444.51 0.01 >>>>>>>>> jess 10 699.05 0.00 >>>>>>>>> jack 10 603.98 0.01 >>>>>>>>> compress 10 534.99 0.01 >>>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> t2 >>>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>>> Significant >>>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>>> 0.014 * >>>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>>> 0.013 * >>>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>>> 0.875 * >>>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>>> 0.000 Yes >>>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>>> 0.425 * >>>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>>> 0.329 * >>>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>>> 0.181 * >>>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>>> 0.001 Yes >>>>>>>>> ============================================================================ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Roland. > From rickard.backman at oracle.com Tue Oct 22 22:56:09 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 23 Oct 2013 07:56:09 +0200 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <2E6DE6D6-ADE5-4F37-AE17-4EC2158220BA@oracle.com> References: <20131018093454.GC17703@rbackman> <526158D2.8080601@oracle.com> <20131022135921.GG13244@rbackman> <2E6DE6D6-ADE5-4F37-AE17-4EC2158220BA@oracle.com> Message-ID: <20131023055609.GI13244@rbackman> Vladimir, thanks for looking at this. I'll remove the part from matcher.cpp then. On 10/23, Vladimir Kozlov wrote: > I read this mail after I responded to other one. > About shared nodes. Yes, loads are always shared and as result we can not combine them with Exact nodes which also shared, as you noticed. But not marking Exact nodes as shared is incorrect because they produce flags. So for these changes I would suggest to leave it without matching exact(reg, mem) version of Mach nodes. We can do additional optimizations later. > > Thanks, > Vladimir > > > On Oct 22, 2013, at 9:59 AM, Rickard B?ckman wrote: > > > > Vladimir, > > > > new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ > > The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ > > (Forgot to add x86_32.ad to that one though). > > > > The reason I didn't implement mulexact(reg, mem) was that we didn't have > > imull and imulq for (reg, mem). I've added those now. > > I also noticed that we never generated *Exact(reg, mem) because of a > > problem in Matcher::find_shared. Since the *Exact nodes have two > > outputs all inputs of *Exact will be marked as shared. I decided to > > only push the *Exact-node for the Result unless only the FlagsProj > > is used. > > > > Thanks > > > >> On 10/18, Vladimir Kozlov wrote: > >> Rickard, > >> > >> is_MathExactOpcode() could be replaced by adding the node to > >> DEFINE_CLASS_ID structure as you did with FlagsProj. is_MathExact() > >> will be true for all its subclasses. > >> > >> Put MathExactNode() constructors together. > >> > >> In library_call.cpp can you name Integer version of method with I: > >> inline_math_addExactI() to be symmetrical with Long version. And I > >> don't think you need separate methods for increment and decrement - > >> path flag to add and sub method. > >> > >> Why you did not implement mulexact(reg, mem) mach nodes? > >> > >> Otherwise it is good. > >> > >> Thanks, > >> Vladimir > >> > >>> On 10/18/13 2:34 AM, Rickard B?ckman wrote: > >>> Hi, can I get reviews for the following change: > >>> > >>> This change creates intrinsics for addExact(long, long), subtractExact, > >>> negateExact, incrementExact, decrementExact and multiplyExact. > >>> > >>> The intrinsics are only added on x86 and only 64-bit has the intrinsics > >>> for the long-versions. (32-bit only has int-versions). > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > >>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > >>> > >>> Thanks > >>> /R > > /R /R From albert.noll at oracle.com Wed Oct 23 00:45:49 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 23 Oct 2013 09:45:49 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> References: <5266CF8C.70305@oracle.com> <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> Message-ID: <52677EAD.7000007@oracle.com> Hi Chris, thanks for catching this. The test is not correct, since the output we want to check is not written to stdout. This patch should be fine. http://cr.openjdk.java.net/~anoll/8026949/webrev.03/ Best, Albert On 23.10.2013 02:45, Christian Thalinger wrote: > 44 // Check that the outputs are equal > 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { > Is this testing the full output or only the first line? Because the > outputs are not equal: > > $ java -Xint -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, > interpreted mode) > > $ java -Xcomp -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, > compiled mode) > > > On Oct 22, 2013, at 12:18 PM, Albert Noll > wrote: > >> Hi, >> >> sure, here is the patch including the test: >> >> http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ >> >> >> Best, >> Albert >> >> On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >>> Albert, please add a jtreg test for this change. I think it is very >>> easy: just start 'java -version' as a external process and check its >>> output in 'Xint' and '-Xcomp' cases. If you don't think so, please >>> file a RFE to add regression test and assign it to me. >>> >>> Thanks. >>> - Igor >>> >>> ----- Reply message ----- >>> From: "Albert Noll" >>> To: "Igor Veresov" >>> Cc: "hotspot-compiler-dev at openjdk.java.net" >>> >>> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: >>> Initialization of C1 thread failed (no space to run compilers) >>> Date: Tue, Oct 22, 2013 22:03 >>> >>> Roland, Igor, thanks for looking at this. >>> >>> I tested the patch as follows: >>> >>> java -Xint -version .. make sure that output does not appear >>> java -Xcomp -version make sure that compiler(s) are working >>> >>> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint >>> and -Xcomp and -Xmixed) >>> >>> Seems to work fine. >>> >>> Best, >>> Albert >>> >>> On 22.10.2013 19:12, Igor Veresov wrote: >>>> Looks good. >>>> >>>> igor >>>> >>>> On Oct 22, 2013, at 6:15 AM, Albert Noll >>> > wrote: >>>> >>>>> Thanks Igor. This is a good solution. >>>>> >>>>> Here is the webrev: >>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>>> >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>>> Another trivial fix option is to just bail out >>>>>> of CompileBroker::compilation_init() is UseCompiler is false. To >>>>>> avoid initializing the compiler objects and all.. >>>>>> >>>>>> igor >>>>>> >>>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>>>> > wrote: >>>>>> >>>>>>> Christian, Igor, thanks for the reviews. >>>>>>> >>>>>>> There seems to be an ambiguity between -Xint and >>>>>>> -XX:+UseCompiler. Whether we use a compiler or >>>>>>> not, depends on the order in which the arguments are given. I am >>>>>>> not exactly sure why we have >>>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>>> >>>>>>> The reason why I added the checks when we determine the number >>>>>>> of compiler threads is that we >>>>>>> do not generate the compiler objects (they are not needed). >>>>>>> Also, the number of compiler threads >>>>>>> is set correctly. >>>>>>> >>>>>>> The solution proposed by Igor is simpler. If the above issues do >>>>>>> not matter, I would also opt for the >>>>>>> simple solution. >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>>> If think you can just use the existing "UseCompiler" flag, that >>>>>>>> we set to false when -Xint is specified and just not call >>>>>>>> init_compiler_threads() if UseCompiler == false. >>>>>>>> >>>>>>>> igor >>>>>>>> >>>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I have reviews for this small patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of >>>>>>>>> C1 thread failed (no space to run compilers) when the VM is >>>>>>>>> started >>>>>>>>> with -Xint >>>>>>>>> >>>>>>>>> Solution: Do not start compiler threads if VM is started with >>>>>>>>> -Xint >>>>>>>>> >>>>>>>>> Testing: -Xint flag does not print out the false warning. >>>>>>>>> Tested flag combinations: >>>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>>> >>>>>>>>> >>>>>>>>> Many thanks in advance, >>>>>>>>> Albert >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131023/0a9c4979/attachment-0001.html From igor.ignatyev at oracle.com Wed Oct 23 00:48:35 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Oct 2013 11:48:35 +0400 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> References: <5266CF8C.70305@oracle.com> <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> Message-ID: <52677F53.4020309@oracle.com> > Is this testing the full output or only the first line? full output, but '-version' by default uses stderr, so stdouts should be empty and equal. I think it would be better to add vm flags to explicitly use of stdout for warnings -- -XX:+DisplayVMOutputToStdout. Best regards, Igor Ignatyev On 10/23/2013 04:45 AM, Christian Thalinger wrote: > 44 // Check that the outputs are equal > 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { > > Is this testing the full output or only the first line? Because the > outputs are not equal: > > $ java -Xint -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, > interpreted mode) > > $ java -Xcomp -version > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, > compiled mode) > > > On Oct 22, 2013, at 12:18 PM, Albert Noll > wrote: > >> Hi, >> >> sure, here is the patch including the test: >> >> http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ >> >> >> Best, >> Albert >> >> On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >>> Albert, please add a jtreg test for this change. I think it is very >>> easy: just start 'java -version' as a external process and check its >>> output in 'Xint' and '-Xcomp' cases. If you don't think so, please >>> file a RFE to add regression test and assign it to me. >>> >>> Thanks. >>> - Igor >>> >>> ----- Reply message ----- >>> From: "Albert Noll" >>> To: "Igor Veresov" >>> Cc: "hotspot-compiler-dev at openjdk.java.net" >>> >>> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: >>> Initialization of C1 thread failed (no space to run compilers) >>> Date: Tue, Oct 22, 2013 22:03 >>> >>> Roland, Igor, thanks for looking at this. >>> >>> I tested the patch as follows: >>> >>> java -Xint -version .. make sure that output does not appear >>> java -Xcomp -version make sure that compiler(s) are working >>> >>> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and >>> -Xcomp and -Xmixed) >>> >>> Seems to work fine. >>> >>> Best, >>> Albert >>> >>> On 22.10.2013 19:12, Igor Veresov wrote: >>>> Looks good. >>>> >>>> igor >>>> >>>> On Oct 22, 2013, at 6:15 AM, Albert Noll >>> > wrote: >>>> >>>>> Thanks Igor. This is a good solution. >>>>> >>>>> Here is the webrev: >>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>>> >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>>> Another trivial fix option is to just bail out >>>>>> of CompileBroker::compilation_init() is UseCompiler is false. To >>>>>> avoid initializing the compiler objects and all.. >>>>>> >>>>>> igor >>>>>> >>>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>>>> > wrote: >>>>>> >>>>>>> Christian, Igor, thanks for the reviews. >>>>>>> >>>>>>> There seems to be an ambiguity between -Xint and >>>>>>> -XX:+UseCompiler. Whether we use a compiler or >>>>>>> not, depends on the order in which the arguments are given. I am >>>>>>> not exactly sure why we have >>>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>>> >>>>>>> The reason why I added the checks when we determine the number of >>>>>>> compiler threads is that we >>>>>>> do not generate the compiler objects (they are not needed). Also, >>>>>>> the number of compiler threads >>>>>>> is set correctly. >>>>>>> >>>>>>> The solution proposed by Igor is simpler. If the above issues do >>>>>>> not matter, I would also opt for the >>>>>>> simple solution. >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>>> If think you can just use the existing "UseCompiler" flag, that >>>>>>>> we set to false when -Xint is specified and just not call >>>>>>>> init_compiler_threads() if UseCompiler == false. >>>>>>>> >>>>>>>> igor >>>>>>>> >>>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I have reviews for this small patch? >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of >>>>>>>>> C1 thread failed (no space to run compilers) when the VM is started >>>>>>>>> with -Xint >>>>>>>>> >>>>>>>>> Solution: Do not start compiler threads if VM is started with -Xint >>>>>>>>> >>>>>>>>> Testing: -Xint flag does not print out the false warning. >>>>>>>>> Tested flag combinations: >>>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>>> >>>>>>>>> >>>>>>>>> Many thanks in advance, >>>>>>>>> Albert >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From albert.noll at oracle.com Wed Oct 23 01:15:41 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 23 Oct 2013 10:15:41 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <52677F53.4020309@oracle.com> References: <5266CF8C.70305@oracle.com> <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> <52677F53.4020309@oracle.com> Message-ID: <526785AD.60506@oracle.com> Hi Igor, are you fine with the lastest version, or should I add the -XX:+DisplayVMOutputToStdout to the test? Best, Albert On 23.10.2013 09:48, Igor Ignatyev wrote: > > Is this testing the full output or only the first line? > full output, but '-version' by default uses stderr, so stdouts should > be empty and equal. > I think it would be better to add vm flags to explicitly use of stdout > for warnings -- -XX:+DisplayVMOutputToStdout. > > Best regards, > Igor Ignatyev > > On 10/23/2013 04:45 AM, Christian Thalinger wrote: >> 44 // Check that the outputs are equal >> 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { >> >> Is this testing the full output or only the first line? Because the >> outputs are not equal: >> >> $ java -Xint -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >> interpreted mode) >> >> $ java -Xcomp -version >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >> compiled mode) >> >> >> On Oct 22, 2013, at 12:18 PM, Albert Noll > > wrote: >> >>> Hi, >>> >>> sure, here is the patch including the test: >>> >>> http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ >>> >>> >>> Best, >>> Albert >>> >>> On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >>>> Albert, please add a jtreg test for this change. I think it is very >>>> easy: just start 'java -version' as a external process and check its >>>> output in 'Xint' and '-Xcomp' cases. If you don't think so, please >>>> file a RFE to add regression test and assign it to me. >>>> >>>> Thanks. >>>> - Igor >>>> >>>> ----- Reply message ----- >>>> From: "Albert Noll" >>>> To: "Igor Veresov" >>>> Cc: "hotspot-compiler-dev at openjdk.java.net" >>>> >>>> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: >>>> Initialization of C1 thread failed (no space to run compilers) >>>> Date: Tue, Oct 22, 2013 22:03 >>>> >>>> Roland, Igor, thanks for looking at this. >>>> >>>> I tested the patch as follows: >>>> >>>> java -Xint -version .. make sure that output does not appear >>>> java -Xcomp -version make sure that compiler(s) are working >>>> >>>> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and >>>> -Xcomp and -Xmixed) >>>> >>>> Seems to work fine. >>>> >>>> Best, >>>> Albert >>>> >>>> On 22.10.2013 19:12, Igor Veresov wrote: >>>>> Looks good. >>>>> >>>>> igor >>>>> >>>>> On Oct 22, 2013, at 6:15 AM, Albert Noll >>>> > wrote: >>>>> >>>>>> Thanks Igor. This is a good solution. >>>>>> >>>>>> Here is the webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>>>> >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>>>> Another trivial fix option is to just bail out >>>>>>> of CompileBroker::compilation_init() is UseCompiler is false. To >>>>>>> avoid initializing the compiler objects and all.. >>>>>>> >>>>>>> igor >>>>>>> >>>>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>>>>> > wrote: >>>>>>> >>>>>>>> Christian, Igor, thanks for the reviews. >>>>>>>> >>>>>>>> There seems to be an ambiguity between -Xint and >>>>>>>> -XX:+UseCompiler. Whether we use a compiler or >>>>>>>> not, depends on the order in which the arguments are given. I am >>>>>>>> not exactly sure why we have >>>>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>>>> >>>>>>>> The reason why I added the checks when we determine the number of >>>>>>>> compiler threads is that we >>>>>>>> do not generate the compiler objects (they are not needed). Also, >>>>>>>> the number of compiler threads >>>>>>>> is set correctly. >>>>>>>> >>>>>>>> The solution proposed by Igor is simpler. If the above issues do >>>>>>>> not matter, I would also opt for the >>>>>>>> simple solution. >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>>>> If think you can just use the existing "UseCompiler" flag, that >>>>>>>>> we set to false when -Xint is specified and just not call >>>>>>>>> init_compiler_threads() if UseCompiler == false. >>>>>>>>> >>>>>>>>> igor >>>>>>>>> >>>>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> could I have reviews for this small patch? >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of >>>>>>>>>> C1 thread failed (no space to run compilers) when the VM is >>>>>>>>>> started >>>>>>>>>> with -Xint >>>>>>>>>> >>>>>>>>>> Solution: Do not start compiler threads if VM is started with >>>>>>>>>> -Xint >>>>>>>>>> >>>>>>>>>> Testing: -Xint flag does not print out the false warning. >>>>>>>>>> Tested flag combinations: >>>>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Many thanks in advance, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From niclas.adlertz at oracle.com Wed Oct 23 02:00:39 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Wed, 23 Oct 2013 11:00:39 +0200 Subject: RFR(XS) 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL In-Reply-To: <964BAA72-4A00-4AC2-A87D-A6FBE2605B02@oracle.com> References: <52653576.8020600@oracle.com> <6E06E430-9897-40EB-98ED-72A2FB46B9C1@oracle.com> <526646DB.5020206@oracle.com> <964BAA72-4A00-4AC2-A87D-A6FBE2605B02@oracle.com> Message-ID: <52679037.8070005@oracle.com> Thanks Chris. Kind Regards, Niclas Adlertz On 2013-10-23 02:20, Christian Thalinger wrote: > > On Oct 22, 2013, at 2:35 AM, Niclas Adlertz wrote: > >> CTW and JPRT doesn't trigger this (that's why it was pushed unnoticed). >> However, I have tested 'java/lang/Character/CheckScript.java' with this fix and it now works. >> >> (java/lang/Character/CheckScript.java was a failing test in nightlies) > > Okay. Looks good. > >> >> Kind Regards, >> Niclas Adlertz >> >> On 2013-10-22 05:27, Christian Thalinger wrote: >>> What testing did you do? >>> >>> On Oct 21, 2013, at 7:08 AM, Niclas Adlertz wrote: >>> >>>> Hi all, >>>> >>>> Now that more nodes can be rematerialized due to fix JDK-8022783, a rematerialized node can have a spilled live range as input even when rematerializing input for phi nodes (in the Phi Node Splitting pass). >>>> Prior to the JDK-8013830 and JDK-8005956 fixes, the Reachblock pointer could be wrong (hence the warning in JDK-8013830). Now, we pass in the correct block-reaches, i.e. the reaches for the 'pred' block. >>>> >>>> Kind Regards, >>>> Niclas Adlertz >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8026939 >>>> WEBREV: cr.openjdk.net is down so I'm pasting the diff here: >>>> >>>> diff -r 52575a17a36c src/share/vm/opto/reg_split.cpp >>>> --- a/src/share/vm/opto/reg_split.cpp Mon Oct 21 09:21:41 2013 +0400 >>>> +++ b/src/share/vm/opto/reg_split.cpp Mon Oct 21 15:34:42 2013 +0200 >>>> @@ -365,7 +365,6 @@ >>>> } >>>> if (lidx < _lrg_map.max_lrg_id() && lrgs(lidx).reg() >= LRG::SPILL_REG) { >>>> - assert(Reachblock != NULL, "Reachblock must be non-NULL"); >>>> Node *rdef = Reachblock[lrg2reach[lidx]]; >>>> if (rdef) { >>>> spill->set_req(i, rdef); >>>> @@ -476,7 +475,6 @@ >>>> uint bidx, pidx, slidx, insidx, inpidx, twoidx; >>>> uint non_phi = 1, spill_cnt = 0; >>>> - Node **Reachblock; >>>> Node *n1, *n2, *n3; >>>> Node_List *defs,*phis; >>>> bool *UPblock; >>>> @@ -559,7 +557,7 @@ >>>> b = _cfg.get_block(bidx); >>>> // Reaches & UP arrays for this block >>>> - Reachblock = Reaches[b->_pre_order]; >>>> + Node** Reachblock = Reaches[b->_pre_order]; >>>> UPblock = UP[b->_pre_order]; >>>> // Reset counter of start of non-Phi nodes in block >>>> non_phi = 1; >>>> @@ -1315,6 +1313,7 @@ >>>> pidx = pred->_pre_order; >>>> // Grab reaching def >>>> Node *def = Reaches[pidx][slidx]; >>>> + Node** Reachblock = Reaches[pidx]; >>>> assert( def, "must have reaching def" ); >>>> // If input up/down sense and reg-pressure DISagree >>>> if (def->rematerialize()) { >>>> @@ -1327,8 +1326,7 @@ >>>> _lrg_map.find(pred->get_node(insert - 1)) >= lrgs_before_phi_split) { >>>> insert--; >>>> } >>>> - // since the def cannot contain any live range input, we can pass in NULL as Reachlock parameter >>>> - def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, NULL, false); >>>> + def = split_Rematerialize(def, pred, insert, maxlrg, splits, slidx, lrg2reach, Reachblock, false); >>>> if (!def) { >>>> return 0; // Bail out >>>> } >>> >> > From igor.veresov at oracle.com Wed Oct 23 02:25:46 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 23 Oct 2013 02:25:46 -0700 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <526785AD.60506@oracle.com> References: <5266CF8C.70305@oracle.com> <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> <52677F53.4020309@oracle.com> <526785AD.60506@oracle.com> Message-ID: <130D94A0-9879-4A61-9611-0E2223C89999@oracle.com> I think the latest version is fine. igor On Oct 23, 2013, at 1:15 AM, Albert Noll wrote: > Hi Igor, > > are you fine with the lastest version, or should I add the -XX:+DisplayVMOutputToStdout to the test? > > Best, > Albert > > On 23.10.2013 09:48, Igor Ignatyev wrote: >> > Is this testing the full output or only the first line? >> full output, but '-version' by default uses stderr, so stdouts should be empty and equal. >> I think it would be better to add vm flags to explicitly use of stdout for warnings -- -XX:+DisplayVMOutputToStdout. >> >> Best regards, >> Igor Ignatyev >> >> On 10/23/2013 04:45 AM, Christian Thalinger wrote: >>> 44 // Check that the outputs are equal >>> 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { >>> >>> Is this testing the full output or only the first line? Because the >>> outputs are not equal: >>> >>> $ java -Xint -version >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >>> interpreted mode) >>> >>> $ java -Xcomp -version >>> java version "1.8.0-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >>> compiled mode) >>> >>> >>> On Oct 22, 2013, at 12:18 PM, Albert Noll >> > wrote: >>> >>>> Hi, >>>> >>>> sure, here is the patch including the test: >>>> >>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ >>>> >>>> >>>> Best, >>>> Albert >>>> >>>> On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >>>>> Albert, please add a jtreg test for this change. I think it is very >>>>> easy: just start 'java -version' as a external process and check its >>>>> output in 'Xint' and '-Xcomp' cases. If you don't think so, please >>>>> file a RFE to add regression test and assign it to me. >>>>> >>>>> Thanks. >>>>> - Igor >>>>> >>>>> ----- Reply message ----- >>>>> From: "Albert Noll" >>>>> To: "Igor Veresov" >>>>> Cc: "hotspot-compiler-dev at openjdk.java.net" >>>>> >>>>> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: >>>>> Initialization of C1 thread failed (no space to run compilers) >>>>> Date: Tue, Oct 22, 2013 22:03 >>>>> >>>>> Roland, Igor, thanks for looking at this. >>>>> >>>>> I tested the patch as follows: >>>>> >>>>> java -Xint -version .. make sure that output does not appear >>>>> java -Xcomp -version make sure that compiler(s) are working >>>>> >>>>> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and >>>>> -Xcomp and -Xmixed) >>>>> >>>>> Seems to work fine. >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 22.10.2013 19:12, Igor Veresov wrote: >>>>>> Looks good. >>>>>> >>>>>> igor >>>>>> >>>>>> On Oct 22, 2013, at 6:15 AM, Albert Noll >>>>> > wrote: >>>>>> >>>>>>> Thanks Igor. This is a good solution. >>>>>>> >>>>>>> Here is the webrev: >>>>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>>>>> Another trivial fix option is to just bail out >>>>>>>> of CompileBroker::compilation_init() is UseCompiler is false. To >>>>>>>> avoid initializing the compiler objects and all.. >>>>>>>> >>>>>>>> igor >>>>>>>> >>>>>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Christian, Igor, thanks for the reviews. >>>>>>>>> >>>>>>>>> There seems to be an ambiguity between -Xint and >>>>>>>>> -XX:+UseCompiler. Whether we use a compiler or >>>>>>>>> not, depends on the order in which the arguments are given. I am >>>>>>>>> not exactly sure why we have >>>>>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>>>>> >>>>>>>>> The reason why I added the checks when we determine the number of >>>>>>>>> compiler threads is that we >>>>>>>>> do not generate the compiler objects (they are not needed). Also, >>>>>>>>> the number of compiler threads >>>>>>>>> is set correctly. >>>>>>>>> >>>>>>>>> The solution proposed by Igor is simpler. If the above issues do >>>>>>>>> not matter, I would also opt for the >>>>>>>>> simple solution. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>>>>> If think you can just use the existing "UseCompiler" flag, that >>>>>>>>>> we set to false when -Xint is specified and just not call >>>>>>>>>> init_compiler_threads() if UseCompiler == false. >>>>>>>>>> >>>>>>>>>> igor >>>>>>>>>> >>>>>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> could I have reviews for this small patch? >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of >>>>>>>>>>> C1 thread failed (no space to run compilers) when the VM is started >>>>>>>>>>> with -Xint >>>>>>>>>>> >>>>>>>>>>> Solution: Do not start compiler threads if VM is started with -Xint >>>>>>>>>>> >>>>>>>>>>> Testing: -Xint flag does not print out the false warning. >>>>>>>>>>> Tested flag combinations: >>>>>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Many thanks in advance, >>>>>>>>>>> Albert >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From albert.noll at oracle.com Wed Oct 23 02:46:54 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 23 Oct 2013 11:46:54 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <130D94A0-9879-4A61-9611-0E2223C89999@oracle.com> References: <5266CF8C.70305@oracle.com> <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> <52677F53.4020309@oracle.com> <526785AD.60506@oracle.com> <130D94A0-9879-4A61-9611-0E2223C89999@oracle.com> Message-ID: <52679B0E.1000404@oracle.com> Thank you, Igor! Best, Albert On 23.10.2013 11:25, Igor Veresov wrote: > I think the latest version is fine. > > igor > > On Oct 23, 2013, at 1:15 AM, Albert Noll wrote: > >> Hi Igor, >> >> are you fine with the lastest version, or should I add the -XX:+DisplayVMOutputToStdout to the test? >> >> Best, >> Albert >> >> On 23.10.2013 09:48, Igor Ignatyev wrote: >>>> Is this testing the full output or only the first line? >>> full output, but '-version' by default uses stderr, so stdouts should be empty and equal. >>> I think it would be better to add vm flags to explicitly use of stdout for warnings -- -XX:+DisplayVMOutputToStdout. >>> >>> Best regards, >>> Igor Ignatyev >>> >>> On 10/23/2013 04:45 AM, Christian Thalinger wrote: >>>> 44 // Check that the outputs are equal >>>> 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { >>>> >>>> Is this testing the full output or only the first line? Because the >>>> outputs are not equal: >>>> >>>> $ java -Xint -version >>>> java version "1.8.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >>>> interpreted mode) >>>> >>>> $ java -Xcomp -version >>>> java version "1.8.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >>>> compiled mode) >>>> >>>> >>>> On Oct 22, 2013, at 12:18 PM, Albert Noll >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> sure, here is the patch including the test: >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ >>>>> >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >>>>>> Albert, please add a jtreg test for this change. I think it is very >>>>>> easy: just start 'java -version' as a external process and check its >>>>>> output in 'Xint' and '-Xcomp' cases. If you don't think so, please >>>>>> file a RFE to add regression test and assign it to me. >>>>>> >>>>>> Thanks. >>>>>> - Igor >>>>>> >>>>>> ----- Reply message ----- >>>>>> From: "Albert Noll" >>>>>> To: "Igor Veresov" >>>>>> Cc: "hotspot-compiler-dev at openjdk.java.net" >>>>>> >>>>>> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: >>>>>> Initialization of C1 thread failed (no space to run compilers) >>>>>> Date: Tue, Oct 22, 2013 22:03 >>>>>> >>>>>> Roland, Igor, thanks for looking at this. >>>>>> >>>>>> I tested the patch as follows: >>>>>> >>>>>> java -Xint -version .. make sure that output does not appear >>>>>> java -Xcomp -version make sure that compiler(s) are working >>>>>> >>>>>> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint and >>>>>> -Xcomp and -Xmixed) >>>>>> >>>>>> Seems to work fine. >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> On 22.10.2013 19:12, Igor Veresov wrote: >>>>>>> Looks good. >>>>>>> >>>>>>> igor >>>>>>> >>>>>>> On Oct 22, 2013, at 6:15 AM, Albert Noll >>>>>> > wrote: >>>>>>> >>>>>>>> Thanks Igor. This is a good solution. >>>>>>>> >>>>>>>> Here is the webrev: >>>>>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>>>>>> Another trivial fix option is to just bail out >>>>>>>>> of CompileBroker::compilation_init() is UseCompiler is false. To >>>>>>>>> avoid initializing the compiler objects and all.. >>>>>>>>> >>>>>>>>> igor >>>>>>>>> >>>>>>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Christian, Igor, thanks for the reviews. >>>>>>>>>> >>>>>>>>>> There seems to be an ambiguity between -Xint and >>>>>>>>>> -XX:+UseCompiler. Whether we use a compiler or >>>>>>>>>> not, depends on the order in which the arguments are given. I am >>>>>>>>>> not exactly sure why we have >>>>>>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>>>>>> >>>>>>>>>> The reason why I added the checks when we determine the number of >>>>>>>>>> compiler threads is that we >>>>>>>>>> do not generate the compiler objects (they are not needed). Also, >>>>>>>>>> the number of compiler threads >>>>>>>>>> is set correctly. >>>>>>>>>> >>>>>>>>>> The solution proposed by Igor is simpler. If the above issues do >>>>>>>>>> not matter, I would also opt for the >>>>>>>>>> simple solution. >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>>>>>> If think you can just use the existing "UseCompiler" flag, that >>>>>>>>>>> we set to false when -Xint is specified and just not call >>>>>>>>>>> init_compiler_threads() if UseCompiler == false. >>>>>>>>>>> >>>>>>>>>>> igor >>>>>>>>>>> >>>>>>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> could I have reviews for this small patch? >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of >>>>>>>>>>>> C1 thread failed (no space to run compilers) when the VM is started >>>>>>>>>>>> with -Xint >>>>>>>>>>>> >>>>>>>>>>>> Solution: Do not start compiler threads if VM is started with -Xint >>>>>>>>>>>> >>>>>>>>>>>> Testing: -Xint flag does not print out the false warning. >>>>>>>>>>>> Tested flag combinations: >>>>>>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Many thanks in advance, >>>>>>>>>>>> Albert >>>>>>>>>>>> From igor.ignatyev at oracle.com Wed Oct 23 03:01:46 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Oct 2013 14:01:46 +0400 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <52679B0E.1000404@oracle.com> References: <5266CF8C.70305@oracle.com> <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> <52677F53.4020309@oracle.com> <526785AD.60506@oracle.com> <130D94A0-9879-4A61-9611-0E2223C89999@oracle.com> <52679B0E.1000404@oracle.com> Message-ID: <52679E8A.5080407@oracle.com> Yes, I'm fine w/ the latest version. Best regards, Igor Ignatyev On 10/23/2013 01:46 PM, Albert Noll wrote: > Thank you, Igor! > > Best, > Albert > > On 23.10.2013 11:25, Igor Veresov wrote: >> I think the latest version is fine. >> >> igor >> >> On Oct 23, 2013, at 1:15 AM, Albert Noll wrote: >> >>> Hi Igor, >>> >>> are you fine with the lastest version, or should I add the >>> -XX:+DisplayVMOutputToStdout to the test? >>> >>> Best, >>> Albert >>> >>> On 23.10.2013 09:48, Igor Ignatyev wrote: >>>>> Is this testing the full output or only the first line? >>>> full output, but '-version' by default uses stderr, so stdouts >>>> should be empty and equal. >>>> I think it would be better to add vm flags to explicitly use of >>>> stdout for warnings -- -XX:+DisplayVMOutputToStdout. >>>> >>>> Best regards, >>>> Igor Ignatyev >>>> >>>> On 10/23/2013 04:45 AM, Christian Thalinger wrote: >>>>> 44 // Check that the outputs are equal >>>>> 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { >>>>> >>>>> Is this testing the full output or only the first line? Because the >>>>> outputs are not equal: >>>>> >>>>> $ java -Xint -version >>>>> java version "1.8.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >>>>> interpreted mode) >>>>> >>>>> $ java -Xcomp -version >>>>> java version "1.8.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b56-internal-fastdebug, >>>>> compiled mode) >>>>> >>>>> >>>>> On Oct 22, 2013, at 12:18 PM, Albert Noll >>>> > wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> sure, here is the patch including the test: >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ >>>>>> >>>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >>>>>>> Albert, please add a jtreg test for this change. I think it is very >>>>>>> easy: just start 'java -version' as a external process and check its >>>>>>> output in 'Xint' and '-Xcomp' cases. If you don't think so, please >>>>>>> file a RFE to add regression test and assign it to me. >>>>>>> >>>>>>> Thanks. >>>>>>> - Igor >>>>>>> >>>>>>> ----- Reply message ----- >>>>>>> From: "Albert Noll" >>>>>>> To: "Igor Veresov" >>>>>>> Cc: "hotspot-compiler-dev at openjdk.java.net" >>>>>>> >>>>>>> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: >>>>>>> Initialization of C1 thread failed (no space to run compilers) >>>>>>> Date: Tue, Oct 22, 2013 22:03 >>>>>>> >>>>>>> Roland, Igor, thanks for looking at this. >>>>>>> >>>>>>> I tested the patch as follows: >>>>>>> >>>>>>> java -Xint -version .. make sure that output does not appear >>>>>>> java -Xcomp -version make sure that compiler(s) are working >>>>>>> >>>>>>> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint >>>>>>> and >>>>>>> -Xcomp and -Xmixed) >>>>>>> >>>>>>> Seems to work fine. >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> On 22.10.2013 19:12, Igor Veresov wrote: >>>>>>>> Looks good. >>>>>>>> >>>>>>>> igor >>>>>>>> >>>>>>>> On Oct 22, 2013, at 6:15 AM, Albert Noll >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Thanks Igor. This is a good solution. >>>>>>>>> >>>>>>>>> Here is the webrev: >>>>>>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>>>>>>> Another trivial fix option is to just bail out >>>>>>>>>> of CompileBroker::compilation_init() is UseCompiler is false. To >>>>>>>>>> avoid initializing the compiler objects and all.. >>>>>>>>>> >>>>>>>>>> igor >>>>>>>>>> >>>>>>>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Christian, Igor, thanks for the reviews. >>>>>>>>>>> >>>>>>>>>>> There seems to be an ambiguity between -Xint and >>>>>>>>>>> -XX:+UseCompiler. Whether we use a compiler or >>>>>>>>>>> not, depends on the order in which the arguments are given. I am >>>>>>>>>>> not exactly sure why we have >>>>>>>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>>>>>>> >>>>>>>>>>> The reason why I added the checks when we determine the >>>>>>>>>>> number of >>>>>>>>>>> compiler threads is that we >>>>>>>>>>> do not generate the compiler objects (they are not needed). >>>>>>>>>>> Also, >>>>>>>>>>> the number of compiler threads >>>>>>>>>>> is set correctly. >>>>>>>>>>> >>>>>>>>>>> The solution proposed by Igor is simpler. If the above issues do >>>>>>>>>>> not matter, I would also opt for the >>>>>>>>>>> simple solution. >>>>>>>>>>> >>>>>>>>>>> Best, >>>>>>>>>>> Albert >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>>>>>>> If think you can just use the existing "UseCompiler" flag, that >>>>>>>>>>>> we set to false when -Xint is specified and just not call >>>>>>>>>>>> init_compiler_threads() if UseCompiler == false. >>>>>>>>>>>> >>>>>>>>>>>> igor >>>>>>>>>>>> >>>>>>>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>>>>>>>>> >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> could I have reviews for this small patch? >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Problem: 8023014 introduced a wrong warning: Initialization of >>>>>>>>>>>>> C1 thread failed (no space to run compilers) when the VM is >>>>>>>>>>>>> started >>>>>>>>>>>>> with -Xint >>>>>>>>>>>>> >>>>>>>>>>>>> Solution: Do not start compiler threads if VM is started >>>>>>>>>>>>> with -Xint >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: -Xint flag does not print out the false warning. >>>>>>>>>>>>> Tested flag combinations: >>>>>>>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks in advance, >>>>>>>>>>>>> Albert >>>>>>>>>>>>> > From roland.westrelin at oracle.com Wed Oct 23 03:32:23 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 23 Oct 2013 12:32:23 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> Message-ID: <50CA3E7B-2484-4C63-A292-F3124A266EA1@oracle.com> On Oct 23, 2013, at 7:54 AM, Vladimir Kozlov wrote: > Roland, > > AddP node has 3 edges, you need to set both Address and Base to new obj. There is graphKit::basic_plus_adr(ptr, offset) method which you can use to generate new addP node. Thanks for spotting that. I'll push it with this change: diff --git a/src/share/vm/opto/parse2.cpp b/src/share/vm/opto/parse2.cpp --- a/src/share/vm/opto/parse2.cpp +++ b/src/share/vm/opto/parse2.cpp @@ -1399,9 +1399,7 @@ obj = maybe_cast_profiled_obj(obj, k); dec_sp(2); // Make the CmpP use the casted obj - addp = addp->clone(); - addp->set_req(AddPNode::Address, obj); - addp = _gvn.transform(addp); + addp = basic_plus_adr(obj, addp->in(AddPNode::Offset)); load_klass = load_klass->clone(); load_klass->set_req(2, addp); load_klass = _gvn.transform(load_klass); And thanks for the review! Roland. > > Other changes look fine. > > Thanks, > Vladimir > >> On Oct 21, 2013, at 4:10 PM, Roland Westrelin wrote: >> >> Here is a new webrev that should address all comments: >> >> http://cr.openjdk.java.net/~roland/8024070/webrev.02/ >> >> Roland. >> >> >>> On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: >>> >>> Roland, >>> >>> I looked on whole changes. >>> >>> Please, switch off UseTypeSpeculation by default as we discussed. >>> >>> I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. >>> >>> ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": >>> >>> + // Return true if profiling provides a type for the argument nb to the >>> >>> I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. >>> >>> It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. >>> >>> compile.cpp next comment is wrong since you keep using CastPP nodes: >>> >>> + // Remove the speculative part of types and clean up the graph from >>> + // the extra CheckCastPP nodes whose only purpose is to carry >>> + // them. Do that early so that optimizations are not disrupted by >>> + // the extra CheckCastPP nodes. >>> >>> 'tmp' is not good name for a 'list': >>> + Unique_Node_List tmp; >>> >>> Split next line: >>> >>> + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { >>> >>> >>> doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). >>> >>> graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. >>> >>> library_call.cpp split next line: >>> >>> + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); >>> >>> >>> parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. >>> >>> Thanks, >>> Vladimir >>> >>>> On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >>>> Roland, >>>> >>>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>> correctly if klass() == tap->klass() >>>> >>>> Lets leave NULL for now because in general meet(con, bot) = bot. It may >>>> change code generation more then other changes and we don't want it now. >>>> >>>>> >>>>> I've been trying to write simple tests to reproduce those failures >>>> without much success. Any suggestion what simple java code I can write >>>> to have something of ptr type AnyNull? >>>> >>>> AnyNull is ptr_dual for NotNull. Meets with it is checked in >>>> Type::meet(). So it should work for tests only with NotNull. >>>> >>>> Vladimir >>>> >>>>> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>>>> Here is a new webrev for this: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>>>> >>>>>>> I applied your suggestions below. >>>>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>>>> profiling data that we use right away so reusing profiling for this, >>>>>>> I find confusing. >>>>>> >>>>>> Okay. >>>>>> >>>>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>>>> problems that need investigation. I did extensive testing with the >>>>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>>>> >>>>>> Yes, it is fine. >>>>>> >>>>>>> >>>>>>> type.cpp has several generic type system fixes: >>>>>>> >>>>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>>>> !klass_is_exact()) { >>>>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>>>> 3186 } else { >>>>>> >>>>>> Looks correct but, please, make sure it works for multi-dimensional >>>>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>>>> that sometimes exact Object klass may be not really exact. >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>>> >>>>>>> mimics what we do for instance klass with subclass/superclass when >>>>>>> both subclass and superclass are exact >>>>>>> >>>>>>> 3315 if( this_klass->is_interface() && >>>>>>> !(tinst_klass->is_interface() || >>>>>>> 3316 tinst_klass == >>>>>>> ciEnv::current()->Object_klass())) { >>>>>>> >>>>>>> is required because otherwise if tinst_klass is of an object class, >>>>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>>>> this->_ptr and tinst->_ptr which were not swapped. >>>>>> >>>>>> Seems reasonable. >>>>>> >>>>>>> >>>>>>> I also had to make the cases: >>>>>>> >>>>>>> 3818 case AnyNull: >>>>>>> 3819 case TopPTR: >>>>>>> >>>>>>> and >>>>>>> >>>>>>> 3847 case NotNull: >>>>>>> 3848 case BotPTR: >>>>>>> >>>>>>> symmetrical which they are not currently. >>>>>> >>>>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>>>> place (it was always false). >>>>>> With your changes the code is still not symmetrical. I think in last >>>>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>>>> const_oop() to constructor. This is what we do when tap is Const and >>>>>> 'this' is below. >>>>> >>>>> Wouldn't this be sufficient as a fix? >>>>> >>>>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>>>> --- a/src/share/vm/opto/type.cpp >>>>> +++ b/src/share/vm/opto/type.cpp >>>>> @@ -3851,7 +3851,7 @@ >>>>> xk = tap->_klass_is_exact; >>>>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>>>> (klass() == tap->klass()); // Only precise for >>>>> identical arrays >>>>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>>>> instance_id, speculative); >>>>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>>>> lazy_klass, xk, off, instance_id, speculative); >>>>> default: ShouldNotReachHere(); >>>>> } >>>>> } >>>>> >>>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>>> correctly if klass() == tap->klass() >>>>> >>>>> I've been trying to write simple tests to reproduce those failures >>>>> without much success. Any suggestion what simple java code I can write >>>>> to have something of ptr type AnyNull? >>>>> >>>>> Thanks, >>>>> Roland. >>>>> >>>>>> >>>>>> I need to look on whole changes later. I will send additional comments. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> General notes: >>>>>>>> >>>>>>>> I think 'speculative' is not right word. We get these types from >>>>>>>> profiling when we see only one type. And we use it only after >>>>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>>>> it comes from. Or other more appropriate name. >>>>>>>> >>>>>>>> You need to add jtreg tests to verify these changes for different >>>>>>>> cases (especially merge points with different profile types). >>>>>>>> >>>>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>>>> Phi nodes and further anyway. >>>>>>>> >>>>>>>> Small notes: >>>>>>>> >>>>>>>> c2_globals.hpp: >>>>>>>> >>>>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>>>> >>>>>>>> drop_speculative* --> remove_speculative* >>>>>>>> >>>>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>>>> for last parameters. >>>>>>>> >>>>>>>> In a lot of places you use: >>>>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>>>> >>>>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>>>> use in such cases. >>>>>>>> >>>>>>>> library_call.cpp: typo: >>>>>>>> >>>>>>>> ciKlass* src_k, *dest_k; >>>>>>>> ^ >>>>>>>> regards, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>>>> Roland, >>>>>>>>> >>>>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>>>> Regression could be also caused by different inlining >>>>>>>>> (InlineSmallCode) >>>>>>>>> because more uncommon traps are generated. >>>>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>>>> am also >>>>>>>>> looking on your extra type profiling changes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>>>> Always >>>>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>>>> more >>>>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>>>> it is. >>>>>>>>>>> >>>>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>>>> It's >>>>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>>>> experiment >>>>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>>>> impact we >>>>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>>>> method >>>>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>>>> >>>>>>>>>> This is the kind of results I get with nashorn: >>>>>>>>>> deltablue: >>>>>>>>>> current: 2345 >>>>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>>>> >>>>>>>>>> RayTrace: >>>>>>>>>> current: 1978 >>>>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>>>> >>>>>>>>>> Richards: >>>>>>>>>> current: 2222 >>>>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>>>> >>>>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>>>> method of the compilation >>>>>>>>>> - type check on return from non inlined calls >>>>>>>>>> >>>>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>>>> benchmarks: >>>>>>>>>> >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> t >>>>>>>>>> Benchmark Samples Mean Stdev >>>>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>>>> javac 10 385.70 0.05 >>>>>>>>>> db 10 444.51 0.01 >>>>>>>>>> jess 10 699.05 0.00 >>>>>>>>>> jack 10 603.98 0.01 >>>>>>>>>> compress 10 534.99 0.01 >>>>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> t2 >>>>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>>>> Significant >>>>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>>>> 0.014 * >>>>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>>>> 0.013 * >>>>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>>>> 0.875 * >>>>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>>>> 0.000 Yes >>>>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>>>> 0.425 * >>>>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>>>> 0.329 * >>>>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>>>> 0.181 * >>>>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>>>> 0.001 Yes >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Roland. >> From roland.westrelin at oracle.com Wed Oct 23 03:32:49 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 23 Oct 2013 12:32:49 +0200 Subject: RFR(L): 8024070: C2 needs some form of type speculation In-Reply-To: References: <48654079-0FC8-4765-967F-2617D8E7A9F4@oracle.com> <5227C753.4080306@oracle.com> <42A1CA68-F41C-46FC-848B-F8BFFCACB91D@oracle.com> <52291E6A.5020605@oracle.com> <52295D6E.9040602@oracle.com> <43E27E99-D76E-4ADA-A21F-3F490C0A98AC@oracle.com> <522A5314.2060408@oracle.com> <52326202.1020807@oracle.com> <02161CCC-1F37-4C5F-B757-1A04888B811A@oracle.com> <5260A928.2010305@oracle.com> <4424860C-A294-42AB-98FA-789655A466A0@oracle.com> <52616ED8.9020703@oracle.com> <5261BE96.6020500@oracle.com> <16005FB0-3ADA-4016-BB01-EAB41C7F71F6@oracle.com> Message-ID: <97771952-2BBE-440C-8A78-43AF04D897A4@oracle.com> Thanks for the review. I'll make the suggested small changes. Roland. On Oct 23, 2013, at 2:40 AM, Christian Thalinger wrote: > Thanks for the Doxygen comments! These are the best ones we have so far! > > src/share/vm/opto/phaseX.cpp: > > + /** > + *Remove the speculative part of all types that we know of > + */ > > Add a space after "*" and get rid of the comment in the header file. > > Otherwise this looks good. > > On Oct 21, 2013, at 1:10 PM, Roland Westrelin wrote: > >> Here is a new webrev that should address all comments: >> >> http://cr.openjdk.java.net/~roland/8024070/webrev.02/ >> >> Roland. >> >> >> On Oct 19, 2013, at 1:04 AM, Vladimir Kozlov wrote: >> >>> Roland, >>> >>> I looked on whole changes. >>> >>> Please, switch off UseTypeSpeculation by default as we discussed. >>> >>> I don't see where you check that profiled type is better than current type to avoid unneeded speculative type generation. For example, type you get from arguments profiling for call in current method could be better then a type from parameters profiling which is used ehrn method is inlined. You will have 2 casts in such case. I think one could be avoided (from parameters profiling) if it is not better then previous (speculative or current) type. >>> >>> ciMethod.cpp can you use simple 'i' instead of 'nb' as we do in other places? And change comments accordingly, "for i'th argument": >>> >>> + // Return true if profiling provides a type for the argument nb to the >>> >>> I think *_profiled_type() should return type* instead of passing it through *& parameter. You can return NULL for cases when you return 'false' now. >>> >>> It would be nice if you can factor out asserts in separate methods since they are the same to avoid duplication and also print bytecode when assert fails. >>> >>> compile.cpp next comment is wrong since you keep using CastPP nodes: >>> >>> + // Remove the speculative part of types and clean up the graph from >>> + // the extra CheckCastPP nodes whose only purpose is to carry >>> + // them. Do that early so that optimizations are not disrupted by >>> + // the extra CheckCastPP nodes. >>> >>> 'tmp' is not good name for a 'list': >>> + Unique_Node_List tmp; >>> >>> Split next line: >>> >>> + if (n->is_Type() && n->as_Type()->type()->isa_oopptr() != NULL && n->as_Type()->type()->is_oopptr()->speculative() != NULL) { >>> >>> >>> doCall.cpp you can store profile.morphism() in local var and set it to 1 if you get spec_rcvr_type. It will simplify the code in call_generator(). >>> >>> graphKit.cpp please, put all new record_*() methods together preferably in the same order as declarations in graphKit.hpp. >>> >>> library_call.cpp split next line: >>> >>> + ciKlass* src_k = top_src->klass(), *dest_k = top_dest->klass(); >>> >>> >>> parse2.cpp I think you need to create new LoadKlass/DecodeNKlass if new obj is different (has cast). replace_in_map() will not replace inputs to address (AddP) of LoadKlass. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/18/13 10:24 AM, Vladimir Kozlov wrote: >>>> Roland, >>>> >>>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>> correctly if klass() == tap->klass() >>>> >>>> Lets leave NULL for now because in general meet(con, bot) = bot. It may >>>> change code generation more then other changes and we don't want it now. >>>> >>>>> >>>>> I've been trying to write simple tests to reproduce those failures >>>> without much success. Any suggestion what simple java code I can write >>>> to have something of ptr type AnyNull? >>>> >>>> AnyNull is ptr_dual for NotNull. Meets with it is checked in >>>> Type::meet(). So it should work for tests only with NotNull. >>>> >>>> Vladimir >>>> >>>> On 10/18/13 9:19 AM, Roland Westrelin wrote: >>>>> Hi Vladimir, >>>>> >>>>> On Oct 18, 2013, at 5:21 AM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>> On 10/17/13 10:55 AM, Roland Westrelin wrote: >>>>>>> Here is a new webrev for this: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~roland/8024070/webrev.01/ >>>>>>> >>>>>>> I applied your suggestions below. >>>>>>> I kept the "speculative" name. "Profiling" in the code indicates >>>>>>> profiling data that we use right away so reusing profiling for this, >>>>>>> I find confusing. >>>>>> >>>>>> Okay. >>>>>> >>>>>>> I kept the CastPPNodes. I tried the CheckCastPPNodes but I had some >>>>>>> problems that need investigation. I did extensive testing with the >>>>>>> CastPPNodes. Can we keep them for now and reconsider that later? >>>>>> >>>>>> Yes, it is fine. >>>>>> >>>>>>> >>>>>>> type.cpp has several generic type system fixes: >>>>>>> >>>>>>> 3184 if (klass()->equals(ciEnv::current()->Object_klass()) && >>>>>>> !klass_is_exact()) { >>>>>>> 3185 return TypeAryPtr::make(ptr, tp->ary(), tp->klass(), >>>>>>> tp->klass_is_exact(), offset, instance_id, speculative); >>>>>>> 3186 } else { >>>>>> >>>>>> Looks correct but, please, make sure it works for multi-dimensional >>>>>> object arrays. And run full CTW tests and all jtregs. I am concern >>>>>> that sometimes exact Object klass may be not really exact. >>>>> >>>>> Ok. >>>>> >>>>>> >>>>>>> >>>>>>> mimics what we do for instance klass with subclass/superclass when >>>>>>> both subclass and superclass are exact >>>>>>> >>>>>>> 3315 if( this_klass->is_interface() && >>>>>>> !(tinst_klass->is_interface() || >>>>>>> 3316 tinst_klass == >>>>>>> ciEnv::current()->Object_klass())) { >>>>>>> >>>>>>> is required because otherwise if tinst_klass is of an object class, >>>>>>> we swap tinst_* and this_* but don't enter the next if() and we use >>>>>>> this->_ptr and tinst->_ptr which were not swapped. >>>>>> >>>>>> Seems reasonable. >>>>>> >>>>>>> >>>>>>> I also had to make the cases: >>>>>>> >>>>>>> 3818 case AnyNull: >>>>>>> 3819 case TopPTR: >>>>>>> >>>>>>> and >>>>>>> >>>>>>> 3847 case NotNull: >>>>>>> 3848 case BotPTR: >>>>>>> >>>>>>> symmetrical which they are not currently. >>>>>> >>>>>> Yes, the check "else if (above_centerline(tap->_ptr))" was in wrong >>>>>> place (it was always false). >>>>>> With your changes the code is still not symmetrical. I think in last >>>>>> case (NotNull or BotPTR) when klass() == tap->klass() we need to pass >>>>>> const_oop() to constructor. This is what we do when tap is Const and >>>>>> 'this' is below. >>>>> >>>>> Wouldn't this be sufficient as a fix? >>>>> >>>>> diff --git a/src/share/vm/opto/type.cpp b/src/share/vm/opto/type.cpp >>>>> --- a/src/share/vm/opto/type.cpp >>>>> +++ b/src/share/vm/opto/type.cpp >>>>> @@ -3851,7 +3851,7 @@ >>>>> xk = tap->_klass_is_exact; >>>>> else xk = (tap->_klass_is_exact & this->_klass_is_exact) && >>>>> (klass() == tap->klass()); // Only precise for >>>>> identical arrays >>>>> - return TypeAryPtr::make(ptr, NULL, tary, lazy_klass, xk, off, >>>>> instance_id, speculative); >>>>> + return TypeAryPtr::make(ptr, tap->const_oop(), tary, >>>>> lazy_klass, xk, off, instance_id, speculative); >>>>> default: ShouldNotReachHere(); >>>>> } >>>>> } >>>>> >>>>> tap->const_oop() would be non NULL for a Constant only and xk is set >>>>> correctly if klass() == tap->klass() >>>>> >>>>> I've been trying to write simple tests to reproduce those failures >>>>> without much success. Any suggestion what simple java code I can write >>>>> to have something of ptr type AnyNull? >>>>> >>>>> Thanks, >>>>> Roland. >>>>> >>>>>> >>>>>> I need to look on whole changes later. I will send additional comments. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Roland. >>>>>>> >>>>>>>> General notes: >>>>>>>> >>>>>>>> I think 'speculative' is not right word. We get these types from >>>>>>>> profiling when we see only one type. And we use it only after >>>>>>>> generated checks. 'profiled' will be more accurate and clear where >>>>>>>> it comes from. Or other more appropriate name. >>>>>>>> >>>>>>>> You need to add jtreg tests to verify these changes for different >>>>>>>> cases (especially merge points with different profile types). >>>>>>>> >>>>>>>> Please, explain why we need CastPP. In merge points it will leak to >>>>>>>> Phi nodes and further anyway. >>>>>>>> >>>>>>>> Small notes: >>>>>>>> >>>>>>>> c2_globals.hpp: >>>>>>>> >>>>>>>> TypeSpeculation --> UseTypeSpeculation >>>>>>>> >>>>>>>> drop_speculative* --> remove_speculative* >>>>>>>> >>>>>>>> Why change all TypeInstPtr::make() if you have default value set >>>>>>>> for last parameters. >>>>>>>> >>>>>>>> In a lot of places you use: >>>>>>>> t->isa_oopptr() != NULL && t->is_oopptr()->speculative_type() >>>>>>>> >>>>>>>> add Type::has_speculative_type() and Type::speculative_type() to >>>>>>>> use in such cases. >>>>>>>> >>>>>>>> library_call.cpp: typo: >>>>>>>> >>>>>>>> ciKlass* src_k, *dest_k; >>>>>>>> ^ >>>>>>>> regards, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 9/6/13 3:11 PM, Vladimir Kozlov wrote: >>>>>>>>> Roland, >>>>>>>>> >>>>>>>>> Thank you for doing this experiment. But Richards is faster ;) >>>>>>>>> Regression could be also caused by different inlining >>>>>>>>> (InlineSmallCode) >>>>>>>>> because more uncommon traps are generated. >>>>>>>>> Anyway, you convince me. Let me go through your changes again. I >>>>>>>>> am also >>>>>>>>> looking on your extra type profiling changes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 9/6/13 11:16 AM, Roland Westrelin wrote: >>>>>>>>>>>> Can you try an other experiment (may be you did it already)? >>>>>>>>>>>> Always >>>>>>>>>>>> (under flag) generate klass check (type_check_receiver()) when >>>>>>>>>>>> unique type from profiling is more precise than type from static >>>>>>>>>>>> analysis. Yes, we may get performance regression in cases where >>>>>>>>>>>> more >>>>>>>>>>>> precise type is not needed. We need to test it and see how bad >>>>>>>>>>>> it is. >>>>>>>>>>> >>>>>>>>>>> This change in itself doesn't bring any performance improvement. >>>>>>>>>>> It's >>>>>>>>>>> here so that if we add more profiling points (8023657) we know what >>>>>>>>>>> to do with the data from profiling. Type speculation + extra >>>>>>>>>>> profiling show a perf improvement on nashorn (10-20% on some >>>>>>>>>>> benchmarks with the nashorn.jar from jdk b105). To me the >>>>>>>>>>> experiment >>>>>>>>>>> that makes sense it to enable profiling from 8023657, do the type >>>>>>>>>>> checks at the profiling points systematically and see what >>>>>>>>>>> impact we >>>>>>>>>>> see on perf. I did that with type checks on entry to the root >>>>>>>>>>> method >>>>>>>>>>> of the compilation for incoming arguments and at returns from calls >>>>>>>>>>> that were not inlined and I had a clear regression on specjvm98. I >>>>>>>>>>> don't remember the exact numbers. I can run the experiment again. >>>>>>>>>> >>>>>>>>>> This is the kind of results I get with nashorn: >>>>>>>>>> deltablue: >>>>>>>>>> current: 2345 >>>>>>>>>> with type speculation and extra profiling: 2662 >>>>>>>>>> with extra profiling and systematic type checks: 2285 >>>>>>>>>> >>>>>>>>>> RayTrace: >>>>>>>>>> current: 1978 >>>>>>>>>> with type speculation and extra profiling: 2113 >>>>>>>>>> with extra profiling and systematic type checks: 1795 >>>>>>>>>> >>>>>>>>>> Richards: >>>>>>>>>> current: 2222 >>>>>>>>>> with type speculation and extra profiling: 2489 >>>>>>>>>> with extra profiling and systematic type checks: 2563 >>>>>>>>>> >>>>>>>>>> "extra profiling and systematic type checks" is: >>>>>>>>>> - type checks for incoming arguments on method entry for the root >>>>>>>>>> method of the compilation >>>>>>>>>> - type check on return from non inlined calls >>>>>>>>>> >>>>>>>>>> so a limited subset of type checks but that gives us type for value >>>>>>>>>> flowing in the compiled method. Eventhought the number of checks is >>>>>>>>>> limited, it is sufficient to cause a regression on standard >>>>>>>>>> benchmarks: >>>>>>>>>> >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> t >>>>>>>>>> Benchmark Samples Mean Stdev >>>>>>>>>> specjvm98 10 663.84 0.01 >>>>>>>>>> javac 10 385.70 0.05 >>>>>>>>>> db 10 444.51 0.01 >>>>>>>>>> jess 10 699.05 0.00 >>>>>>>>>> jack 10 603.98 0.01 >>>>>>>>>> compress 10 534.99 0.01 >>>>>>>>>> mtrt 10 1694.45 0.01 >>>>>>>>>> mpegaudio 10 866.77 0.00 >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> t2 >>>>>>>>>> Benchmark Samples Mean Stdev %Diff P >>>>>>>>>> Significant >>>>>>>>>> specjvm98 10 654.39 0.01 -1.42 >>>>>>>>>> 0.014 * >>>>>>>>>> javac 10 356.46 0.07 -7.58 >>>>>>>>>> 0.013 * >>>>>>>>>> db 10 444.87 0.01 0.08 >>>>>>>>>> 0.875 * >>>>>>>>>> jess 10 681.66 0.01 -2.49 >>>>>>>>>> 0.000 Yes >>>>>>>>>> jack 10 601.90 0.01 -0.34 >>>>>>>>>> 0.425 * >>>>>>>>>> compress 10 538.06 0.02 0.57 >>>>>>>>>> 0.329 * >>>>>>>>>> mtrt 10 1722.77 0.03 1.67 >>>>>>>>>> 0.181 * >>>>>>>>>> mpegaudio 10 854.38 0.01 -1.43 >>>>>>>>>> 0.001 Yes >>>>>>>>>> ============================================================================ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Roland. >>>>>>>>>> >>>>>>> >>>>> >> > From rickard.backman at oracle.com Wed Oct 23 03:54:33 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Wed, 23 Oct 2013 10:54:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Message-ID: <20131023105441.C1A0362679@hg.openjdk.java.net> Changeset: 8b4bbba322d3 Author: anoll Date: 2013-10-23 10:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8b4bbba322d3 8026407: VM crashes on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified Summary: Ensure currently required generation of AdapterHandlerLibrary::create_native_wrapper() Reviewed-by: roland, iveresov ! src/share/vm/compiler/compileBroker.cpp From roland.westrelin at oracle.com Wed Oct 23 05:51:04 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 23 Oct 2013 14:51:04 +0200 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> References: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> Message-ID: <022C8E7D-E175-4F5C-B67A-EBD761AC2ECA@oracle.com> > http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ That looks good to me. Roland. From vladimir.x.ivanov at oracle.com Wed Oct 23 06:03:34 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 23 Oct 2013 17:03:34 +0400 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> References: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> Message-ID: <5267C926.1060703@oracle.com> Chris, - ShouldNotReachHere(); + { + ResourceMark rm; + fatal(err_msg("no original bytecode found in %s at bci %d", name_and_sig_as_C_string(), bci)); + } Did you intend to use err_msg_res there? Best regards, Vladimir Ivanov On 10/23/13 2:31 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8026328 > http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ > > 8026328: Setting a breakpoint on invokedynamic crashes the JVM > Reviewed-by: > > Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. > > The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. > > There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. > From rickard.backman at oracle.com Wed Oct 23 06:24:46 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 23 Oct 2013 15:24:46 +0200 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> <20131022135635.GF13244@rbackman> Message-ID: <20131023132446.GL13244@rbackman> Vladimir, thanks for taking time to look at this. See inline. On 10/23, Vladimir Kozlov wrote: > Richard, > > Node.hpp and corresponding constructors. You should specify id only for MathExact class since you only need query method for it (no need to specify it for subclasses). The number in DEFINE_CLASS_ID should be 4 (not 7) since the last one (for Membar) was 3. Ok. > > I do not understand your problem with shared nodes (matcher.cpp changes). Sharing means that separate Mach node will be generated (it will not be part of mega Mach node). So I do not see the problem. Is it load nodes you have problem with? Please, explain. > Removed. is_shared is also passed as an argument to match_into_reg. If shared we will never put it into a register. > About phi node. Look if it is created by spit_through_phi optimization. We should not do that because if addexact, for example, collapsed/folded on one branch how we get flag value from this branch. The Phi was (part of) an induction variable in this case. New webrev: http://cr.openjdk.java.net/~rbackman/8026844.2/ Thanks! > > Thanks, > Vladimir > > > On Oct 22, 2013, at 9:56 AM, Rickard B?ckman wrote: > > > > Christian, > > > > new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ > > The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ > > (I missed x86_32.ad when generating it, but everything else should be > > there). > > > > I removed the timeouts, they were remains of another attempt at writing > > tests. > > > > Thanks > > > >> On 10/18, Christian Thalinger wrote: > >> src/share/vm/opto/library_call.cpp: > >> > >> + Node* arg1 = argument(0); // type long > >> + // argument(1) == TOP > >> + Node* arg2 = argument(2); // type long > >> + // argument(4) == TOP > >> > >> The "argument(4)" comment it wrong; should be 3. > >> > >> + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); > >> > >> Remove the extra spaces. > >> > >> src/share/vm/opto/mathexactnode.hpp: > >> > >> + MathExactNode(Node* ctrl, Node* n1); > >> MathExactNode(Node* ctrl, Node* in1, Node* in2); > >> > >> Should "n1" be "in1"? Or maybe just "n". > >> > >> These have two copyright headers: > >> > >> test/compiler/intrinsics/mathexact/IncExactITest.java > >> test/compiler/intrinsics/mathexact/IncExactLTest.java > >> > >> It seems all of the tests have a wrong bug number: > >> > >> 26 * @bug 8024924 > >> > >> or > >> > >> 26 * @bug 8025657 > >> > >> test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: > >> > >> 28 * @compile MulExactIRepeatTest.java > >> > >> That one doesn't compile Verify.java. Please check all of the test files for these issue. > >> > >> In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? > >> > >> The question is do we really need individual test files for these? I don't object just mentioning it. > >> > >>> On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: > >>> > >>> Hi, can I get reviews for the following change: > >>> > >>> This change creates intrinsics for addExact(long, long), subtractExact, > >>> negateExact, incrementExact, decrementExact and multiplyExact. > >>> > >>> The intrinsics are only added on x86 and only 64-bit has the intrinsics > >>> for the long-versions. (32-bit only has int-versions). > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > >>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > >>> > >>> Thanks > >>> /R > > /R /R From albert.noll at oracle.com Wed Oct 23 06:49:53 2013 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 23 Oct 2013 15:49:53 +0200 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> Message-ID: <5267D401.6070403@oracle.com> Hi, unfortunately, the patch was not correct, as revealed by jprt. The problem was that entries into the hashmap are not removed correctly. This version fixes the problem. The patch is currently in jprt. So far, everything looks good. Many thanks for another round. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.03/ Best, Albert On 16.10.2013 19:43, Christian Thalinger wrote: > It would be nice to have a comment on this guy: > *+ bool _contains_all_checks;* > No need for another webrev if you decide to add the comment. > > Looks good. > > On Oct 15, 2013, at 11:02 PM, Albert Noll > wrote: > >> Forgot to adjust the comment. This version should be fine. >> >> http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ >> >> >> Albert >> >> On 15.10.2013 21:03, Vladimir Kozlov wrote: >>> Albert, >>> >>> contains_all_stubs name is incorrect. It should be >>> contains_all_checks. Adapter code does not have stubs in it. >>> >>> I think the next check should be: >>> >>> bool contains_all_checks = (StubRoutines::code2() != NULL) || >>> !VerifyAdapterCalls; >>> >>> because code does not change when VerifyAdapterCalls is false. >>> Then you don't need to check VerifyAdapterCalls in next condition: >>> >>> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && >>> !entry->contains_all_checks()) { >>> >>> And we need to regenerate adapter regardless VerifyAdapterSharing >>> because, as you said, VerifyAdapterCalls potentially reports a false >>> error if check for code2 is not generated. >>> >>> So the condition should be simple "if (!entry->contains_all_checks())". >>> >>> Could you leave next lines unchanged (use 2 lines for arguments)?: >>> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >>> >>> sizeof(buffer_locs)/sizeof(relocInfo)); >>> MacroAssembler _masm(&buffer); >>> >>> Cleanup is fine. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/15/13 4:14 AM, Albert Noll wrote: >>>> Hi, >>>> >>>> could I have reviews for this small patch? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>>> >>>> >>>> Problem: This flag is broken. The reason is that adapters >>>> (gen_i2c_adapter()) that are generated during VM startup do not >>>> include >>>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>>> specified. StubRoutines::code2() is only allocated later during >>>> startup; >>>> consequently, code2() is NULL. As a result, the size of the generated >>>> adapter as well as the code itself does not mactch. >>>> >>>> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >>>> Note that this patch also fixes potential issues with >>>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>>> removes some unused field of VerifyAdapterSharing. >>>> >>>> >>>> Many thanks in advance, >>>> Albert >>>> ** >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131023/a5a53429/attachment.html From vladimir.x.ivanov at oracle.com Wed Oct 23 07:44:34 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 23 Oct 2013 18:44:34 +0400 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> <525FDC25.30805@oracle.com> <5260F071.6080708@oracle.com> Message-ID: <5267E0D2.1050605@oracle.com> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.01/ 3 lines changed: 0 ins; 2 del; 1 mod Reviewed-by: jrose, ? The fix is to skip MemberNameTable update in MHN_getMemberVMInfo. I filed a followup bug to implement MemberName interning [1]. It should eliminate possibility of MemberNameTable elements overwrite. Testing: failing testcase. Contributed-by: sspitsyn JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8027162 On 10/18/13 8:47 PM, Christian Thalinger wrote: > > On Oct 18, 2013, at 1:25 AM, serguei.spitsyn at oracle.com wrote: > >> Vladimir, >> >> >> Just want to share some details with you. >> >> >> On 10/17/13 5:46 AM, Vladimir Ivanov wrote: >>> Serguei, Chris, Igor, thanks for looking at this fix. >>> >>> I need to look more thoroughly at this code. >>> I assumed that member name is initialized only once, but I was wrong - asserting empty slot in MethodHandles::init_method_MemberName fails during initialization of JSR292 core classes. >> >> John or Chris, please, correct me if I'm wrong... >> But, I think, John had a plan in mind to utilize the MNT for uniqueness of member names. >> It was about all member names, not only method member names. > > Correct. It is worrying that the assert fires. We should get to the bottom of this and fix it properly. > >> >> >> Thanks, >> Serguei >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: >>>> On 10/16/13 1:28 PM, Christian Thalinger wrote: >>>>> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >>>>> wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>>>>> 7 lines changed: 5 ins; 1 del; 1 mod >>>>>> >>>>>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>>>>> assert(m.vminfoIsConsistent()); >>>>>> >>>>>> After that check, class redefinition is broken - it's still possible >>>>>> to invoke old version of a method. >>>>>> >>>>>> Analysis from Serguei: >>>>>> "The problem is here: >>>>>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>>>>> info) { >>>>>> . . . . . . . . >>>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>>> >>>>>> return mname(); >>>>>> } >>>>>> >>>>>> The call to add_member_name() resets the member name at the index >>>>>> m->method_idnum(). After that one of the two member names with the >>>>>> same method_idnum() is out of the MNT and is not updated when the >>>>>> method is redefined." >>>>> As I understand this the problem is calling >>>>> MethodHandles::init_method_MemberName which installs a new MemberName >>>>> instance in the MemberNameTable. Correct? >>>>> >>>>> If that's the case then there is a potential race here. >>>>> >>>>> + x = m->method_holder()->get_member_name(m->method_idnum()); >>>>> + if (x == NULL) { >>>>> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >>>>> x = MethodHandles::init_method_MemberName(mname2, info); >>>>> } >>>>> >>>>> Racing threads can get back null when calling get_member_name and then >>>>> install different MemberName objects in the table. >>>> >>>> Good catch, Chris. >>>> I do not see a way to fix it easily without some refactoring. >>>> >>>> It is probably better to add to the InstanceKlass a helper function that >>>> will do >>>> this dance with a required synchronization. >>>> But the following line needs to be taken out of the >>>> init_method_MemberName() : >>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>>> The fix is to check whether there's already a member name associated >>>>>> with the before creating a new one. >>>>>> >>>>>> Testing: failing test. >>>>>> >>>>>> Contributed-by: sspitsyn, vlivanov >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >>>> >> > From christian.thalinger at oracle.com Wed Oct 23 09:05:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Oct 2013 09:05:02 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <5267C926.1060703@oracle.com> References: <9306D231-A5C0-4FF8-93C4-1D89038B3A3D@oracle.com> <5267C926.1060703@oracle.com> Message-ID: <03C799F3-4C9A-4799-9CF6-4D3EA3CBB94B@oracle.com> On Oct 23, 2013, at 6:03 AM, Vladimir Ivanov wrote: > Chris, > > - ShouldNotReachHere(); > + { > + ResourceMark rm; > + fatal(err_msg("no original bytecode found in %s at bci %d", name_and_sig_as_C_string(), bci)); > + } > > Did you intend to use err_msg_res there? No. We usually use err_msg_res only in the compiler since err_msg_res can fail. The ResourceMark is there because of name_and_sig_as_C_string(). But means it could also fail? ;-) > > Best regards, > Vladimir Ivanov > > On 10/23/13 2:31 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8026328 >> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >> >> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >> Reviewed-by: >> >> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >> >> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >> >> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >> From roland.westrelin at oracle.com Wed Oct 23 08:39:19 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Wed, 23 Oct 2013 15:39:19 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8024070: C2 needs some form of type speculation Message-ID: <20131023153943.DA7256268F@hg.openjdk.java.net> Changeset: b2ee5dc63353 Author: roland Date: 2013-10-23 12:40 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b2ee5dc63353 8024070: C2 needs some form of type speculation Summary: record unused type profile information with type system, propagate and use it. Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp + test/compiler/types/TypeSpeculation.java From john.r.rose at oracle.com Wed Oct 23 09:40:28 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 23 Oct 2013 09:40:28 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <5267E0D2.1050605@oracle.com> References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> <525FDC25.30805@oracle.com> <5260F071.6080708@oracle.com> <5267E0D2.1050605@oracle.com> Message-ID: <961C26A3-22AF-4C4F-BA3F-744801CC5E5A@oracle.com> Reviewed. (You as sponsor can add yourself as another reviewer if you wish.) ? John On Oct 23, 2013, at 7:44 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023004/webrev.01/ > 3 lines changed: 0 ins; 2 del; 1 mod > > Reviewed-by: jrose, ? > > The fix is to skip MemberNameTable update in MHN_getMemberVMInfo. > > I filed a followup bug to implement MemberName interning [1]. It should eliminate possibility of MemberNameTable elements overwrite. > > Testing: failing testcase. > > Contributed-by: sspitsyn > > JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8027162 > > On 10/18/13 8:47 PM, Christian Thalinger wrote: >> >> On Oct 18, 2013, at 1:25 AM, serguei.spitsyn at oracle.com wrote: >> >>> Vladimir, >>> >>> >>> Just want to share some details with you. >>> >>> >>> On 10/17/13 5:46 AM, Vladimir Ivanov wrote: >>>> Serguei, Chris, Igor, thanks for looking at this fix. >>>> >>>> I need to look more thoroughly at this code. >>>> I assumed that member name is initialized only once, but I was wrong - asserting empty slot in MethodHandles::init_method_MemberName fails during initialization of JSR292 core classes. >>> >>> John or Chris, please, correct me if I'm wrong... >>> But, I think, John had a plan in mind to utilize the MNT for uniqueness of member names. >>> It was about all member names, not only method member names. >> >> Correct. It is worrying that the assert fires. We should get to the bottom of this and fix it properly. >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 10/16/13 1:28 PM, Christian Thalinger wrote: >>>>>> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >>>>>> wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>>>>>> 7 lines changed: 5 ins; 1 del; 1 mod >>>>>>> >>>>>>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>>>>>> assert(m.vminfoIsConsistent()); >>>>>>> >>>>>>> After that check, class redefinition is broken - it's still possible >>>>>>> to invoke old version of a method. >>>>>>> >>>>>>> Analysis from Serguei: >>>>>>> "The problem is here: >>>>>>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>>>>>> info) { >>>>>>> . . . . . . . . >>>>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>>>> >>>>>>> return mname(); >>>>>>> } >>>>>>> >>>>>>> The call to add_member_name() resets the member name at the index >>>>>>> m->method_idnum(). After that one of the two member names with the >>>>>>> same method_idnum() is out of the MNT and is not updated when the >>>>>>> method is redefined." >>>>>> As I understand this the problem is calling >>>>>> MethodHandles::init_method_MemberName which installs a new MemberName >>>>>> instance in the MemberNameTable. Correct? >>>>>> >>>>>> If that's the case then there is a potential race here. >>>>>> >>>>>> + x = m->method_holder()->get_member_name(m->method_idnum()); >>>>>> + if (x == NULL) { >>>>>> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >>>>>> x = MethodHandles::init_method_MemberName(mname2, info); >>>>>> } >>>>>> >>>>>> Racing threads can get back null when calling get_member_name and then >>>>>> install different MemberName objects in the table. >>>>> >>>>> Good catch, Chris. >>>>> I do not see a way to fix it easily without some refactoring. >>>>> >>>>> It is probably better to add to the InstanceKlass a helper function that >>>>> will do >>>>> this dance with a required synchronization. >>>>> But the following line needs to be taken out of the >>>>> init_method_MemberName() : >>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>>> The fix is to check whether there's already a member name associated >>>>>>> with the before creating a new one. >>>>>>> >>>>>>> Testing: failing test. >>>>>>> >>>>>>> Contributed-by: sspitsyn, vlivanov >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >>>>> >>> >> From vladimir.x.ivanov at oracle.com Wed Oct 23 09:41:33 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 23 Oct 2013 20:41:33 +0400 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <961C26A3-22AF-4C4F-BA3F-744801CC5E5A@oracle.com> References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> <525FDC25.30805@oracle.com> <5260F071.6080708@oracle.com> <5267E0D2.1050605@oracle.com> <961C26A3-22AF-4C4F-BA3F-744801CC5E5A@oracle.com> Message-ID: <5267FC3D.3090308@oracle.com> Thank you, John. Best regards, Vladimir Ivanov On 10/23/13 8:40 PM, John Rose wrote: > Reviewed. > > (You as sponsor can add yourself as another reviewer if you wish.) > > ? John > > On Oct 23, 2013, at 7:44 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.01/ >> 3 lines changed: 0 ins; 2 del; 1 mod >> >> Reviewed-by: jrose, ? >> >> The fix is to skip MemberNameTable update in MHN_getMemberVMInfo. >> >> I filed a followup bug to implement MemberName interning [1]. It should eliminate possibility of MemberNameTable elements overwrite. >> >> Testing: failing testcase. >> >> Contributed-by: sspitsyn >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8027162 >> >> On 10/18/13 8:47 PM, Christian Thalinger wrote: >>> >>> On Oct 18, 2013, at 1:25 AM, serguei.spitsyn at oracle.com wrote: >>> >>>> Vladimir, >>>> >>>> >>>> Just want to share some details with you. >>>> >>>> >>>> On 10/17/13 5:46 AM, Vladimir Ivanov wrote: >>>>> Serguei, Chris, Igor, thanks for looking at this fix. >>>>> >>>>> I need to look more thoroughly at this code. >>>>> I assumed that member name is initialized only once, but I was wrong - asserting empty slot in MethodHandles::init_method_MemberName fails during initialization of JSR292 core classes. >>>> >>>> John or Chris, please, correct me if I'm wrong... >>>> But, I think, John had a plan in mind to utilize the MNT for uniqueness of member names. >>>> It was about all member names, not only method member names. >>> >>> Correct. It is worrying that the assert fires. We should get to the bottom of this and fix it properly. >>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 10/16/13 1:28 PM, Christian Thalinger wrote: >>>>>>> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >>>>>>> wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>>>>>>> 7 lines changed: 5 ins; 1 del; 1 mod >>>>>>>> >>>>>>>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>>>>>>> assert(m.vminfoIsConsistent()); >>>>>>>> >>>>>>>> After that check, class redefinition is broken - it's still possible >>>>>>>> to invoke old version of a method. >>>>>>>> >>>>>>>> Analysis from Serguei: >>>>>>>> "The problem is here: >>>>>>>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>>>>>>> info) { >>>>>>>> . . . . . . . . >>>>>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>>>>> >>>>>>>> return mname(); >>>>>>>> } >>>>>>>> >>>>>>>> The call to add_member_name() resets the member name at the index >>>>>>>> m->method_idnum(). After that one of the two member names with the >>>>>>>> same method_idnum() is out of the MNT and is not updated when the >>>>>>>> method is redefined." >>>>>>> As I understand this the problem is calling >>>>>>> MethodHandles::init_method_MemberName which installs a new MemberName >>>>>>> instance in the MemberNameTable. Correct? >>>>>>> >>>>>>> If that's the case then there is a potential race here. >>>>>>> >>>>>>> + x = m->method_holder()->get_member_name(m->method_idnum()); >>>>>>> + if (x == NULL) { >>>>>>> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >>>>>>> x = MethodHandles::init_method_MemberName(mname2, info); >>>>>>> } >>>>>>> >>>>>>> Racing threads can get back null when calling get_member_name and then >>>>>>> install different MemberName objects in the table. >>>>>> >>>>>> Good catch, Chris. >>>>>> I do not see a way to fix it easily without some refactoring. >>>>>> >>>>>> It is probably better to add to the InstanceKlass a helper function that >>>>>> will do >>>>>> this dance with a required synchronization. >>>>>> But the following line needs to be taken out of the >>>>>> init_method_MemberName() : >>>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>>> The fix is to check whether there's already a member name associated >>>>>>>> with the before creating a new one. >>>>>>>> >>>>>>>> Testing: failing test. >>>>>>>> >>>>>>>> Contributed-by: sspitsyn, vlivanov >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Wed Oct 23 09:45:24 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Oct 2013 12:45:24 -0400 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <20131023132446.GL13244@rbackman> References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> <20131022135635.GF13244@rbackman> <20131023132446.GL13244@rbackman> Message-ID: Looks good to me. Thanks, Vladimir > On Oct 23, 2013, at 9:24 AM, Rickard B?ckman wrote: > > Vladimir, thanks for taking time to look at this. See inline. > >> On 10/23, Vladimir Kozlov wrote: >> Richard, >> >> Node.hpp and corresponding constructors. You should specify id only for MathExact class since you only need query method for it (no need to specify it for subclasses). The number in DEFINE_CLASS_ID should be 4 (not 7) since the last one (for Membar) was 3. > > Ok. > >> >> I do not understand your problem with shared nodes (matcher.cpp changes). Sharing means that separate Mach node will be generated (it will not be part of mega Mach node). So I do not see the problem. Is it load nodes you have problem with? Please, explain. > > Removed. is_shared is also passed as an argument to match_into_reg. If > shared we will never put it into a register. > >> About phi node. Look if it is created by spit_through_phi optimization. We should not do that because if addexact, for example, collapsed/folded on one branch how we get flag value from this branch. > > The Phi was (part of) an induction variable in this case. > > New webrev: http://cr.openjdk.java.net/~rbackman/8026844.2/ > > Thanks! > >> >> Thanks, >> Vladimir >> >>> On Oct 22, 2013, at 9:56 AM, Rickard B?ckman wrote: >>> >>> Christian, >>> >>> new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ >>> The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ >>> (I missed x86_32.ad when generating it, but everything else should be >>> there). >>> >>> I removed the timeouts, they were remains of another attempt at writing >>> tests. >>> >>> Thanks >>> >>>> On 10/18, Christian Thalinger wrote: >>>> src/share/vm/opto/library_call.cpp: >>>> >>>> + Node* arg1 = argument(0); // type long >>>> + // argument(1) == TOP >>>> + Node* arg2 = argument(2); // type long >>>> + // argument(4) == TOP >>>> >>>> The "argument(4)" comment it wrong; should be 3. >>>> >>>> + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); >>>> >>>> Remove the extra spaces. >>>> >>>> src/share/vm/opto/mathexactnode.hpp: >>>> >>>> + MathExactNode(Node* ctrl, Node* n1); >>>> MathExactNode(Node* ctrl, Node* in1, Node* in2); >>>> >>>> Should "n1" be "in1"? Or maybe just "n". >>>> >>>> These have two copyright headers: >>>> >>>> test/compiler/intrinsics/mathexact/IncExactITest.java >>>> test/compiler/intrinsics/mathexact/IncExactLTest.java >>>> >>>> It seems all of the tests have a wrong bug number: >>>> >>>> 26 * @bug 8024924 >>>> >>>> or >>>> >>>> 26 * @bug 8025657 >>>> >>>> test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: >>>> >>>> 28 * @compile MulExactIRepeatTest.java >>>> >>>> That one doesn't compile Verify.java. Please check all of the test files for these issue. >>>> >>>> In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? >>>> >>>> The question is do we really need individual test files for these? I don't object just mentioning it. >>>> >>>>> On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: >>>>> >>>>> Hi, can I get reviews for the following change: >>>>> >>>>> This change creates intrinsics for addExact(long, long), subtractExact, >>>>> negateExact, incrementExact, decrementExact and multiplyExact. >>>>> >>>>> The intrinsics are only added on x86 and only 64-bit has the intrinsics >>>>> for the long-versions. (32-bit only has int-versions). >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 >>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ >>>>> >>>>> Thanks >>>>> /R >>> /R > /R From vladimir.kozlov at oracle.com Wed Oct 23 09:53:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Oct 2013 12:53:31 -0400 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <19038A39-0BB7-4B47-97EB-BD016289A487@oracle.com> References: <52668A55.40605@oracle.com> <19038A39-0BB7-4B47-97EB-BD016289A487@oracle.com> Message-ID: <1A764289-A4AE-4EDD-9B57-AD23178595AD@oracle.com> Albert, I saw this change is pushed and I am fine with this. But, as Igor said, please file new bug and investigate it when you have time. Thanks, Vladimir > On Oct 22, 2013, at 2:17 PM, Igor Veresov wrote: > > What if there's no space to create the wrapper? Do we crash? > I guess the workaround is ok for now, but please file a new bug to investigate. > > igor > >> On Oct 22, 2013, at 7:23 AM, Albert Noll wrote: >> >> Hi all, >> >> I worked on this bug for some time but so far I was not able to determine its root cause. >> However, I have found a work around that hides the problem. Since it is important >> for the embedded version of hotspot to work with small code cache sizes + nashorn, >> I would suggest to apply this workaround, and file another bug that investigates the problem >> (e.g., a P4) that we can defer. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8026407 >> webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ >> >> problem: If we do not create native wrapper for method handle intrinsics, we get >> segfaults in compiled code. Also, if -XX:VerifyAdapterCalls is enabled, we >> get: >> >> assert(false) failed: DEBUG MESSAGE: i2c adapter must return to an interpreter frame >> >> The bug seems to be specific to method handle intrinsics. I assume that we either call >> the wrong entry point to a compiled method, or there is a bug somewhere in the generated >> adapters. Method handle intrinsics are treated specifically in various parts of the code and >> I do not yet really understand everything. >> >> solution: As mentioned above, the solution is a workaround and does not solve the real problem. >> Nevertheless it improves stability of hotspot and the impact of the proposed changes are >> marginal. >> >> testing: Running nashorn with small code cache size (3m) on PPC and x86 >> >> There will be a separate mail for closed part changes. >> >> Many thanks in advance, >> Albert >> >> P.S.: If anyone has an idea of where the problem could be, please let me know! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131023/a61a1e27/attachment.html From john.r.rose at oracle.com Wed Oct 23 09:59:23 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 23 Oct 2013 09:59:23 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <5267D401.6070403@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> <5267D401.6070403@oracle.com> Message-ID: <420AA490-51F4-459C-982A-606F885FD575@oracle.com> I have a question: The amended free_entry function indirectly unlinks the selected 'entry', but may also unlink other entries with the same hash and fingerprint. Isn't this working against the use for free_entry, where a pre-existing shared_entry is to be favored and returned? Won't the shared_entry be unlinked also? That would seem to lead to a storage leak. (Minor style nit: You code the hash comparison and key comparison as nested ifs; they would be just as readable connected by an '&&', and with less nesting.) ? John On Oct 23, 2013, at 6:49 AM, Albert Noll wrote: > Hi, > > unfortunately, the patch was not correct, as revealed by jprt. > The problem was that entries into the hashmap are not removed > correctly. > > This version fixes the problem. The patch is currently in jprt. > So far, everything looks good. > > Many thanks for another round. Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8026478/webrev.03/ > > Best, > Albert > > > On 16.10.2013 19:43, Christian Thalinger wrote: >> It would be nice to have a comment on this guy: >> + bool _contains_all_checks; >> No need for another webrev if you decide to add the comment. >> >> Looks good. >> >> On Oct 15, 2013, at 11:02 PM, Albert Noll wrote: >> >>> Forgot to adjust the comment. This version should be fine. >>> >>> http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ >>> >>> Albert >>> >>> On 15.10.2013 21:03, Vladimir Kozlov wrote: >>>> Albert, >>>> >>>> contains_all_stubs name is incorrect. It should be contains_all_checks. Adapter code does not have stubs in it. >>>> >>>> I think the next check should be: >>>> >>>> bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; >>>> >>>> because code does not change when VerifyAdapterCalls is false. >>>> Then you don't need to check VerifyAdapterCalls in next condition: >>>> >>>> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && !entry->contains_all_checks()) { >>>> >>>> And we need to regenerate adapter regardless VerifyAdapterSharing because, as you said, VerifyAdapterCalls potentially reports a false error if check for code2 is not generated. >>>> >>>> So the condition should be simple "if (!entry->contains_all_checks())". >>>> >>>> Could you leave next lines unchanged (use 2 lines for arguments)?: >>>> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >>>> >>>> sizeof(buffer_locs)/sizeof(relocInfo)); >>>> MacroAssembler _masm(&buffer); >>>> >>>> Cleanup is fine. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/15/13 4:14 AM, Albert Noll wrote: >>>>> Hi, >>>>> >>>>> could I have reviews for this small patch? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>>>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>>>> >>>>> >>>>> Problem: This flag is broken. The reason is that adapters >>>>> (gen_i2c_adapter()) that are generated during VM startup do not include >>>>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>>>> specified. StubRoutines::code2() is only allocated later during startup; >>>>> consequently, code2() is NULL. As a result, the size of the generated >>>>> adapter as well as the code itself does not mactch. >>>>> >>>>> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >>>>> Note that this patch also fixes potential issues with >>>>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>>>> removes some unused field of VerifyAdapterSharing. >>>>> >>>>> >>>>> Many thanks in advance, >>>>> Albert >>>>> ** >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131023/6efbeedf/attachment-0001.html From vladimir.kozlov at oracle.com Wed Oct 23 10:13:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Oct 2013 13:13:01 -0400 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> <20131022135635.GF13244@rbackman> <20131023132446.GL13244@rbackman> Message-ID: <31C5312A-CEF7-4CBA-9C9B-A67FCED916CA@oracle.com> > On Oct 23, 2013, at 12:45 PM, Vladimir Kozlov wrote: > > Looks good to me. May be not. I missed that you removed your changes in final graph reshape for phi node. You misinterpreted my comment. I said split through phi optimization should not be done. If phi come from loop code - it is different issue. I think you can keep your code for phi otherwise you may get problems, Thanks, Vladimir > > Thanks, > Vladimir > >> On Oct 23, 2013, at 9:24 AM, Rickard B?ckman wrote: >> >> Vladimir, thanks for taking time to look at this. See inline. >> >>> On 10/23, Vladimir Kozlov wrote: >>> Richard, >>> >>> Node.hpp and corresponding constructors. You should specify id only for MathExact class since you only need query method for it (no need to specify it for subclasses). The number in DEFINE_CLASS_ID should be 4 (not 7) since the last one (for Membar) was 3. >> >> Ok. >> >>> >>> I do not understand your problem with shared nodes (matcher.cpp changes). Sharing means that separate Mach node will be generated (it will not be part of mega Mach node). So I do not see the problem. Is it load nodes you have problem with? Please, explain. >> >> Removed. is_shared is also passed as an argument to match_into_reg. If >> shared we will never put it into a register. >> >>> About phi node. Look if it is created by spit_through_phi optimization. We should not do that because if addexact, for example, collapsed/folded on one branch how we get flag value from this branch. >> >> The Phi was (part of) an induction variable in this case. >> >> New webrev: http://cr.openjdk.java.net/~rbackman/8026844.2/ >> >> Thanks! >> >>> >>> Thanks, >>> Vladimir >>> >>>> On Oct 22, 2013, at 9:56 AM, Rickard B?ckman wrote: >>>> >>>> Christian, >>>> >>>> new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ >>>> The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ >>>> (I missed x86_32.ad when generating it, but everything else should be >>>> there). >>>> >>>> I removed the timeouts, they were remains of another attempt at writing >>>> tests. >>>> >>>> Thanks >>>> >>>>> On 10/18, Christian Thalinger wrote: >>>>> src/share/vm/opto/library_call.cpp: >>>>> >>>>> + Node* arg1 = argument(0); // type long >>>>> + // argument(1) == TOP >>>>> + Node* arg2 = argument(2); // type long >>>>> + // argument(4) == TOP >>>>> >>>>> The "argument(4)" comment it wrong; should be 3. >>>>> >>>>> + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); >>>>> >>>>> Remove the extra spaces. >>>>> >>>>> src/share/vm/opto/mathexactnode.hpp: >>>>> >>>>> + MathExactNode(Node* ctrl, Node* n1); >>>>> MathExactNode(Node* ctrl, Node* in1, Node* in2); >>>>> >>>>> Should "n1" be "in1"? Or maybe just "n". >>>>> >>>>> These have two copyright headers: >>>>> >>>>> test/compiler/intrinsics/mathexact/IncExactITest.java >>>>> test/compiler/intrinsics/mathexact/IncExactLTest.java >>>>> >>>>> It seems all of the tests have a wrong bug number: >>>>> >>>>> 26 * @bug 8024924 >>>>> >>>>> or >>>>> >>>>> 26 * @bug 8025657 >>>>> >>>>> test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: >>>>> >>>>> 28 * @compile MulExactIRepeatTest.java >>>>> >>>>> That one doesn't compile Verify.java. Please check all of the test files for these issue. >>>>> >>>>> In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? >>>>> >>>>> The question is do we really need individual test files for these? I don't object just mentioning it. >>>>> >>>>>> On Oct 18, 2013, at 2:34 AM, Rickard B?ckman wrote: >>>>>> >>>>>> Hi, can I get reviews for the following change: >>>>>> >>>>>> This change creates intrinsics for addExact(long, long), subtractExact, >>>>>> negateExact, incrementExact, decrementExact and multiplyExact. >>>>>> >>>>>> The intrinsics are only added on x86 and only 64-bit has the intrinsics >>>>>> for the long-versions. (32-bit only has int-versions). >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 >>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ >>>>>> >>>>>> Thanks >>>>>> /R >>>> /R >> /R From john.r.rose at oracle.com Wed Oct 23 10:25:54 2013 From: john.r.rose at oracle.com (John Rose) Date: Wed, 23 Oct 2013 10:25:54 -0700 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: References: <52668A55.40605@oracle.com> Message-ID: On Oct 22, 2013, at 4:25 PM, Christian Thalinger wrote: > > On Oct 22, 2013, at 7:23 AM, Albert Noll wrote: > >> Hi all, >> >> I worked on this bug for some time but so far I was not able to determine its root cause. >> However, I have found a work around that hides the problem. Since it is important >> for the embedded version of hotspot to work with small code cache sizes + nashorn, >> I would suggest to apply this workaround, and file another bug that investigates the problem >> (e.g., a P4) that we can defer. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8026407 >> webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ >> >> problem: If we do not create native wrapper for method handle intrinsics, we get >> segfaults in compiled code. Also, if -XX:VerifyAdapterCalls is enabled, we >> get: >> >> assert(false) failed: DEBUG MESSAGE: i2c adapter must return to an interpreter frame >> >> The bug seems to be specific to method handle intrinsics. I assume that we either call >> the wrong entry point to a compiled method, or there is a bug somewhere in the generated >> adapters. Method handle intrinsics are treated specifically in various parts of the code and >> I do not yet really understand everything. > > I can tell you why (as could John): in order to properly handle the appendix argument for out-of-line calls we are using a small trampoline that pops off the appendix argument and jumps to the target (see gen_special_dispatch in SharedRuntime). > > Since normal compiled-to-compiled calls are not able to handle such a thing we MUST generate an adapter in this case. If we can't generate one and use it we can not execute the out-of-line method handle calls. > Thanks, Chris; that's correct. Albert, I think you are seeing edge cases (common enough when memory is tight) where compiled code A gets successfully compiled but a stub B that it needs fails to compile. If this is so, the order of compilation needs to change somehow so that B precedes A, or else A needs to ensure that B compiles before A needs it. An analogous case is the i2c/c2i adapters for all methods. There was a time (IIRC) that they were generated more lazily, but we had to make them eager, since we could get the same failure pattern: A compiles but B doesn't, where B is the i2c or c2i adapter. A third option, which I would prefer if it were feasible, would be to make the compiled paths for the method handle stubs always inlined into the compiled code. But this is probably difficult, because method handles can point to method handle methods (and do pretty often!), so that it is not always possible for the compiler to know that a call will need to go through a stub's compiled entry point. There are ways around this also, but it's tricky. It seems likely to me that there is some kind of economical way to make sure that the stubs (B) are always created before their users (A) get compiled. Albert, thank you for dissecting this, and so many other gnarly code storage issues. ? John >> solution: As mentioned above, the solution is a workaround and does not solve the real problem. >> Nevertheless it improves stability of hotspot and the impact of the proposed changes are >> marginal. >> >> testing: Running nashorn with small code cache size (3m) on PPC and x86 >> >> There will be a separate mail for closed part changes. >> >> Many thanks in advance, >> Albert >> >> P.S.: If anyone has an idea of where the problem could be, please let me know! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131023/58275fa5/attachment.html From christian.thalinger at oracle.com Wed Oct 23 10:27:38 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Oct 2013 10:27:38 -0700 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: <5267E0D2.1050605@oracle.com> References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> <525FDC25.30805@oracle.com> <5260F071.6080708@oracle.com> <5267E0D2.1050605@oracle.com> Message-ID: Looks good. On Oct 23, 2013, at 7:44 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8023004/webrev.01/ > 3 lines changed: 0 ins; 2 del; 1 mod > > Reviewed-by: jrose, ? > > The fix is to skip MemberNameTable update in MHN_getMemberVMInfo. > > I filed a followup bug to implement MemberName interning [1]. It should eliminate possibility of MemberNameTable elements overwrite. > > Testing: failing testcase. > > Contributed-by: sspitsyn > > JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8027162 > > On 10/18/13 8:47 PM, Christian Thalinger wrote: >> >> On Oct 18, 2013, at 1:25 AM, serguei.spitsyn at oracle.com wrote: >> >>> Vladimir, >>> >>> >>> Just want to share some details with you. >>> >>> >>> On 10/17/13 5:46 AM, Vladimir Ivanov wrote: >>>> Serguei, Chris, Igor, thanks for looking at this fix. >>>> >>>> I need to look more thoroughly at this code. >>>> I assumed that member name is initialized only once, but I was wrong - asserting empty slot in MethodHandles::init_method_MemberName fails during initialization of JSR292 core classes. >>> >>> John or Chris, please, correct me if I'm wrong... >>> But, I think, John had a plan in mind to utilize the MNT for uniqueness of member names. >>> It was about all member names, not only method member names. >> >> Correct. It is worrying that the assert fires. We should get to the bottom of this and fix it properly. >> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: >>>>> On 10/16/13 1:28 PM, Christian Thalinger wrote: >>>>>> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >>>>>> wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>>>>>> 7 lines changed: 5 ins; 1 del; 1 mod >>>>>>> >>>>>>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>>>>>> assert(m.vminfoIsConsistent()); >>>>>>> >>>>>>> After that check, class redefinition is broken - it's still possible >>>>>>> to invoke old version of a method. >>>>>>> >>>>>>> Analysis from Serguei: >>>>>>> "The problem is here: >>>>>>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>>>>>> info) { >>>>>>> . . . . . . . . >>>>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>>>> >>>>>>> return mname(); >>>>>>> } >>>>>>> >>>>>>> The call to add_member_name() resets the member name at the index >>>>>>> m->method_idnum(). After that one of the two member names with the >>>>>>> same method_idnum() is out of the MNT and is not updated when the >>>>>>> method is redefined." >>>>>> As I understand this the problem is calling >>>>>> MethodHandles::init_method_MemberName which installs a new MemberName >>>>>> instance in the MemberNameTable. Correct? >>>>>> >>>>>> If that's the case then there is a potential race here. >>>>>> >>>>>> + x = m->method_holder()->get_member_name(m->method_idnum()); >>>>>> + if (x == NULL) { >>>>>> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >>>>>> x = MethodHandles::init_method_MemberName(mname2, info); >>>>>> } >>>>>> >>>>>> Racing threads can get back null when calling get_member_name and then >>>>>> install different MemberName objects in the table. >>>>> >>>>> Good catch, Chris. >>>>> I do not see a way to fix it easily without some refactoring. >>>>> >>>>> It is probably better to add to the InstanceKlass a helper function that >>>>> will do >>>>> this dance with a required synchronization. >>>>> But the following line needs to be taken out of the >>>>> init_method_MemberName() : >>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>>> The fix is to check whether there's already a member name associated >>>>>>> with the before creating a new one. >>>>>>> >>>>>>> Testing: failing test. >>>>>>> >>>>>>> Contributed-by: sspitsyn, vlivanov >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >>>>> >>> >> From christian.thalinger at oracle.com Wed Oct 23 10:41:31 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 23 Oct 2013 10:41:31 -0700 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: References: <52668A55.40605@oracle.com> Message-ID: <2345C523-E41B-4E62-8EC1-35DFE994E9FE@oracle.com> On Oct 23, 2013, at 10:25 AM, John Rose wrote: > On Oct 22, 2013, at 4:25 PM, Christian Thalinger wrote: > >> >> On Oct 22, 2013, at 7:23 AM, Albert Noll wrote: >> >>> Hi all, >>> >>> I worked on this bug for some time but so far I was not able to determine its root cause. >>> However, I have found a work around that hides the problem. Since it is important >>> for the embedded version of hotspot to work with small code cache sizes + nashorn, >>> I would suggest to apply this workaround, and file another bug that investigates the problem >>> (e.g., a P4) that we can defer. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8026407 >>> webrev: http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ >>> >>> problem: If we do not create native wrapper for method handle intrinsics, we get >>> segfaults in compiled code. Also, if -XX:VerifyAdapterCalls is enabled, we >>> get: >>> >>> assert(false) failed: DEBUG MESSAGE: i2c adapter must return to an interpreter frame >>> >>> The bug seems to be specific to method handle intrinsics. I assume that we either call >>> the wrong entry point to a compiled method, or there is a bug somewhere in the generated >>> adapters. Method handle intrinsics are treated specifically in various parts of the code and >>> I do not yet really understand everything. >> >> I can tell you why (as could John): in order to properly handle the appendix argument for out-of-line calls we are using a small trampoline that pops off the appendix argument and jumps to the target (see gen_special_dispatch in SharedRuntime). >> >> Since normal compiled-to-compiled calls are not able to handle such a thing we MUST generate an adapter in this case. If we can't generate one and use it we can not execute the out-of-line method handle calls. >> > > Thanks, Chris; that's correct. > > Albert, I think you are seeing edge cases (common enough when memory is tight) where compiled code A gets successfully compiled but a stub B that it needs fails to compile. > > If this is so, the order of compilation needs to change somehow so that B precedes A, or else A needs to ensure that B compiles before A needs it. > > An analogous case is the i2c/c2i adapters for all methods. There was a time (IIRC) that they were generated more lazily, but we had to make them eager, since we could get the same failure pattern: A compiles but B doesn't, where B is the i2c or c2i adapter. That is some interesting bit of history and finally gives an answer to my question why the I2C/C2I adapters are eagerly generated. The reason why I stumbled across this a couple weeks ago is I wanted to see if we can generate some (all?) of our adapters from snippet type code and not have handwritten assembler code for them. > > A third option, which I would prefer if it were feasible, would be to make the compiled paths for the method handle stubs always inlined into the compiled code. But this is probably difficult, because method handles can point to method handle methods (and do pretty often!), so that it is not always possible for the compiler to know that a call will need to go through a stub's compiled entry point. There are ways around this also, but it's tricky. > > It seems likely to me that there is some kind of economical way to make sure that the stubs (B) are always created before their users (A) get compiled. > > Albert, thank you for dissecting this, and so many other gnarly code storage issues. > > ? John > > >>> solution: As mentioned above, the solution is a workaround and does not solve the real problem. >>> Nevertheless it improves stability of hotspot and the impact of the proposed changes are >>> marginal. >>> >>> testing: Running nashorn with small code cache size (3m) on PPC and x86 >>> >>> There will be a separate mail for closed part changes. >>> >>> Many thanks in advance, >>> Albert >>> >>> P.S.: If anyone has an idea of where the problem could be, please let me know! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131023/5b2e5a15/attachment-0001.html From rickard.backman at oracle.com Wed Oct 23 12:05:05 2013 From: rickard.backman at oracle.com (Rickard B??ckman) Date: Wed, 23 Oct 2013 21:05:05 +0200 Subject: RFR(L) 8026844: Various Math functions needs intrinsification In-Reply-To: <31C5312A-CEF7-4CBA-9C9B-A67FCED916CA@oracle.com> References: <20131018093454.GC17703@rbackman> <0CACF678-19AD-4DB0-AB15-7CBEE59E8B22@oracle.com> <20131022135635.GF13244@rbackman> <20131023132446.GL13244@rbackman> <31C5312A-CEF7-4CBA-9C9B-A67FCED916CA@oracle.com> Message-ID: <20131023190505.GA24064@rbackman> Vladimir, there must have been a mistake somewhere, the change in compile.cpp checking for Phi nodes was part of another change that has already been pushed. Here: 8026959: assert(!n->pinned() || n->is_MachConstantBase()) failed: only pinned MachConstantBase node is expected here Thanks On 10/23, Vladimir Kozlov wrote: > > > On Oct 23, 2013, at 12:45 PM, Vladimir Kozlov wrote: > > > > Looks good to me. > > May be not. I missed that you removed your changes in final graph reshape for phi node. You misinterpreted my comment. I said split through phi optimization should not be done. If phi come from loop code - it is different issue. I think you can keep your code for phi otherwise you may get problems, > > Thanks, > Vladimir > > > > > Thanks, > > Vladimir > > > >> On Oct 23, 2013, at 9:24 AM, Rickard B??ckman wrote: > >> > >> Vladimir, thanks for taking time to look at this. See inline. > >> > >>> On 10/23, Vladimir Kozlov wrote: > >>> Richard, > >>> > >>> Node.hpp and corresponding constructors. You should specify id only for MathExact class since you only need query method for it (no need to specify it for subclasses). The number in DEFINE_CLASS_ID should be 4 (not 7) since the last one (for Membar) was 3. > >> > >> Ok. > >> > >>> > >>> I do not understand your problem with shared nodes (matcher.cpp changes). Sharing means that separate Mach node will be generated (it will not be part of mega Mach node). So I do not see the problem. Is it load nodes you have problem with? Please, explain. > >> > >> Removed. is_shared is also passed as an argument to match_into_reg. If > >> shared we will never put it into a register. > >> > >>> About phi node. Look if it is created by spit_through_phi optimization. We should not do that because if addexact, for example, collapsed/folded on one branch how we get flag value from this branch. > >> > >> The Phi was (part of) an induction variable in this case. > >> > >> New webrev: http://cr.openjdk.java.net/~rbackman/8026844.2/ > >> > >> Thanks! > >> > >>> > >>> Thanks, > >>> Vladimir > >>> > >>>> On Oct 22, 2013, at 9:56 AM, Rickard B??ckman wrote: > >>>> > >>>> Christian, > >>>> > >>>> new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/ > >>>> The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/ > >>>> (I missed x86_32.ad when generating it, but everything else should be > >>>> there). > >>>> > >>>> I removed the timeouts, they were remains of another attempt at writing > >>>> tests. > >>>> > >>>> Thanks > >>>> > >>>>> On 10/18, Christian Thalinger wrote: > >>>>> src/share/vm/opto/library_call.cpp: > >>>>> > >>>>> + Node* arg1 = argument(0); // type long > >>>>> + // argument(1) == TOP > >>>>> + Node* arg2 = argument(2); // type long > >>>>> + // argument(4) == TOP > >>>>> > >>>>> The "argument(4)" comment it wrong; should be 3. > >>>>> > >>>>> + Node* add = _gvn.transform( new(C) AddExactLNode(NULL, arg1, arg2) ); > >>>>> > >>>>> Remove the extra spaces. > >>>>> > >>>>> src/share/vm/opto/mathexactnode.hpp: > >>>>> > >>>>> + MathExactNode(Node* ctrl, Node* n1); > >>>>> MathExactNode(Node* ctrl, Node* in1, Node* in2); > >>>>> > >>>>> Should "n1" be "in1"? Or maybe just "n". > >>>>> > >>>>> These have two copyright headers: > >>>>> > >>>>> test/compiler/intrinsics/mathexact/IncExactITest.java > >>>>> test/compiler/intrinsics/mathexact/IncExactLTest.java > >>>>> > >>>>> It seems all of the tests have a wrong bug number: > >>>>> > >>>>> 26 * @bug 8024924 > >>>>> > >>>>> or > >>>>> > >>>>> 26 * @bug 8025657 > >>>>> > >>>>> test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java: > >>>>> > >>>>> 28 * @compile MulExactIRepeatTest.java > >>>>> > >>>>> That one doesn't compile Verify.java. Please check all of the test files for these issue. > >>>>> > >>>>> In some test files you have timeouts. Will there be a timeout problem on slower embedded platforms? > >>>>> > >>>>> The question is do we really need individual test files for these? I don't object just mentioning it. > >>>>> > >>>>>> On Oct 18, 2013, at 2:34 AM, Rickard B??ckman wrote: > >>>>>> > >>>>>> Hi, can I get reviews for the following change: > >>>>>> > >>>>>> This change creates intrinsics for addExact(long, long), subtractExact, > >>>>>> negateExact, incrementExact, decrementExact and multiplyExact. > >>>>>> > >>>>>> The intrinsics are only added on x86 and only 64-bit has the intrinsics > >>>>>> for the long-versions. (32-bit only has int-versions). > >>>>>> > >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026844 > >>>>>> Webrev: http://cr.openjdk.java.net/~rbackman/8026844/ > >>>>>> > >>>>>> Thanks > >>>>>> /R > >>>> /R > >> /R /R From niclas.adlertz at oracle.com Wed Oct 23 15:00:41 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Wed, 23 Oct 2013 22:00:41 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131023220108.20548626B1@hg.openjdk.java.net> Changeset: 4c9115774c8e Author: adlertz Date: 2013-10-23 10:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4c9115774c8e 8026939: assert(Reachblock != NULL) failed: Reachblock must be non-NULL Summary: We can reach this state from phi input rematerialization, so pass in the Reaches of the predecessor Reviewed-by: roland, twisti ! src/share/vm/opto/reg_split.cpp Changeset: 97d400662426 Author: adlertz Date: 2013-10-23 19:22 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/97d400662426 Merge From igor.veresov at oracle.com Wed Oct 23 19:16:27 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 24 Oct 2013 02:16:27 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 3 new changesets Message-ID: <20131024021641.709F1626C0@hg.openjdk.java.net> Changeset: 9acbfe04b5c3 Author: iveresov Date: 2013-10-23 11:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9acbfe04b5c3 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64 Summary: Fix wrong calling convention in LIR_Assembler::emit_unwind_handler(), T_METADATA support in calling convention generator, C1 register allocator Reviewed-by: twisti, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp Changeset: 1c90f0072f0d Author: twisti Date: 2013-10-23 15:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1c90f0072f0d 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3a04e444da6d Author: iveresov Date: 2013-10-23 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3a04e444da6d Merge From albert.noll at oracle.com Wed Oct 23 21:54:13 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 24 Oct 2013 06:54:13 +0200 Subject: RFR(S): 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) In-Reply-To: <52679E8A.5080407@oracle.com> References: <5266CF8C.70305@oracle.com> <4FC15972-1DE4-4579-BE25-ACAAFB981B16@oracle.com> <52677F53.4020309@oracle.com> <526785AD.60506@oracle.com> <130D94A0-9879-4A61-9611-0E2223C89999@oracle.com> <52679B0E.1000404@oracle.com> <52679E8A.5080407@oracle.com> Message-ID: <5268A7F5.4010108@oracle.com> Hi, I guess this bug can be considered as reviewed. Since it is only a minor issue, I guess it is fine if we push it after ZBB. Best, Albert On 23.10.2013 12:01, Igor Ignatyev wrote: > Yes, I'm fine w/ the latest version. > > Best regards, > Igor Ignatyev > > On 10/23/2013 01:46 PM, Albert Noll wrote: >> Thank you, Igor! >> >> Best, >> Albert >> >> On 23.10.2013 11:25, Igor Veresov wrote: >>> I think the latest version is fine. >>> >>> igor >>> >>> On Oct 23, 2013, at 1:15 AM, Albert Noll >>> wrote: >>> >>>> Hi Igor, >>>> >>>> are you fine with the lastest version, or should I add the >>>> -XX:+DisplayVMOutputToStdout to the test? >>>> >>>> Best, >>>> Albert >>>> >>>> On 23.10.2013 09:48, Igor Ignatyev wrote: >>>>>> Is this testing the full output or only the first line? >>>>> full output, but '-version' by default uses stderr, so stdouts >>>>> should be empty and equal. >>>>> I think it would be better to add vm flags to explicitly use of >>>>> stdout for warnings -- -XX:+DisplayVMOutputToStdout. >>>>> >>>>> Best regards, >>>>> Igor Ignatyev >>>>> >>>>> On 10/23/2013 04:45 AM, Christian Thalinger wrote: >>>>>> 44 // Check that the outputs are equal >>>>>> 45 if (out1.getStdout().compareTo(out2.getStdout()) != 0) { >>>>>> >>>>>> Is this testing the full output or only the first line? Because the >>>>>> outputs are not equal: >>>>>> >>>>>> $ java -Xint -version >>>>>> java version "1.8.0-ea" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>> 25.0-b56-internal-fastdebug, >>>>>> interpreted mode) >>>>>> >>>>>> $ java -Xcomp -version >>>>>> java version "1.8.0-ea" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0-ea-b109) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>> 25.0-b56-internal-fastdebug, >>>>>> compiled mode) >>>>>> >>>>>> >>>>>> On Oct 22, 2013, at 12:18 PM, Albert Noll >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> sure, here is the patch including the test: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.02/ >>>>>>> >>>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> On 22.10.2013 20:34, igor.ignatyev at oracle.com wrote: >>>>>>>> Albert, please add a jtreg test for this change. I think it is >>>>>>>> very >>>>>>>> easy: just start 'java -version' as a external process and >>>>>>>> check its >>>>>>>> output in 'Xint' and '-Xcomp' cases. If you don't think so, please >>>>>>>> file a RFE to add regression test and assign it to me. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> - Igor >>>>>>>> >>>>>>>> ----- Reply message ----- >>>>>>>> From: "Albert Noll" >>>>>>>> To: "Igor Veresov" >>>>>>>> Cc: "hotspot-compiler-dev at openjdk.java.net" >>>>>>>> >>>>>>>> Subject: RFR(S): 8026949: -Xint flag prints wrong warning: >>>>>>>> Initialization of C1 thread failed (no space to run compilers) >>>>>>>> Date: Tue, Oct 22, 2013 22:03 >>>>>>>> >>>>>>>> Roland, Igor, thanks for looking at this. >>>>>>>> >>>>>>>> I tested the patch as follows: >>>>>>>> >>>>>>>> java -Xint -version .. make sure that output does not appear >>>>>>>> java -Xcomp -version make sure that compiler(s) are working >>>>>>>> >>>>>>>> Execution of nashorn octane + some DaCapo benchmarks. (with -Xint >>>>>>>> and >>>>>>>> -Xcomp and -Xmixed) >>>>>>>> >>>>>>>> Seems to work fine. >>>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> On 22.10.2013 19:12, Igor Veresov wrote: >>>>>>>>> Looks good. >>>>>>>>> >>>>>>>>> igor >>>>>>>>> >>>>>>>>> On Oct 22, 2013, at 6:15 AM, Albert Noll >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Thanks Igor. This is a good solution. >>>>>>>>>> >>>>>>>>>> Here is the webrev: >>>>>>>>>> http://cr.openjdk.java.net/~anoll/8026949/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Albert >>>>>>>>>> >>>>>>>>>> On 22.10.2013 08:41, Igor Veresov wrote: >>>>>>>>>>> Another trivial fix option is to just bail out >>>>>>>>>>> of CompileBroker::compilation_init() is UseCompiler is >>>>>>>>>>> false. To >>>>>>>>>>> avoid initializing the compiler objects and all.. >>>>>>>>>>> >>>>>>>>>>> igor >>>>>>>>>>> >>>>>>>>>>> On Oct 21, 2013, at 11:15 PM, Albert Noll >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Christian, Igor, thanks for the reviews. >>>>>>>>>>>> >>>>>>>>>>>> There seems to be an ambiguity between -Xint and >>>>>>>>>>>> -XX:+UseCompiler. Whether we use a compiler or >>>>>>>>>>>> not, depends on the order in which the arguments are given. >>>>>>>>>>>> I am >>>>>>>>>>>> not exactly sure why we have >>>>>>>>>>>> the -XX:(+/-)UseCompiler flag at all, also as a product flag. >>>>>>>>>>>> >>>>>>>>>>>> The reason why I added the checks when we determine the >>>>>>>>>>>> number of >>>>>>>>>>>> compiler threads is that we >>>>>>>>>>>> do not generate the compiler objects (they are not needed). >>>>>>>>>>>> Also, >>>>>>>>>>>> the number of compiler threads >>>>>>>>>>>> is set correctly. >>>>>>>>>>>> >>>>>>>>>>>> The solution proposed by Igor is simpler. If the above >>>>>>>>>>>> issues do >>>>>>>>>>>> not matter, I would also opt for the >>>>>>>>>>>> simple solution. >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Albert >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 22.10.2013 06:17, Igor Veresov wrote: >>>>>>>>>>>>> If think you can just use the existing "UseCompiler" flag, >>>>>>>>>>>>> that >>>>>>>>>>>>> we set to false when -Xint is specified and just not call >>>>>>>>>>>>> init_compiler_threads() if UseCompiler == false. >>>>>>>>>>>>> >>>>>>>>>>>>> igor >>>>>>>>>>>>> >>>>>>>>>>>>> On Oct 21, 2013, at 2:54 AM, Albert Noll >>>>>>>>>>>>> >>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> could I have reviews for this small patch? >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8026949 >>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026949/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Problem: 8023014 introduced a wrong warning: >>>>>>>>>>>>>> Initialization of >>>>>>>>>>>>>> C1 thread failed (no space to run compilers) when the VM is >>>>>>>>>>>>>> started >>>>>>>>>>>>>> with -Xint >>>>>>>>>>>>>> >>>>>>>>>>>>>> Solution: Do not start compiler threads if VM is started >>>>>>>>>>>>>> with -Xint >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: -Xint flag does not print out the false warning. >>>>>>>>>>>>>> Tested flag combinations: >>>>>>>>>>>>>> -XX:+TieredCompilation -Xint (-server / -client) >>>>>>>>>>>>>> -XX:-TieredCompilation -Xint (-server / -client) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Many thanks in advance, >>>>>>>>>>>>>> Albert >>>>>>>>>>>>>> >> From rickard.backman at oracle.com Thu Oct 24 00:29:23 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 24 Oct 2013 07:29:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026844: Various Math functions needs intrinsification Message-ID: <20131024072930.EA2B6626C8@hg.openjdk.java.net> Changeset: 59e8ad757e19 Author: rbackman Date: 2013-10-18 10:41 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/59e8ad757e19 8026844: Various Math functions needs intrinsification Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/mathexactnode.cpp ! src/share/vm/opto/mathexactnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/vmStructs.cpp + test/compiler/intrinsics/mathexact/AddExactICondTest.java + test/compiler/intrinsics/mathexact/AddExactIConstantTest.java + test/compiler/intrinsics/mathexact/AddExactILoadTest.java + test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java + test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java + test/compiler/intrinsics/mathexact/AddExactLConstantTest.java + test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java + test/compiler/intrinsics/mathexact/DecExactITest.java + test/compiler/intrinsics/mathexact/DecExactLTest.java + test/compiler/intrinsics/mathexact/IncExactITest.java + test/compiler/intrinsics/mathexact/IncExactLTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactICondTest.java + test/compiler/intrinsics/mathexact/MulExactIConstantTest.java + test/compiler/intrinsics/mathexact/MulExactILoadTest.java + test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java + test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java + test/compiler/intrinsics/mathexact/MulExactLConstantTest.java + test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactIConstantTest.java + test/compiler/intrinsics/mathexact/NegExactILoadTest.java + test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLConstantTest.java + test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java + test/compiler/intrinsics/mathexact/SubExactICondTest.java + test/compiler/intrinsics/mathexact/SubExactIConstantTest.java + test/compiler/intrinsics/mathexact/SubExactILoadTest.java + test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java + test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java + test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java + test/compiler/intrinsics/mathexact/SubExactLConstantTest.java + test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/Verify.java From albert.noll at oracle.com Thu Oct 24 01:01:38 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 24 Oct 2013 10:01:38 +0200 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <520301C5.20803@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> Message-ID: <5268D3E2.2070608@oracle.com> Hi, here is an updated version of this bug. In this version, compilation IDs are generated by using Atomic::add(). As a result, we should not need locks to provide a unique ID for each request. Also, in AdapterHandlerLibrary::create_native_wrapper(), set_code() is now called while holding the AdapterHandlerLibrary_lock. This should be fine, since set_code() does not use locks. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ Many thanks in advance, Albert On 08.08.2013 04:26, Vladimir Kozlov wrote: > I think the simplest solution would be to make > CompileBroker::assign_compile_id() public (note, it is static method) > and call it from create_native_wrapper(). > > Vladimir > > On 8/7/13 6:50 PM, John Rose wrote: >> On Aug 6, 2013, at 10:55 PM, Albert Noll > > wrote: >> >>> please review this small patch. >> >> It looks like you moved the test (for NULL) of method->code() outside of >> AdapterHandlerLibrary_lock. >> >> This means that there will be races where multiple threads race to >> request a native wrapper. They will all generate the code, sequentially >> grabbing AdapterHandlerLibrary_lock. I think this is unnecessary >> concurrency. I suggest that you keep the lines marked "See if somebody >> beat us to it". >> >> --- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/e07e8cae/attachment-0001.html From aleksey.shipilev at oracle.com Thu Oct 24 01:15:45 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 24 Oct 2013 12:15:45 +0400 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <5268D3E2.2070608@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> Message-ID: <5268D731.90904@oracle.com> On 10/24/2013 12:01 PM, Albert Noll wrote: > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ Nice to see the locking gone. compileBroker.cpp: * Is that considered correct that OSR and normal compilations are marked differently when running in debug mode, but not in release? I understand the comment before assign_compile_id, so this is more of the philosophical question. sharedRuntime.cpp: * Why do you need "2653 return;" in the method tail? Thanks, -Aleksey. From albert.noll at oracle.com Thu Oct 24 01:21:09 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 24 Oct 2013 10:21:09 +0200 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <5268D731.90904@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> Message-ID: <5268D875.5030506@oracle.com> Hi Aleksey, thanks for looking at this. On 24.10.2013 10:15, Aleksey Shipilev wrote: > On 10/24/2013 12:01 PM, Albert Noll wrote: >> Here is the updated webrev: >> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ > Nice to see the locking gone. > > compileBroker.cpp: > * Is that considered correct that OSR and normal compilations are > marked differently when running in debug mode, but not in release? I > understand the comment before assign_compile_id, so this is more of the > philosophical question. Compilation IDs are only different if -XX:CICountOSR is set, which is defaulted to false. > sharedRuntime.cpp: > * Why do you need "2653 return;" in the method tail? Thanks for spotting this. I missed it during the cleanup. Best, Albert > Thanks, > -Aleksey. From albert.noll at oracle.com Thu Oct 24 01:56:10 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 24 Oct 2013 10:56:10 +0200 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <5268D875.5030506@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> Message-ID: <5268E0AA.8060404@oracle.com> Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ Best, Albert On 24.10.2013 10:21, Albert Noll wrote: > Hi Aleksey, > > thanks for looking at this. > > On 24.10.2013 10:15, Aleksey Shipilev wrote: >> On 10/24/2013 12:01 PM, Albert Noll wrote: >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >> Nice to see the locking gone. >> >> compileBroker.cpp: >> * Is that considered correct that OSR and normal compilations are >> marked differently when running in debug mode, but not in release? I >> understand the comment before assign_compile_id, so this is more of the >> philosophical question. > Compilation IDs are only different if -XX:CICountOSR is set, which is > defaulted to false. >> sharedRuntime.cpp: >> * Why do you need "2653 return;" in the method tail? > Thanks for spotting this. I missed it during the cleanup. > > Best, > Albert >> Thanks, >> -Aleksey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/c5e909ac/attachment.html From aleksey.shipilev at oracle.com Thu Oct 24 02:03:31 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 24 Oct 2013 13:03:31 +0400 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <5268E0AA.8060404@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> Message-ID: <5268E263.70407@oracle.com> On 10/24/2013 12:56 PM, Albert Noll wrote: > http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ > Good with me. -Aleksey. From vladimir.x.ivanov at oracle.com Thu Oct 24 03:59:51 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 24 Oct 2013 14:59:51 +0400 Subject: RFR (XS): 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. In-Reply-To: References: <525C42C4.1090801@oracle.com> <0B94C48A-90C3-447E-A48E-1C2E3795B4DA@oracle.com> <525FB034.9000806@oracle.com> <525FDC25.30805@oracle.com> <5260F071.6080708@oracle.com> <5267E0D2.1050605@oracle.com> Message-ID: <5268FDA7.5030803@oracle.com> Thank you, Chris. Best regards, Vladimir Ivanov On 10/23/13 9:27 PM, Christian Thalinger wrote: > Looks good. > > On Oct 23, 2013, at 7:44 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.01/ >> 3 lines changed: 0 ins; 2 del; 1 mod >> >> Reviewed-by: jrose, ? >> >> The fix is to skip MemberNameTable update in MHN_getMemberVMInfo. >> >> I filed a followup bug to implement MemberName interning [1]. It should eliminate possibility of MemberNameTable elements overwrite. >> >> Testing: failing testcase. >> >> Contributed-by: sspitsyn >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8027162 >> >> On 10/18/13 8:47 PM, Christian Thalinger wrote: >>> >>> On Oct 18, 2013, at 1:25 AM, serguei.spitsyn at oracle.com wrote: >>> >>>> Vladimir, >>>> >>>> >>>> Just want to share some details with you. >>>> >>>> >>>> On 10/17/13 5:46 AM, Vladimir Ivanov wrote: >>>>> Serguei, Chris, Igor, thanks for looking at this fix. >>>>> >>>>> I need to look more thoroughly at this code. >>>>> I assumed that member name is initialized only once, but I was wrong - asserting empty slot in MethodHandles::init_method_MemberName fails during initialization of JSR292 core classes. >>>> >>>> John or Chris, please, correct me if I'm wrong... >>>> But, I think, John had a plan in mind to utilize the MNT for uniqueness of member names. >>>> It was about all member names, not only method member names. >>> >>> Correct. It is worrying that the assert fires. We should get to the bottom of this and fix it properly. >>> >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 10/17/13 1:39 PM, serguei.spitsyn at oracle.com wrote: >>>>>> On 10/16/13 1:28 PM, Christian Thalinger wrote: >>>>>>> On Oct 14, 2013, at 12:15 PM, Vladimir Ivanov >>>>>>> wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~vlivanov/8023004/webrev.00/ >>>>>>>> 7 lines changed: 5 ins; 1 del; 1 mod >>>>>>>> >>>>>>>> Assertion code in JDK fetches info from VM using MHN.getMemberVMInfo: >>>>>>>> assert(m.vminfoIsConsistent()); >>>>>>>> >>>>>>>> After that check, class redefinition is broken - it's still possible >>>>>>>> to invoke old version of a method. >>>>>>>> >>>>>>>> Analysis from Serguei: >>>>>>>> "The problem is here: >>>>>>>> oop MethodHandles::init_method_MemberName(Handle mname, CallInfo& >>>>>>>> info) { >>>>>>>> . . . . . . . . >>>>>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>>>>> >>>>>>>> return mname(); >>>>>>>> } >>>>>>>> >>>>>>>> The call to add_member_name() resets the member name at the index >>>>>>>> m->method_idnum(). After that one of the two member names with the >>>>>>>> same method_idnum() is out of the MNT and is not updated when the >>>>>>>> method is redefined." >>>>>>> As I understand this the problem is calling >>>>>>> MethodHandles::init_method_MemberName which installs a new MemberName >>>>>>> instance in the MemberNameTable. Correct? >>>>>>> >>>>>>> If that's the case then there is a potential race here. >>>>>>> >>>>>>> + x = m->method_holder()->get_member_name(m->method_idnum()); >>>>>>> + if (x == NULL) { >>>>>>> + Handle mname2 = MethodHandles::new_MemberName(CHECK_NULL); >>>>>>> x = MethodHandles::init_method_MemberName(mname2, info); >>>>>>> } >>>>>>> >>>>>>> Racing threads can get back null when calling get_member_name and then >>>>>>> install different MemberName objects in the table. >>>>>> >>>>>> Good catch, Chris. >>>>>> I do not see a way to fix it easily without some refactoring. >>>>>> >>>>>> It is probably better to add to the InstanceKlass a helper function that >>>>>> will do >>>>>> this dance with a required synchronization. >>>>>> But the following line needs to be taken out of the >>>>>> init_method_MemberName() : >>>>>> m->method_holder()->add_member_name(m->method_idnum(), mname); >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>>> The fix is to check whether there's already a member name associated >>>>>>>> with the before creating a new one. >>>>>>>> >>>>>>>> Testing: failing test. >>>>>>>> >>>>>>>> Contributed-by: sspitsyn, vlivanov >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Vladimir Ivanov >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8023004 >>>>>> >>>> >>> > From albert.noll at oracle.com Thu Oct 24 05:30:12 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 24 Oct 2013 14:30:12 +0200 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <420AA490-51F4-459C-982A-606F885FD575@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> <5267D401.6070403@oracle.com> <420AA490-51F4-459C-982A-606F885FD575@oracle.com> Message-ID: <526912D4.4080000@oracle.com> Hi John, thank you for looking at this. You are right, the changes to free_entry are not correct when -XX:VerifyAdapterSharing is specified. An alternative way to solve the problem is to add entrys only if the entry contains all checks and -XX:+VerifyAdapterCalls is specified. With this version, we also do not need the _contains_all_checks field in AdapterHandlerEntry. What do you think about this version? http://cr.openjdk.java.net/~anoll/8026478/webrev.04/ Best, Albert On 23.10.2013 18:59, John Rose wrote: > I have a question: The amended free_entry function indirectly unlinks > the selected 'entry', but may also unlink other entries with the same > hash and fingerprint. Isn't this working against the use for > free_entry, where a pre-existing shared_entry is to be favored and > returned? Won't the shared_entry be unlinked also? That would seem > to lead to a storage leak. > > (Minor style nit: You code the hash comparison and key comparison as > nested ifs; they would be just as readable connected by an '&&', and > with less nesting.) > > ? John > > On Oct 23, 2013, at 6:49 AM, Albert Noll > wrote: > >> Hi, >> >> unfortunately, the patch was not correct, as revealed by jprt. >> The problem was that entries into the hashmap are not removed >> correctly. >> >> This version fixes the problem. The patch is currently in jprt. >> So far, everything looks good. >> >> Many thanks for another round. Here is the updated webrev: >> http://cr.openjdk.java.net/~anoll/8026478/webrev.03/ >> >> >> Best, >> Albert >> >> >> On 16.10.2013 19:43, Christian Thalinger wrote: >>> It would be nice to have a comment on this guy: >>> *+ bool _contains_all_checks;* >>> No need for another webrev if you decide to add the comment. >>> >>> Looks good. >>> >>> On Oct 15, 2013, at 11:02 PM, Albert Noll >> > wrote: >>> >>>> Forgot to adjust the comment. This version should be fine. >>>> >>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ >>>> >>>> >>>> Albert >>>> >>>> On 15.10.2013 21:03, Vladimir Kozlov wrote: >>>>> Albert, >>>>> >>>>> contains_all_stubs name is incorrect. It should be >>>>> contains_all_checks. Adapter code does not have stubs in it. >>>>> >>>>> I think the next check should be: >>>>> >>>>> bool contains_all_checks = (StubRoutines::code2() != NULL) || >>>>> !VerifyAdapterCalls; >>>>> >>>>> because code does not change when VerifyAdapterCalls is false. >>>>> Then you don't need to check VerifyAdapterCalls in next condition: >>>>> >>>>> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && >>>>> !entry->contains_all_checks()) { >>>>> >>>>> And we need to regenerate adapter regardless VerifyAdapterSharing >>>>> because, as you said, VerifyAdapterCalls potentially reports a >>>>> false error if check for code2 is not generated. >>>>> >>>>> So the condition should be simple "if >>>>> (!entry->contains_all_checks())". >>>>> >>>>> Could you leave next lines unchanged (use 2 lines for arguments)?: >>>>> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >>>>> >>>>> sizeof(buffer_locs)/sizeof(relocInfo)); >>>>> MacroAssembler _masm(&buffer); >>>>> >>>>> Cleanup is fine. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/15/13 4:14 AM, Albert Noll wrote: >>>>>> Hi, >>>>>> >>>>>> could I have reviews for this small patch? >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>>>>> >>>>>> >>>>>> Problem: This flag is broken. The reason is that adapters >>>>>> (gen_i2c_adapter()) that are generated during VM startup do not >>>>>> include >>>>>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>>>>> specified. StubRoutines::code2() is only allocated later during >>>>>> startup; >>>>>> consequently, code2() is NULL. As a result, the size of the >>>>>> generated >>>>>> adapter as well as the code itself does not mactch. >>>>>> >>>>>> Solution: Defer check (VerifyAdapterSharing) until VM is >>>>>> initialzied. >>>>>> Note that this patch also fixes potential issues with >>>>>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>>>>> removes some unused field of VerifyAdapterSharing. >>>>>> >>>>>> >>>>>> Many thanks in advance, >>>>>> Albert >>>>>> ** >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/c0a4e283/attachment-0001.html From vladimir.x.ivanov at oracle.com Thu Oct 24 06:15:49 2013 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Thu, 24 Oct 2013 13:15:49 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 3 new changesets Message-ID: <20131024131612.E913E626D4@hg.openjdk.java.net> Changeset: 68f07c29521b Author: anoll Date: 2013-10-15 08:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/68f07c29521b 8025740: Typo. Error line for wrong ReservedCodeCacheSize value is printed twice Summary: Remove duplicate print Reviewed-by: kvn, twisti ! src/share/vm/runtime/arguments.cpp Changeset: d95eca175eff Author: sspitsyn Date: 2013-10-23 20:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d95eca175eff 8023004: JSR 292: java.lang.RuntimeException: Original target method was called. Reviewed-by: jrose ! src/share/vm/prims/methodHandles.cpp Changeset: 0d1661d63d70 Author: vlivanov Date: 2013-10-23 20:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0d1661d63d70 8012941: JSR 292: too deep inlining might crash compiler because of stack overflow Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_globals.hpp From albert.noll at oracle.com Thu Oct 24 07:39:09 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 24 Oct 2013 16:39:09 +0200 Subject: RFR(S): 8026407: VM is crashed on linux-ppc and linux-i586 when there is not enough ReservedCodeCacheSize specified In-Reply-To: <2345C523-E41B-4E62-8EC1-35DFE994E9FE@oracle.com> References: <52668A55.40605@oracle.com> <2345C523-E41B-4E62-8EC1-35DFE994E9FE@oracle.com> Message-ID: <5269310D.2070803@oracle.com> John, Christian, thanks for providing background information to this bug. This certainly helps me in understanding this issue better. I will file a bug to further work on this issue. Best, Albert On 23.10.2013 19:41, Christian Thalinger wrote: > > On Oct 23, 2013, at 10:25 AM, John Rose > wrote: > >> On Oct 22, 2013, at 4:25 PM, Christian Thalinger >> > > wrote: >> >>> >>> On Oct 22, 2013, at 7:23 AM, Albert Noll >> > wrote: >>> >>>> Hi all, >>>> >>>> I worked on this bug for some time but so far I was not able to >>>> determine its root cause. >>>> However, I have found a work around that hides the problem. Since >>>> it is important >>>> for the embedded version of hotspot to work with small code cache >>>> sizes + nashorn, >>>> I would suggest to apply this workaround, and file another bug that >>>> investigates the problem >>>> (e.g., a P4) that we can defer. >>>> >>>> bug:https://bugs.openjdk.java.net/browse/JDK-8026407 >>>> webrev:http://cr.openjdk.java.net/~anoll/8026407/webrev.00/ >>>> >>>> >>>> problem: If we do not create native wrapper for method handle >>>> intrinsics, we get >>>> segfaults in compiled code. Also, if >>>> -XX:VerifyAdapterCalls is enabled, we >>>> get: >>>> >>>> assert(false) failed: DEBUG MESSAGE: i2c adapter >>>> must return to an interpreter frame >>>> >>>> The bug seems to be specific to method handle >>>> intrinsics. I assume that we either call >>>> the wrong entry point to a compiled method, or there >>>> is a bug somewhere in the generated >>>> adapters. Method handle intrinsics are treated >>>> specifically in various parts of the code and >>>> I do not yet really understand everything. >>> >>> I can tell you why (as could John): in order to properly handle the >>> appendix argument for out-of-line calls we are using a small >>> trampoline that pops off the appendix argument and jumps to the >>> target (see gen_special_dispatch in SharedRuntime). >>> >>> Since normal compiled-to-compiled calls are not able to handle such >>> a thing we MUST generate an adapter in this case. If we can't >>> generate one and use it we can not execute the out-of-line method >>> handle calls. >>> >> >> Thanks, Chris; that's correct. >> >> Albert, I think you are seeing edge cases (common enough when memory >> is tight) where compiled code A gets successfully compiled but a stub >> B that it needs fails to compile. >> >> If this is so, the order of compilation needs to change somehow so >> that B precedes A, or else A needs to ensure that B compiles before A >> needs it. >> >> An analogous case is the i2c/c2i adapters for all methods. There was >> a time (IIRC) that they were generated more lazily, but we had to >> make them eager, since we could get the same failure pattern: A >> compiles but B doesn't, where B is the i2c or c2i adapter. > > That is some interesting bit of history and finally gives an answer to > my question why the I2C/C2I adapters are eagerly generated. The > reason why I stumbled across this a couple weeks ago is I wanted to > see if we can generate some (all?) of our adapters from snippet type > code and not have handwritten assembler code for them. > >> >> A third option, which I would prefer if it were feasible, would be to >> make the compiled paths for the method handle stubs always inlined >> into the compiled code. But this is probably difficult, because >> method handles can point to method handle methods (and do pretty >> often!), so that it is not always possible for the compiler to know >> that a call will need to go through a stub's compiled entry point. >> There are ways around this also, but it's tricky. >> >> It seems likely to me that there is some kind of economical way to >> make sure that the stubs (B) are always created before their users >> (A) get compiled. >> >> Albert, thank you for dissecting this, and so many other gnarly code >> storage issues. >> >> ? John >> >> >>>> solution: As mentioned above, the solution is a workaround and does >>>> not solve the real problem. >>>> Nevertheless it improves stability of hotspot and the >>>> impact of the proposed changes are >>>> marginal. >>>> >>>> testing: Running nashorn with small code cache size (3m) on PPC and x86 >>>> >>>> There will be a separate mail for closed part changes. >>>> >>>> Many thanks in advance, >>>> Albert >>>> >>>> P.S.: If anyone has an idea of where the problem could be, please >>>> let me know! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/42d5222f/attachment.html From roland.westrelin at oracle.com Thu Oct 24 08:25:12 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 24 Oct 2013 17:25:12 +0200 Subject: RFR(XXS): 8026978: JSR292: fatal error: Type profiling not implemented on this platform Message-ID: <369EA7CB-5340-40C0-8743-163E4831C67F@oracle.com> Not the prettiest fix but one that is straightforward: http://cr.openjdk.java.net/~roland/8026978/webrev.00/ Roland. From christian.thalinger at oracle.com Thu Oct 24 09:12:46 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 09:12:46 -0700 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <5268E0AA.8060404@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> Message-ID: <418342F0-599F-4ADB-A758-647F9FBD3CDC@oracle.com> src/share/vm/runtime/sharedRuntime.cpp: + // The compilation falls outside the allowed range. Note that this can only happen in debug + // build if the cIStart(OSR) and CIStop(OSR) flags at are specified. Since currently this wrapper Typo: CIStart. Also, should this be: ?flags are?? Otherwise this looks good. On Oct 24, 2013, at 1:56 AM, Albert Noll wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ > > Best, > Albert > > On 24.10.2013 10:21, Albert Noll wrote: >> Hi Aleksey, >> >> thanks for looking at this. >> >> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>> Nice to see the locking gone. >>> >>> compileBroker.cpp: >>> * Is that considered correct that OSR and normal compilations are >>> marked differently when running in debug mode, but not in release? I >>> understand the comment before assign_compile_id, so this is more of the >>> philosophical question. >> Compilation IDs are only different if -XX:CICountOSR is set, which is >> defaulted to false. >>> sharedRuntime.cpp: >>> * Why do you need "2653 return;" in the method tail? >> Thanks for spotting this. I missed it during the cleanup. >> >> Best, >> Albert >>> Thanks, >>> -Aleksey. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/ee96f240/attachment-0001.html From christian.thalinger at oracle.com Thu Oct 24 09:24:21 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 09:24:21 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <526912D4.4080000@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> <5267D401.6070403@oracle.com> <420AA490-51F4-459C-982A-606F885FD575@oracle.com> <526912D4.4080000@oracle.com> Message-ID: <2B208669-E266-4D60-AF44-311FD0DB3D1D@oracle.com> src/share/vm/runtime/sharedRuntime.cpp: + bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; Could you move the !VerifyAdapterCalls check to here: + if (contains_all_checks) { And I still don?t know what ?checks? means in this context. Anyway, this looks good. On Oct 24, 2013, at 5:30 AM, Albert Noll wrote: > Hi John, > > thank you for looking at this. You are right, the changes to free_entry are not correct when -XX:VerifyAdapterSharing is > specified. > > An alternative way to solve the problem is to add entrys only if the entry contains all checks and > -XX:+VerifyAdapterCalls is specified. With this version, we also do not need the _contains_all_checks > field in AdapterHandlerEntry. > > What do you think about this version? > http://cr.openjdk.java.net/~anoll/8026478/webrev.04/ > Best, > Albert > > > On 23.10.2013 18:59, John Rose wrote: >> I have a question: The amended free_entry function indirectly unlinks the selected 'entry', but may also unlink other entries with the same hash and fingerprint. Isn't this working against the use for free_entry, where a pre-existing shared_entry is to be favored and returned? Won't the shared_entry be unlinked also? That would seem to lead to a storage leak. >> >> (Minor style nit: You code the hash comparison and key comparison as nested ifs; they would be just as readable connected by an '&&', and with less nesting.) >> >> ? John >> >> On Oct 23, 2013, at 6:49 AM, Albert Noll wrote: >> >>> Hi, >>> >>> unfortunately, the patch was not correct, as revealed by jprt. >>> The problem was that entries into the hashmap are not removed >>> correctly. >>> >>> This version fixes the problem. The patch is currently in jprt. >>> So far, everything looks good. >>> >>> Many thanks for another round. Here is the updated webrev: >>> http://cr.openjdk.java.net/~anoll/8026478/webrev.03/ >>> >>> Best, >>> Albert >>> >>> >>> On 16.10.2013 19:43, Christian Thalinger wrote: >>>> It would be nice to have a comment on this guy: >>>> + bool _contains_all_checks; >>>> No need for another webrev if you decide to add the comment. >>>> >>>> Looks good. >>>> >>>> On Oct 15, 2013, at 11:02 PM, Albert Noll wrote: >>>> >>>>> Forgot to adjust the comment. This version should be fine. >>>>> >>>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ >>>>> >>>>> Albert >>>>> >>>>> On 15.10.2013 21:03, Vladimir Kozlov wrote: >>>>>> Albert, >>>>>> >>>>>> contains_all_stubs name is incorrect. It should be contains_all_checks. Adapter code does not have stubs in it. >>>>>> >>>>>> I think the next check should be: >>>>>> >>>>>> bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; >>>>>> >>>>>> because code does not change when VerifyAdapterCalls is false. >>>>>> Then you don't need to check VerifyAdapterCalls in next condition: >>>>>> >>>>>> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && !entry->contains_all_checks()) { >>>>>> >>>>>> And we need to regenerate adapter regardless VerifyAdapterSharing because, as you said, VerifyAdapterCalls potentially reports a false error if check for code2 is not generated. >>>>>> >>>>>> So the condition should be simple "if (!entry->contains_all_checks())". >>>>>> >>>>>> Could you leave next lines unchanged (use 2 lines for arguments)?: >>>>>> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >>>>>> >>>>>> sizeof(buffer_locs)/sizeof(relocInfo)); >>>>>> MacroAssembler _masm(&buffer); >>>>>> >>>>>> Cleanup is fine. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/15/13 4:14 AM, Albert Noll wrote: >>>>>>> Hi, >>>>>>> >>>>>>> could I have reviews for this small patch? >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Problem: This flag is broken. The reason is that adapters >>>>>>> (gen_i2c_adapter()) that are generated during VM startup do not include >>>>>>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>>>>>> specified. StubRoutines::code2() is only allocated later during startup; >>>>>>> consequently, code2() is NULL. As a result, the size of the generated >>>>>>> adapter as well as the code itself does not mactch. >>>>>>> >>>>>>> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >>>>>>> Note that this patch also fixes potential issues with >>>>>>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>>>>>> removes some unused field of VerifyAdapterSharing. >>>>>>> >>>>>>> >>>>>>> Many thanks in advance, >>>>>>> Albert >>>>>>> ** >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/0b0d0823/attachment.html From christian.thalinger at oracle.com Thu Oct 24 09:26:19 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 09:26:19 -0700 Subject: RFR(XXS): 8026978: JSR292: fatal error: Type profiling not implemented on this platform In-Reply-To: <369EA7CB-5340-40C0-8743-163E4831C67F@oracle.com> References: <369EA7CB-5340-40C0-8743-163E4831C67F@oracle.com> Message-ID: <9A323C96-B60E-4224-AC05-7381D90113BD@oracle.com> Ugh. Oh well, looks good. On Oct 24, 2013, at 8:25 AM, Roland Westrelin wrote: > Not the prettiest fix but one that is straightforward: > > http://cr.openjdk.java.net/~roland/8026978/webrev.00/ > > Roland. From niclas.adlertz at oracle.com Thu Oct 24 11:36:45 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Thu, 24 Oct 2013 20:36:45 +0200 Subject: RFR(XS) 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Message-ID: <526968BD.8030502@oracle.com> Hi all, When removing junk phi nodes in post_allocate_copy_removal() we don't check if the inputs of the phi node die. This results in 'assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc'. Fix is to remove input recursively if they go dead. Tested with JPRT and CTW. Fixes the IeeeRecommendedTests failure. WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8026940/webrev00 JBS: https://bugs.openjdk.java.net/browse/JDK-8026940 Kind Regards, Niclas Adlertz From albert.noll at oracle.com Thu Oct 24 12:50:15 2013 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 24 Oct 2013 21:50:15 +0200 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <418342F0-599F-4ADB-A758-647F9FBD3CDC@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> <418342F0-599F-4ADB-A758-647F9FBD3CDC@oracle.com> Message-ID: <526979F7.7090708@oracle.com> Hi Chris, thanks for looking at this. I'll fix the typos before pushing. Best, Albert On 24.10.2013 18:12, Christian Thalinger wrote: > *src/share/vm/runtime/sharedRuntime.cpp:* > *+ // The compilation falls outside the allowed range. Note that this can only happen in debug* > *+ // build if the cIStart(OSR) and CIStop(OSR) flags at are specified. Since currently this wrapper* > Typo: CIStart. Also, should this be: ?flags are?? > > Otherwise this looks good. > > On Oct 24, 2013, at 1:56 AM, Albert Noll > wrote: > >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >> >> >> Best, >> Albert >> >> On 24.10.2013 10:21, Albert Noll wrote: >>> Hi Aleksey, >>> >>> thanks for looking at this. >>> >>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>> Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>> Nice to see the locking gone. >>>> >>>> compileBroker.cpp: >>>> * Is that considered correct that OSR and normal compilations are >>>> marked differently when running in debug mode, but not in release? I >>>> understand the comment before assign_compile_id, so this is more of >>>> the >>>> philosophical question. >>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>> defaulted to false. >>>> sharedRuntime.cpp: >>>> * Why do you need "2653 return;" in the method tail? >>> Thanks for spotting this. I missed it during the cleanup. >>> >>> Best, >>> Albert >>>> Thanks, >>>> -Aleksey. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/83d0da33/attachment.html From igor.ignatyev at oracle.com Thu Oct 24 13:11:27 2013 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Fri, 25 Oct 2013 00:11:27 +0400 Subject: =?utf-8?B?UmU6IFJGUiAoUyk6IDgwMjI0OTQ6IE1ha2UgY29tcGlsYXRpb24gSURzIHNlcXVl?= =?utf-8?B?bnRpYWw=?= Message-ID: <201310242011.r9OKBRvk000811@aserz7021.oracle.com> Albert, Do you plan to push it into jdk8 or jdk8uX? - Igor ----- Reply message ----- From: "Albert Noll" To: "Christian Thalinger" Cc: "hot >> hotspot-compiler-dev at openjdk.java.net" Subject: RFR (S): 8022494: Make compilation IDs sequential Date: Thu, Oct 24, 2013 23:50 Hi Chris, thanks for looking at this. I'll fix the typos before pushing. Best, Albert On 24.10.2013 18:12, Christian Thalinger wrote: src/share/vm/runtime/sharedRuntime.cpp: + // The compilation falls outside the allowed range. Note that this can only happen in debug + // build if the cIStart(OSR) and CIStop(OSR) flags at are specified. Since currently this wrapper Typo: ?CIStart. ?Also, should this be: ??flags are?? Otherwise this looks good. On Oct 24, 2013, at 1:56 AM, Albert Noll wrote: Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ Best, Albert On 24.10.2013 10:21, Albert Noll wrote: Hi Aleksey, thanks for looking at this. On 24.10.2013 10:15, Aleksey Shipilev wrote: On 10/24/2013 12:01 PM, Albert Noll wrote: Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ Nice to see the locking gone. compileBroker.cpp: ?? * Is that considered correct that OSR and normal compilations are marked differently when running in debug mode, but not in release? I understand the comment before assign_compile_id, so this is more of the philosophical question. Compilation IDs are only different if -XX:CICountOSR is set, which is defaulted to false. sharedRuntime.cpp: ?? * Why do you need "2653?? return;" in the method tail? Thanks for spotting this. I missed it during the cleanup. Best, Albert Thanks, -Aleksey. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131025/6793867a/attachment.html From christian.thalinger at oracle.com Thu Oct 24 15:02:33 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 15:02:33 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <526851CC.9080104@oracle.com> References: <526851CC.9080104@oracle.com> Message-ID: <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> On Oct 23, 2013, at 3:46 PM, serguei.spitsyn at oracle.com wrote: > Chris, > > This fix is nice, thank you for doing it! > I don't see any issues except this one: > > 566 /** > 567 * Returns the return entry address for the given top-of-stack state and bytecode. > 568 */ > 569 address TemplateInterpreter::return_entry(TosState state, int length, Bytecodes::Code code) { > 570 guarantee(0 <= length && length < Interpreter::number_of_return_entries, "illegal length"); > 571 const int index = TosState_as_index(state); > 572 switch (code) { > 573 case Bytecodes::_invokestatic: > 574 case Bytecodes::_invokespecial: > 575 case Bytecodes::_invokevirtual: > 576 return _invoke_return_entry[index]; > 577 case Bytecodes::_invokeinterface: > 578 return _invokeinterface_return_entry[index]; > 579 case Bytecodes::_invokedynamic: > 580 return _invokedynamic_return_entry[index]; > 581 default: > 582 return _return_entry[length].entry(state); > 583 } > 584 } > Should the above switch also include the _invokehandle case? Good point. It should. I?ve also added an assert to make sure we don?t end up with an invoke instruction in the default case: + default: + assert(!Bytecodes::is_invoke(code), err_msg("invoke instructions should be handled separately: %s", Bytecodes::name(code))); + return _return_entry[length].entry(state); > > > How did you test it? > It is necessary to run the nsk.jvmti and nsk.jdi testlists. It tested various things manually and did a JPRT run. Since I touched every invoke return entry in the system running some random code automatically tests this code. > > Thanks, > Serguei > > > On 10/23/13 11:06 AM, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8026328 >> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >> >> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >> Reviewed-by: >> >> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >> >> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >> >> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/9dd09d5b/attachment-0001.html From christian.thalinger at oracle.com Thu Oct 24 15:45:17 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 15:45:17 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> References: <526851CC.9080104@oracle.com> <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> Message-ID: <547D9252-B866-452B-B11E-CF251F68286C@oracle.com> On Oct 24, 2013, at 3:02 PM, Christian Thalinger wrote: > > On Oct 23, 2013, at 3:46 PM, serguei.spitsyn at oracle.com wrote: > >> Chris, >> >> This fix is nice, thank you for doing it! >> I don't see any issues except this one: >> >> 566 /** >> 567 * Returns the return entry address for the given top-of-stack state and bytecode. >> 568 */ >> 569 address TemplateInterpreter::return_entry(TosState state, int length, Bytecodes::Code code) { >> 570 guarantee(0 <= length && length < Interpreter::number_of_return_entries, "illegal length"); >> 571 const int index = TosState_as_index(state); >> 572 switch (code) { >> 573 case Bytecodes::_invokestatic: >> 574 case Bytecodes::_invokespecial: >> 575 case Bytecodes::_invokevirtual: >> 576 return _invoke_return_entry[index]; >> 577 case Bytecodes::_invokeinterface: >> 578 return _invokeinterface_return_entry[index]; >> 579 case Bytecodes::_invokedynamic: >> 580 return _invokedynamic_return_entry[index]; >> 581 default: >> 582 return _return_entry[length].entry(state); >> 583 } >> 584 } >> Should the above switch also include the _invokehandle case? > > Good point. It should. I?ve also added an assert to make sure we don?t end up with an invoke instruction in the default case: > > + default: > + assert(!Bytecodes::is_invoke(code), err_msg("invoke instructions should be handled separately: %s", Bytecodes::name(code))); > + return _return_entry[length].entry(state); Which brings up another question: should Bytecodes::is_invoke include a check for invokehandle? I think it should but we shouldn?t make that change so late in the 8 game. > >> >> >> How did you test it? >> It is necessary to run the nsk.jvmti and nsk.jdi testlists. > > It tested various things manually and did a JPRT run. Since I touched every invoke return entry in the system running some random code automatically tests this code. > >> >> Thanks, >> Serguei >> >> >> On 10/23/13 11:06 AM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8026328 >>> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >>> >>> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >>> Reviewed-by: >>> >>> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >>> >>> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >>> >>> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/48fe52f3/attachment.html From roland.westrelin at oracle.com Thu Oct 24 16:10:04 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 24 Oct 2013 23:10:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026978: JSR292: fatal error: Type profiling not implemented on this platform Message-ID: <20131024231025.683426270B@hg.openjdk.java.net> Changeset: f7d928a3181c Author: roland Date: 2013-10-24 19:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f7d928a3181c 8026978: JSR292: fatal error: Type profiling not implemented on this platform Summary: force TypeProfileLevel to 0 on non x86 Reviewed-by: twisti ! src/share/vm/runtime/arguments.cpp From serguei.spitsyn at oracle.com Thu Oct 24 16:12:23 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Oct 2013 16:12:23 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <547D9252-B866-452B-B11E-CF251F68286C@oracle.com> References: <526851CC.9080104@oracle.com> <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> <547D9252-B866-452B-B11E-CF251F68286C@oracle.com> Message-ID: <5269A957.5090100@oracle.com> On 10/24/13 3:45 PM, Christian Thalinger wrote: > > On Oct 24, 2013, at 3:02 PM, Christian Thalinger > > wrote: > >> >> On Oct 23, 2013, at 3:46 PM,serguei.spitsyn at oracle.com >> wrote: >> >>> Chris, >>> >>> This fix is nice, thank you for doing it! >>> I don't see any issues except this one: >>> >>> 566 /** >>> 567 * Returns the return entry address for the given top-of-stack state and bytecode. >>> 568 */ >>> 569 address TemplateInterpreter::return_entry(TosState state, int length, Bytecodes::Code code) { >>> 570 guarantee(0 <= length && length < Interpreter::number_of_return_entries, "illegal length"); >>> 571 const int index = TosState_as_index(state); >>> 572 switch (code) { >>> 573 case Bytecodes::_invokestatic: >>> 574 case Bytecodes::_invokespecial: >>> 575 case Bytecodes::_invokevirtual: >>> 576 return _invoke_return_entry[index]; >>> 577 case Bytecodes::_invokeinterface: >>> 578 return _invokeinterface_return_entry[index]; >>> 579 case Bytecodes::_invokedynamic: >>> 580 return _invokedynamic_return_entry[index]; >>> 581 default: >>> 582 return _return_entry[length].entry(state); >>> 583 } >>> 584 } >>> Should the above switch also include the _invokehandle case? >> >> Good point. It should. I?ve also added an assert to make sure we >> don?t end up with an invoke instruction in the default case: >> >> + default: >> + assert(!Bytecodes::is_invoke(code), err_msg("invoke instructions >> should be handled separately: %s", Bytecodes::name(code))); >> + return _return_entry[length].entry(state); > > Which brings up another question: should Bytecodes::is_invoke include > a check for invokehandle? I think it should but we shouldn?t make > that change so late in the 8 game. I do not see the Bytecodes::is_invoke is used widely. It is used in 4 other asserts: ops/methodData.cpp: assert(Bytecodes::is_invoke(stream->code()), "should be invoke"); oops/methodData.cpp: assert(Bytecodes::is_invoke(stream->code()), "should be invoke"); oops/methodData.cpp: assert(Bytecodes::is_invoke(stream->code()), "should be invoke"); interpreter/bytecodes.hpp: static bool has_receiver (Code code) { assert(is_invoke(code), ""); return code == _invokevirtual || Fixing it in Bytecodes::is_invoke looks pretty so far but depends on the usage in methodData.cpp. Thanks, Serguei > >> >>> >>> >>> How did you test it? >>> It is necessary to run the nsk.jvmti and nsk.jdi testlists. >> >> It tested various things manually and did a JPRT run. Since I >> touched every invoke return entry in the system running some random >> code automatically tests this code. >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/23/13 11:06 AM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8026328 >>>> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >>>> >>>> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >>>> Reviewed-by: >>>> >>>> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >>>> >>>> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >>>> >>>> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/dc4c8540/attachment-0001.html From serguei.spitsyn at oracle.com Thu Oct 24 16:14:18 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Oct 2013 16:14:18 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <5269A957.5090100@oracle.com> References: <526851CC.9080104@oracle.com> <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> <547D9252-B866-452B-B11E-CF251F68286C@oracle.com> <5269A957.5090100@oracle.com> Message-ID: <5269A9CA.6090508@oracle.com> On 10/24/13 4:12 PM, serguei.spitsyn at oracle.com wrote: > On 10/24/13 3:45 PM, Christian Thalinger wrote: >> >> On Oct 24, 2013, at 3:02 PM, Christian Thalinger >> > > wrote: >> >>> >>> On Oct 23, 2013, at 3:46 PM,serguei.spitsyn at oracle.com >>> wrote: >>> >>>> Chris, >>>> >>>> This fix is nice, thank you for doing it! >>>> I don't see any issues except this one: >>>> >>>> 566 /** >>>> 567 * Returns the return entry address for the given top-of-stack state and bytecode. >>>> 568 */ >>>> 569 address TemplateInterpreter::return_entry(TosState state, int length, Bytecodes::Code code) { >>>> 570 guarantee(0 <= length && length < Interpreter::number_of_return_entries, "illegal length"); >>>> 571 const int index = TosState_as_index(state); >>>> 572 switch (code) { >>>> 573 case Bytecodes::_invokestatic: >>>> 574 case Bytecodes::_invokespecial: >>>> 575 case Bytecodes::_invokevirtual: >>>> 576 return _invoke_return_entry[index]; >>>> 577 case Bytecodes::_invokeinterface: >>>> 578 return _invokeinterface_return_entry[index]; >>>> 579 case Bytecodes::_invokedynamic: >>>> 580 return _invokedynamic_return_entry[index]; >>>> 581 default: >>>> 582 return _return_entry[length].entry(state); >>>> 583 } >>>> 584 } >>>> Should the above switch also include the _invokehandle case? >>> >>> Good point. It should. I?ve also added an assert to make sure we >>> don?t end up with an invoke instruction in the default case: >>> >>> + default: >>> + assert(!Bytecodes::is_invoke(code), err_msg("invoke instructions >>> should be handled separately: %s", Bytecodes::name(code))); >>> + return _return_entry[length].entry(state); >> >> Which brings up another question: should Bytecodes::is_invoke >> include a check for invokehandle? I think it should but we shouldn?t >> make that change so late in the 8 game. > > I do not see the Bytecodes::is_invoke is used widely. > > It is used in 4 other asserts: > > ops/methodData.cpp: assert(Bytecodes::is_invoke(stream->code()), > "should be invoke"); > oops/methodData.cpp: assert(Bytecodes::is_invoke(stream->code()), > "should be invoke"); > oops/methodData.cpp: assert(Bytecodes::is_invoke(stream->code()), > "should be invoke"); > > interpreter/bytecodes.hpp: static bool has_receiver (Code > code) { assert(is_invoke(code), ""); return code == _invokevirtual || > > > Fixing it in Bytecodes::is_invoke looks pretty so far but depends on > the usage in methodData.cpp. Correction: "looks pretty safe so far". :) Thanks, Serguei > > > Thanks, > Serguei > >> >>> >>>> >>>> >>>> How did you test it? >>>> It is necessary to run the nsk.jvmti and nsk.jdi testlists. >>> >>> It tested various things manually and did a JPRT run. Since I >>> touched every invoke return entry in the system running some random >>> code automatically tests this code. >>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/23/13 11:06 AM, Christian Thalinger wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8026328 >>>>> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >>>>> >>>>> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >>>>> Reviewed-by: >>>>> >>>>> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >>>>> >>>>> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >>>>> >>>>> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/e4ca1cbc/attachment.html From christian.thalinger at oracle.com Thu Oct 24 16:21:24 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 24 Oct 2013 16:21:24 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> References: <526851CC.9080104@oracle.com> <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> Message-ID: <540288FF-3262-41B8-B45D-03733D1480F0@oracle.com> I?ve added another small change to make Zero build again: diff -r 97d400662426 src/cpu/zero/vm/globals_zero.hpp --- a/src/cpu/zero/vm/globals_zero.hpp Wed Oct 23 19:22:28 2013 +0000 +++ b/src/cpu/zero/vm/globals_zero.hpp Thu Oct 24 16:20:54 2013 -0700 @@ -57,6 +57,8 @@ define_pd_global(bool, UseMembar, // GC Ergo Flags define_pd_global(uintx, CMSYoungGenPerWorker, 16*M); // default max size of CMS young gen, per GC worker thread +define_pd_global(uintx, TypeProfileLevel, 0); + #define ARCH_FLAGS(develop, product, diagnostic, experimental, notproduct) #endif // CPU_ZERO_VM_GLOBALS_ZERO_HPP On Oct 24, 2013, at 3:02 PM, Christian Thalinger wrote: > > On Oct 23, 2013, at 3:46 PM, serguei.spitsyn at oracle.com wrote: > >> Chris, >> >> This fix is nice, thank you for doing it! >> I don't see any issues except this one: >> >> 566 /** >> 567 * Returns the return entry address for the given top-of-stack state and bytecode. >> 568 */ >> 569 address TemplateInterpreter::return_entry(TosState state, int length, Bytecodes::Code code) { >> 570 guarantee(0 <= length && length < Interpreter::number_of_return_entries, "illegal length"); >> 571 const int index = TosState_as_index(state); >> 572 switch (code) { >> 573 case Bytecodes::_invokestatic: >> 574 case Bytecodes::_invokespecial: >> 575 case Bytecodes::_invokevirtual: >> 576 return _invoke_return_entry[index]; >> 577 case Bytecodes::_invokeinterface: >> 578 return _invokeinterface_return_entry[index]; >> 579 case Bytecodes::_invokedynamic: >> 580 return _invokedynamic_return_entry[index]; >> 581 default: >> 582 return _return_entry[length].entry(state); >> 583 } >> 584 } >> Should the above switch also include the _invokehandle case? > > Good point. It should. I?ve also added an assert to make sure we don?t end up with an invoke instruction in the default case: > > + default: > + assert(!Bytecodes::is_invoke(code), err_msg("invoke instructions should be handled separately: %s", Bytecodes::name(code))); > + return _return_entry[length].entry(state); > >> >> >> How did you test it? >> It is necessary to run the nsk.jvmti and nsk.jdi testlists. > > It tested various things manually and did a JPRT run. Since I touched every invoke return entry in the system running some random code automatically tests this code. > >> >> Thanks, >> Serguei >> >> >> On 10/23/13 11:06 AM, Christian Thalinger wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8026328 >>> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >>> >>> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >>> Reviewed-by: >>> >>> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >>> >>> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >>> >>> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/bdd27d50/attachment-0001.html From john.r.rose at oracle.com Thu Oct 24 16:30:15 2013 From: john.r.rose at oracle.com (John Rose) Date: Thu, 24 Oct 2013 16:30:15 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <5269A957.5090100@oracle.com> References: <526851CC.9080104@oracle.com> <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> <547D9252-B866-452B-B11E-CF251F68286C@oracle.com> <5269A957.5090100@oracle.com> Message-ID: <9409D227-D78C-437C-AED6-F98C096553EA@oracle.com> You might sidestep the issue like this: assert(!is_invoke(java_code(code)), ""); -- John (on my iPhone) On Oct 24, 2013, at 4:12 PM, "serguei.spitsyn at oracle.com" wrote: > should Bytecodes::is_invoke include a check for invokehandle? From serguei.spitsyn at oracle.com Thu Oct 24 16:47:53 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Oct 2013 16:47:53 -0700 Subject: RFR (M): 8026328: Setting a breakpoint on invokedynamic crashes the JVM In-Reply-To: <540288FF-3262-41B8-B45D-03733D1480F0@oracle.com> References: <526851CC.9080104@oracle.com> <10BF7F32-ECAB-456D-88B4-6C53A4A56C35@oracle.com> <540288FF-3262-41B8-B45D-03733D1480F0@oracle.com> Message-ID: <5269B1A9.4060700@oracle.com> On 10/24/13 4:21 PM, Christian Thalinger wrote: > I?ve added another small change to make Zero build again: > > diff -r 97d400662426 src/cpu/zero/vm/globals_zero.hpp > --- a/src/cpu/zero/vm/globals_zero.hppWed Oct 23 19:22:28 2013 +0000 > +++ b/src/cpu/zero/vm/globals_zero.hppThu Oct 24 16:20:54 2013 -0700 > @@ -57,6 +57,8 @@ define_pd_global(bool, UseMembar, > // GC Ergo Flags > define_pd_global(uintx, CMSYoungGenPerWorker, 16*M); // default max > size of CMS young gen, per GC worker thread > > > +define_pd_global(uintx, TypeProfileLevel, 0); > + > #define ARCH_FLAGS(develop, product, diagnostic, experimental, > notproduct) > > > #endif // CPU_ZERO_VM_GLOBALS_ZERO_HPP Looks good. Thanks, Serguei > > On Oct 24, 2013, at 3:02 PM, Christian Thalinger > > wrote: > >> >> On Oct 23, 2013, at 3:46 PM,serguei.spitsyn at oracle.com >> wrote: >> >>> Chris, >>> >>> This fix is nice, thank you for doing it! >>> I don't see any issues except this one: >>> >>> 566 /** >>> 567 * Returns the return entry address for the given top-of-stack state and bytecode. >>> 568 */ >>> 569 address TemplateInterpreter::return_entry(TosState state, int length, Bytecodes::Code code) { >>> 570 guarantee(0 <= length && length < Interpreter::number_of_return_entries, "illegal length"); >>> 571 const int index = TosState_as_index(state); >>> 572 switch (code) { >>> 573 case Bytecodes::_invokestatic: >>> 574 case Bytecodes::_invokespecial: >>> 575 case Bytecodes::_invokevirtual: >>> 576 return _invoke_return_entry[index]; >>> 577 case Bytecodes::_invokeinterface: >>> 578 return _invokeinterface_return_entry[index]; >>> 579 case Bytecodes::_invokedynamic: >>> 580 return _invokedynamic_return_entry[index]; >>> 581 default: >>> 582 return _return_entry[length].entry(state); >>> 583 } >>> 584 } >>> Should the above switch also include the _invokehandle case? >> >> Good point. It should. I?ve also added an assert to make sure we >> don?t end up with an invoke instruction in the default case: >> >> + default: >> + assert(!Bytecodes::is_invoke(code), err_msg("invoke instructions >> should be handled separately: %s", Bytecodes::name(code))); >> + return _return_entry[length].entry(state); >> >>> >>> >>> How did you test it? >>> It is necessary to run the nsk.jvmti and nsk.jdi testlists. >> >> It tested various things manually and did a JPRT run. Since I >> touched every invoke return entry in the system running some random >> code automatically tests this code. >> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/23/13 11:06 AM, Christian Thalinger wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8026328 >>>> http://cr.openjdk.java.net/~twisti/8026328/webrev.00/ >>>> >>>> 8026328: Setting a breakpoint on invokedynamic crashes the JVM >>>> Reviewed-by: >>>> >>>> Well-known invoke instructions have a 2-byte index but invokedynamic has a 4-byte index. In return entries we check the bytecode instruction to decide which size the index has. >>>> >>>> The problem is that if there is a breakpoint there is no way to know what index size the instruction has because the original instruction byte was replaced with the breakpoint byte. >>>> >>>> There are a couple of ways to fix this but the proper way (in my opinion) is to have separate return entries for the different classes of invoke instructions. This on one hand generates more return entries but on the other hand makes them smaller and simpler. >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131024/40733b3d/attachment.html From christian.thalinger at oracle.com Thu Oct 24 22:03:52 2013 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 25 Oct 2013 05:03:52 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131025050410.561586271D@hg.openjdk.java.net> Changeset: bd3237e0e18d Author: twisti Date: 2013-10-24 16:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bd3237e0e18d 8026328: Setting a breakpoint on invokedynamic crashes the JVM Reviewed-by: jrose, roland ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/handles.cpp Changeset: cbe8ba0fb8fc Author: twisti Date: 2013-10-24 16:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cbe8ba0fb8fc Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java From albert.noll at oracle.com Thu Oct 24 22:31:39 2013 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 25 Oct 2013 07:31:39 +0200 Subject: RFR (S): 8022494: Make compilation IDs sequential Message-ID: <526A023B.3040101@oracle.com> Hi Igor, if you are ok with it, I would push it into 8. The change is low-risk and improves the understandability/readability of -XX:+PrintCompilation. Best, Albert On 24.10.2013 22:11, igor.ignatyev at oracle.com wrote: > Albert, > Do you plan to push it into jdk8 or jdk8uX? > > - Igor > > ----- Reply message ----- > From: "Albert Noll" > To: "Christian Thalinger" > Cc: "hot >> hotspot-compiler-dev at openjdk.java.net" > > Subject: RFR (S): 8022494: Make compilation IDs sequential > Date: Thu, Oct 24, 2013 23:50 > > Hi Chris, > > thanks for looking at this. I'll fix the typos before pushing. > > Best, > Albert > > On 24.10.2013 18:12, Christian Thalinger wrote: >> *src/share/vm/runtime/sharedRuntime.cpp:* >> *+ // The compilation falls outside the allowed range. Note that this can only happen in debug* >> *+ // build if the cIStart(OSR) and CIStop(OSR) flags at are specified. Since currently this wrapper* >> Typo: CIStart. Also, should this be: ?flags are?? >> >> Otherwise this looks good. >> >> On Oct 24, 2013, at 1:56 AM, Albert Noll > > wrote: >> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ >>> >>> >>> Best, >>> Albert >>> >>> On 24.10.2013 10:21, Albert Noll wrote: >>>> Hi Aleksey, >>>> >>>> thanks for looking at this. >>>> >>>> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>>>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>>>> Here is the updated webrev: >>>>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>>>>> >>>>> Nice to see the locking gone. >>>>> >>>>> compileBroker.cpp: >>>>> * Is that considered correct that OSR and normal compilations are >>>>> marked differently when running in debug mode, but not in release? I >>>>> understand the comment before assign_compile_id, so this is more >>>>> of the >>>>> philosophical question. >>>> Compilation IDs are only different if -XX:CICountOSR is set, which is >>>> defaulted to false. >>>>> sharedRuntime.cpp: >>>>> * Why do you need "2653 return;" in the method tail? >>>> Thanks for spotting this. I missed it during the cleanup. >>>> >>>> Best, >>>> Albert >>>>> Thanks, >>>>> -Aleksey. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131025/6380055a/attachment-0001.html From roland.westrelin at oracle.com Fri Oct 25 00:43:17 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 25 Oct 2013 09:43:17 +0200 Subject: RFR(S): 8027140: Assertion in compiler when running bigapps/Kitchensink/stability Message-ID: I wasn?t able to reproduce that bug or write a test case for it. Anyway, TypeKlassPtr was a subclass of TypeOopPtr before perm gen removal. TypeOopPtr::filter() had code to handle TypeKlassPtr types. When TypeKlassPtr was moved under TypePtr, this code wasn?t moved. I think it should have been and that could explain the assert. http://cr.openjdk.java.net/~roland/8027140/webrev.00/ Roland. From roland.westrelin at oracle.com Fri Oct 25 01:02:51 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 25 Oct 2013 10:02:51 +0200 Subject: RFR(XS) 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc In-Reply-To: <526968BD.8030502@oracle.com> References: <526968BD.8030502@oracle.com> Message-ID: > WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8026940/webrev00 This comment doesn?t look good anymore: 97 static bool expected_yanked_node(Node *old, Node *orig_old) { 98 // This code is expected only next original nodes: 99 // - load from constant table node which may have next data input nodes: 100 // MachConstantBase, Phi, MachTemp, MachSpillCopy 101 // - load constant node which may have next data input nodes: 102 // MachTemp, MachSpillCopy 103 // - MachSpillCopy 104 // - MachProj and Copy dead nodes otherwise I think it?s good. Roland. From albert.noll at oracle.com Fri Oct 25 01:26:04 2013 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 25 Oct 2013 10:26:04 +0200 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <2B208669-E266-4D60-AF44-311FD0DB3D1D@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> <5267D401.6070403@oracle.com> <420AA490-51F4-459C-982A-606F885FD575@oracle.com> <526912D4.4080000@oracle.com> <2B208669-E266-4D60-AF44-311FD0DB3D1D@oracle.com> Message-ID: <526A2B1C.2070905@oracle.com> Hi Chris, thanks for looking at this again. I moved the !VerifyAdapterCalls as you proposed. That seems more logical to me as well. I also updated the comment that describes the contains_all_checks variable. If you do not understand it, it is not well decribed, but it should be. Please let me know if it is clearer now. If not, I'll update the comment. *+ // StubRoutines::code2() is initialized after this function can be called. As a result,* *+ // VerifyAdapterCalls and VerifyAdapterSharing can fail if we re-use code that generated* *+ // prior to StubRoutines::code2() being set. Checks refer to checks generated in an I2C* *+ // stub that ensure that an I2C stub is called from an interpreter frame.* Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.05/ Best, Albert On 24.10.2013 18:24, Christian Thalinger wrote: > *src/share/vm/runtime/sharedRuntime.cpp:* > *+ bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls;* > Could you move the *!VerifyAdapterCalls *check to here: > *+ if (contains_all_checks) {* > And I still don?t know what ?checks? means in this context. Anyway, > this looks good. > > On Oct 24, 2013, at 5:30 AM, Albert Noll > wrote: > >> Hi John, >> >> thank you for looking at this. You are right, the changes to >> free_entry are not correct when -XX:VerifyAdapterSharing is >> specified. >> >> An alternative way to solve the problem is to add entrys only if the >> entry contains all checks and >> -XX:+VerifyAdapterCalls is specified. With this version, we also do >> not need the _contains_all_checks >> field in AdapterHandlerEntry. >> >> What do you think about this version? >> http://cr.openjdk.java.net/~anoll/8026478/webrev.04/ >> >> Best, >> Albert >> >> >> On 23.10.2013 18:59, John Rose wrote: >>> I have a question: The amended free_entry function indirectly >>> unlinks the selected 'entry', but may also unlink other entries with >>> the same hash and fingerprint. Isn't this working against the use >>> for free_entry, where a pre-existing shared_entry is to be favored >>> and returned? Won't the shared_entry be unlinked also? That would >>> seem to lead to a storage leak. >>> >>> (Minor style nit: You code the hash comparison and key comparison >>> as nested ifs; they would be just as readable connected by an '&&', >>> and with less nesting.) >>> >>> ? John >>> >>> On Oct 23, 2013, at 6:49 AM, Albert Noll >> > wrote: >>> >>>> Hi, >>>> >>>> unfortunately, the patch was not correct, as revealed by jprt. >>>> The problem was that entries into the hashmap are not removed >>>> correctly. >>>> >>>> This version fixes the problem. The patch is currently in jprt. >>>> So far, everything looks good. >>>> >>>> Many thanks for another round. Here is the updated webrev: >>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.03/ >>>> >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 16.10.2013 19:43, Christian Thalinger wrote: >>>>> It would be nice to have a comment on this guy: >>>>> *+ bool _contains_all_checks;* >>>>> No need for another webrev if you decide to add the comment. >>>>> >>>>> Looks good. >>>>> >>>>> On Oct 15, 2013, at 11:02 PM, Albert Noll >>>> > wrote: >>>>> >>>>>> Forgot to adjust the comment. This version should be fine. >>>>>> >>>>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ >>>>>> >>>>>> >>>>>> Albert >>>>>> >>>>>> On 15.10.2013 21:03, Vladimir Kozlov wrote: >>>>>>> Albert, >>>>>>> >>>>>>> contains_all_stubs name is incorrect. It should be >>>>>>> contains_all_checks. Adapter code does not have stubs in it. >>>>>>> >>>>>>> I think the next check should be: >>>>>>> >>>>>>> bool contains_all_checks = (StubRoutines::code2() != NULL) || >>>>>>> !VerifyAdapterCalls; >>>>>>> >>>>>>> because code does not change when VerifyAdapterCalls is false. >>>>>>> Then you don't need to check VerifyAdapterCalls in next condition: >>>>>>> >>>>>>> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && >>>>>>> !entry->contains_all_checks()) { >>>>>>> >>>>>>> And we need to regenerate adapter regardless >>>>>>> VerifyAdapterSharing because, as you said, VerifyAdapterCalls >>>>>>> potentially reports a false error if check for code2 is not >>>>>>> generated. >>>>>>> >>>>>>> So the condition should be simple "if >>>>>>> (!entry->contains_all_checks())". >>>>>>> >>>>>>> Could you leave next lines unchanged (use 2 lines for arguments)?: >>>>>>> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >>>>>>> >>>>>>> sizeof(buffer_locs)/sizeof(relocInfo)); >>>>>>> MacroAssembler _masm(&buffer); >>>>>>> >>>>>>> Cleanup is fine. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/15/13 4:14 AM, Albert Noll wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> could I have reviews for this small patch? >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Problem: This flag is broken. The reason is that adapters >>>>>>>> (gen_i2c_adapter()) that are generated during VM startup do not >>>>>>>> include >>>>>>>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>>>>>>> specified. StubRoutines::code2() is only allocated later during >>>>>>>> startup; >>>>>>>> consequently, code2() is NULL. As a result, the size of the >>>>>>>> generated >>>>>>>> adapter as well as the code itself does not mactch. >>>>>>>> >>>>>>>> Solution: Defer check (VerifyAdapterSharing) until VM is >>>>>>>> initialzied. >>>>>>>> Note that this patch also fixes potential issues with >>>>>>>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>>>>>>> removes some unused field of VerifyAdapterSharing. >>>>>>>> >>>>>>>> >>>>>>>> Many thanks in advance, >>>>>>>> Albert >>>>>>>> ** >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131025/b47d2452/attachment-0001.html From niclas.adlertz at oracle.com Fri Oct 25 01:30:04 2013 From: niclas.adlertz at oracle.com (Niclas Adlertz) Date: Fri, 25 Oct 2013 10:30:04 +0200 Subject: RFR(XS) 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc In-Reply-To: References: <526968BD.8030502@oracle.com> Message-ID: <526A2C0C.7000403@oracle.com> Thanks Roland. I will change the comment. Kind Regards, Niclas Adlertz On 2013-10-25 10:02, Roland Westrelin wrote: >> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8026940/webrev00 > > This comment doesn?t look good anymore: > > 97 static bool expected_yanked_node(Node *old, Node *orig_old) { > 98 // This code is expected only next original nodes: > 99 // - load from constant table node which may have next data input nodes: > 100 // MachConstantBase, Phi, MachTemp, MachSpillCopy > 101 // - load constant node which may have next data input nodes: > 102 // MachTemp, MachSpillCopy > 103 // - MachSpillCopy > 104 // - MachProj and Copy dead nodes > > otherwise I think it?s good. > > Roland. > From christian.thalinger at oracle.com Fri Oct 25 13:38:30 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 25 Oct 2013 13:38:30 -0700 Subject: RFR(S): 8027140: Assertion in compiler when running bigapps/Kitchensink/stability In-Reply-To: References: Message-ID: <32020F25-3C97-4119-8244-B6BD9B36D8D7@oracle.com> This looks good. Can you change the type hierarchy in type.hpp too? class TypePtr; class TypeRawPtr; class TypeOopPtr; class TypeInstPtr; class TypeAryPtr; class TypeKlassPtr; class TypeMetadataPtr; On Oct 25, 2013, at 12:43 AM, Roland Westrelin wrote: > I wasn?t able to reproduce that bug or write a test case for it. Anyway, TypeKlassPtr was a subclass of TypeOopPtr before perm gen removal. TypeOopPtr::filter() had code to handle TypeKlassPtr types. When TypeKlassPtr was moved under TypePtr, this code wasn?t moved. I think it should have been and that could explain the assert. > > http://cr.openjdk.java.net/~roland/8027140/webrev.00/ > > Roland. From christian.thalinger at oracle.com Fri Oct 25 13:41:43 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 25 Oct 2013 13:41:43 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <526A2B1C.2070905@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> <5267D401.6070403@oracle.com> <420AA490-51F4-459C-982A-606F885FD575@oracle.com> <526912D4.4080000@oracle.com> <2B208669-E266-4D60-AF44-311FD0DB3D1D@oracle.com> <526A2B1C.2070905@oracle.com> Message-ID: Usually we call them I2C/C2I ?adapters? but it doesn?t matter. The change is good. On Oct 25, 2013, at 1:26 AM, Albert Noll wrote: > Hi Chris, > > thanks for looking at this again. I moved the !VerifyAdapterCalls as you proposed. > That seems more logical to me as well. > > I also updated the comment that describes the contains_all_checks variable. > If you do not understand it, it is not well decribed, but it should be. Please let > me know if it is clearer now. If not, I'll update the comment. > > + // StubRoutines::code2() is initialized after this function can be called. As a result, > + // VerifyAdapterCalls and VerifyAdapterSharing can fail if we re-use code that generated > + // prior to StubRoutines::code2() being set. Checks refer to checks generated in an I2C > + // stub that ensure that an I2C stub is called from an interpreter frame. > > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8026478/webrev.05/ > > Best, > Albert > > On 24.10.2013 18:24, Christian Thalinger wrote: >> src/share/vm/runtime/sharedRuntime.cpp: >> + bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; >> Could you move the !VerifyAdapterCalls check to here: >> + if (contains_all_checks) { >> And I still don?t know what ?checks? means in this context. Anyway, this looks good. >> >> On Oct 24, 2013, at 5:30 AM, Albert Noll wrote: >> >>> Hi John, >>> >>> thank you for looking at this. You are right, the changes to free_entry are not correct when -XX:VerifyAdapterSharing is >>> specified. >>> >>> An alternative way to solve the problem is to add entrys only if the entry contains all checks and >>> -XX:+VerifyAdapterCalls is specified. With this version, we also do not need the _contains_all_checks >>> field in AdapterHandlerEntry. >>> >>> What do you think about this version? >>> http://cr.openjdk.java.net/~anoll/8026478/webrev.04/ >>> Best, >>> Albert >>> >>> >>> On 23.10.2013 18:59, John Rose wrote: >>>> I have a question: The amended free_entry function indirectly unlinks the selected 'entry', but may also unlink other entries with the same hash and fingerprint. Isn't this working against the use for free_entry, where a pre-existing shared_entry is to be favored and returned? Won't the shared_entry be unlinked also? That would seem to lead to a storage leak. >>>> >>>> (Minor style nit: You code the hash comparison and key comparison as nested ifs; they would be just as readable connected by an '&&', and with less nesting.) >>>> >>>> ? John >>>> >>>> On Oct 23, 2013, at 6:49 AM, Albert Noll wrote: >>>> >>>>> Hi, >>>>> >>>>> unfortunately, the patch was not correct, as revealed by jprt. >>>>> The problem was that entries into the hashmap are not removed >>>>> correctly. >>>>> >>>>> This version fixes the problem. The patch is currently in jprt. >>>>> So far, everything looks good. >>>>> >>>>> Many thanks for another round. Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.03/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 16.10.2013 19:43, Christian Thalinger wrote: >>>>>> It would be nice to have a comment on this guy: >>>>>> + bool _contains_all_checks; >>>>>> No need for another webrev if you decide to add the comment. >>>>>> >>>>>> Looks good. >>>>>> >>>>>> On Oct 15, 2013, at 11:02 PM, Albert Noll wrote: >>>>>> >>>>>>> Forgot to adjust the comment. This version should be fine. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ >>>>>>> >>>>>>> Albert >>>>>>> >>>>>>> On 15.10.2013 21:03, Vladimir Kozlov wrote: >>>>>>>> Albert, >>>>>>>> >>>>>>>> contains_all_stubs name is incorrect. It should be contains_all_checks. Adapter code does not have stubs in it. >>>>>>>> >>>>>>>> I think the next check should be: >>>>>>>> >>>>>>>> bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; >>>>>>>> >>>>>>>> because code does not change when VerifyAdapterCalls is false. >>>>>>>> Then you don't need to check VerifyAdapterCalls in next condition: >>>>>>>> >>>>>>>> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && !entry->contains_all_checks()) { >>>>>>>> >>>>>>>> And we need to regenerate adapter regardless VerifyAdapterSharing because, as you said, VerifyAdapterCalls potentially reports a false error if check for code2 is not generated. >>>>>>>> >>>>>>>> So the condition should be simple "if (!entry->contains_all_checks())". >>>>>>>> >>>>>>>> Could you leave next lines unchanged (use 2 lines for arguments)?: >>>>>>>> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >>>>>>>> >>>>>>>> sizeof(buffer_locs)/sizeof(relocInfo)); >>>>>>>> MacroAssembler _masm(&buffer); >>>>>>>> >>>>>>>> Cleanup is fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/15/13 4:14 AM, Albert Noll wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I have reviews for this small patch? >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem: This flag is broken. The reason is that adapters >>>>>>>>> (gen_i2c_adapter()) that are generated during VM startup do not include >>>>>>>>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>>>>>>>> specified. StubRoutines::code2() is only allocated later during startup; >>>>>>>>> consequently, code2() is NULL. As a result, the size of the generated >>>>>>>>> adapter as well as the code itself does not mactch. >>>>>>>>> >>>>>>>>> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >>>>>>>>> Note that this patch also fixes potential issues with >>>>>>>>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>>>>>>>> removes some unused field of VerifyAdapterSharing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Many thanks in advance, >>>>>>>>> Albert >>>>>>>>> ** >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131025/02695f76/attachment.html From igor.veresov at oracle.com Fri Oct 25 14:08:45 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 25 Oct 2013 14:08:45 -0700 Subject: RFR(S): 8027140: Assertion in compiler when running bigapps/Kitchensink/stability In-Reply-To: References: Message-ID: Looks fine. igor On Oct 25, 2013, at 12:43 AM, Roland Westrelin wrote: > I wasn?t able to reproduce that bug or write a test case for it. Anyway, TypeKlassPtr was a subclass of TypeOopPtr before perm gen removal. TypeOopPtr::filter() had code to handle TypeKlassPtr types. When TypeKlassPtr was moved under TypePtr, this code wasn?t moved. I think it should have been and that could explain the assert. > > http://cr.openjdk.java.net/~roland/8027140/webrev.00/ > > Roland. From rickard.backman at oracle.com Mon Oct 28 00:55:19 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 28 Oct 2013 08:55:19 +0100 Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Message-ID: <20131028075519.GD1092@rbackman> Hi, can I please have this small change reviewed? Webrev: http://cr.openjdk.java.net/~rbackman/8027353/ Bug: https://bugs.openjdk.java.net/browse/JDK-8027353 Thanks /R From vladimir.kozlov at oracle.com Mon Oct 28 01:03:09 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2013 01:03:09 -0700 Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null In-Reply-To: <20131028075519.GD1092@rbackman> References: <20131028075519.GD1092@rbackman> Message-ID: <526E1A3D.5070300@oracle.com> Good. Thanks, Vladimir On 10/28/13 12:55 AM, Rickard B?ckman wrote: > Hi, > > can I please have this small change reviewed? > > Webrev: http://cr.openjdk.java.net/~rbackman/8027353/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8027353 > > Thanks > /R > From rickard.backman at oracle.com Mon Oct 28 01:14:30 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 28 Oct 2013 09:14:30 +0100 Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null In-Reply-To: <526E1A3D.5070300@oracle.com> References: <20131028075519.GD1092@rbackman> <526E1A3D.5070300@oracle.com> Message-ID: <20131028081430.GA28875@rbackman> Thank you, Vladimir. /R On 10/28, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/28/13 12:55 AM, Rickard B?ckman wrote: > >Hi, > > > >can I please have this small change reviewed? > > > >Webrev: http://cr.openjdk.java.net/~rbackman/8027353/ > >Bug: https://bugs.openjdk.java.net/browse/JDK-8027353 > > > >Thanks > >/R > > From roland.westrelin at oracle.com Mon Oct 28 01:19:54 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 28 Oct 2013 09:19:54 +0100 Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null In-Reply-To: <20131028075519.GD1092@rbackman> References: <20131028075519.GD1092@rbackman> Message-ID: > Webrev: http://cr.openjdk.java.net/~rbackman/8027353/ It looks good. Roland. From rickard.backman at oracle.com Mon Oct 28 01:23:02 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 28 Oct 2013 09:23:02 +0100 Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null In-Reply-To: References: <20131028075519.GD1092@rbackman> Message-ID: <20131028082302.GB28875@rbackman> Roland, thanks for the review. /R On 10/28, Roland Westrelin wrote: > > Webrev: http://cr.openjdk.java.net/~rbackman/8027353/ > > It looks good. > > Roland. > From igor.ignatyev at oracle.com Mon Oct 28 01:37:46 2013 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Mon, 28 Oct 2013 12:37:46 +0400 Subject: =?utf-8?B?UmU6IFJGUihYUyk6IDgwMjczNTM6IEV4YWN0IGludHJpbnNpY3M6IGFzc2VydChu?= =?utf-8?B?ICE9IE5VTEwpIGZhaWxlZDogbXVzdCBub3QgYmUgbnVsbA==?= Message-ID: <201310280837.r9S8bjOb016126@userz7021.oracle.com> Rickard, Could you please add a CR number in the tests, at least in 'compiler/intrinsics/mathexact/SubExactLNonConstantTest.java'. - Igor ----- Reply message ----- From: "RickardB?ckman" To: Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Date: Mon, Oct 28, 2013 11:55 Hi, can I please have this small change reviewed? Webrev: http://cr.openjdk.java.net/~rbackman/8027353/ Bug: https://bugs.openjdk.java.net/browse/JDK-8027353 Thanks /R -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131028/10fa5892/attachment.html From roland.westrelin at oracle.com Mon Oct 28 01:56:33 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 28 Oct 2013 09:56:33 +0100 Subject: RFR(S): 8027140: Assertion in compiler when running bigapps/Kitchensink/stability In-Reply-To: References: Message-ID: <72D0B232-84B3-43E5-9360-4B1A4BFC6806@oracle.com> Thanks for the review, Igor. Roland. From roland.westrelin at oracle.com Mon Oct 28 01:57:00 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 28 Oct 2013 09:57:00 +0100 Subject: RFR(S): 8027140: Assertion in compiler when running bigapps/Kitchensink/stability In-Reply-To: <32020F25-3C97-4119-8244-B6BD9B36D8D7@oracle.com> References: <32020F25-3C97-4119-8244-B6BD9B36D8D7@oracle.com> Message-ID: > This looks good. Can you change the type hierarchy in type.hpp too? I?ll do that. Thanks for the review. Roland. From rickard.backman at oracle.com Mon Oct 28 02:02:56 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 28 Oct 2013 10:02:56 +0100 Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Message-ID: <20131028090256.GC28875@rbackman> Ok, done. On 10/28, igor.ignatyev at oracle.com wrote: > Rickard, > Could you please add a CR number in the tests, at least in 'compiler/intrinsics/mathexact/SubExactLNonConstantTest.java'. > > - Igor > > ----- Reply message ----- > From: "RickardB?ckman" > To: > Subject: RFR(XS): 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null > Date: Mon, Oct 28, 2013 11:55 > > Hi, > > can I please have this small change reviewed? > > Webrev: http://cr.openjdk.java.net/~rbackman/8027353/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8027353 > > Thanks > /R From bundin10 at rambler.ru Mon Oct 28 05:09:17 2013 From: bundin10 at rambler.ru (=?koi8-r?B?5M3J1NLJyiDi1c7Eyc4=?=) Date: Mon, 28 Oct 2013 16:09:17 +0400 Subject: About wildcard Message-ID: <1382962157.327723.4535.29202@saddam1.rambler.ru> Hello! I want to ask the following question: Let we have code List nums= new ArrayList(); nums.add(4); with compile time error. Fragment of error description is Integer cannot convert to CAP#1. What is the CAP#1 type? If we consider package javax.lang.model.type we have that intreface NullType inherited from ReferenceType. And we can add to nums null only. Question: Is it true that CAP#1 just is NullType for compiler? Best regards, Dmitrii, Junior Java Developer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131028/3efcd462/attachment-0001.html From igor.ignatyev at oracle.com Mon Oct 28 09:40:52 2013 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 28 Oct 2013 20:40:52 +0400 Subject: About wildcard In-Reply-To: <1382962157.327723.4535.29202@saddam1.rambler.ru> References: <1382962157.327723.4535.29202@saddam1.rambler.ru> Message-ID: <526E9394.60702@oracle.com> Hi Dmitrii, You wrote to wrong mail-list. This list is about JIT compiler in hotspot (which compiles java bytecode into native code), but you need a list about Java compiler (compiler java source code into java bytecode) -- compiler-dev at openjdk.java.net. On 10/28/2013 04:09 PM, ??????? ?????? wrote: > Hello! I want to ask the following question: Let we have code /*List extends Number> nums= new ArrayList(); nums.add(4);*/ with > compile time error. Fragment of error description is /*Integer cannot > convert to CAP#1*. /What is the */CAP#1/* type? If we consider > package*/javax.lang.model.type/* we have that intreface */NullType/* > inherited from */ReferenceType/*. And we can add to */nums null > /*only/./ Question: Is it true that /*CAP#1*/ just is /*NullType */for > compiler? > > Best regards, > > Dmitrii, > > Junior Java Developer. > From vladimir.kozlov at oracle.com Mon Oct 28 11:21:04 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2013 11:21:04 -0700 Subject: RFR(XXS): 8026978: JSR292: fatal error: Type profiling not implemented on this platform In-Reply-To: <9A323C96-B60E-4224-AC05-7381D90113BD@oracle.com> References: <369EA7CB-5340-40C0-8743-163E4831C67F@oracle.com> <9A323C96-B60E-4224-AC05-7381D90113BD@oracle.com> Message-ID: <526EAB10.7070107@oracle.com> It can be done in vm_version_.cpp similar to UseSSE. But current fix is fine too because we will remove it when we implement call site type profiling on other platforms. Thanks, Vladimir On 10/24/13 9:26 AM, Christian Thalinger wrote: > Ugh. Oh well, looks good. > > On Oct 24, 2013, at 8:25 AM, Roland Westrelin wrote: > >> Not the prettiest fix but one that is straightforward: >> >> http://cr.openjdk.java.net/~roland/8026978/webrev.00/ >> >> Roland. > From vladimir.kozlov at oracle.com Mon Oct 28 11:59:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2013 11:59:32 -0700 Subject: RFR (S): 8022494: Make compilation IDs sequential In-Reply-To: <5268E0AA.8060404@oracle.com> References: <5201E15F.2020809@oracle.com> <8BF33C0B-1AA4-4349-A3F7-8C5B3305A8DC@oracle.com> <520301C5.20803@oracle.com> <5268D3E2.2070608@oracle.com> <5268D731.90904@oracle.com> <5268D875.5030506@oracle.com> <5268E0AA.8060404@oracle.com> Message-ID: <526EB414.1030705@oracle.com> Albert, The warning is not correct solution since we HAVE to generate method handle intrinsics if your comment is correct: + // must be generated for method handle intrinsics (8026407), print out a warning. + if (method->is_method_handle_intrinsic()) { + warning("Must generate wrapper for method handle intrinsic"); + return; + } I think assign_compile_id() should generate id in such case regardless CIStart and CIStop values. The warning above will be assert after that. And, please, file RFE (starter task) to cleanup type of compile_id. In some places it declared as 'int' and in an other as 'uint'. Thanks, Vladimir On 10/24/13 1:56 AM, Albert Noll wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~anoll/8022494/webrev.04/ > > Best, > Albert > > On 24.10.2013 10:21, Albert Noll wrote: >> Hi Aleksey, >> >> thanks for looking at this. >> >> On 24.10.2013 10:15, Aleksey Shipilev wrote: >>> On 10/24/2013 12:01 PM, Albert Noll wrote: >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~anoll/8022494/webrev.03/ >>> Nice to see the locking gone. >>> >>> compileBroker.cpp: >>> * Is that considered correct that OSR and normal compilations are >>> marked differently when running in debug mode, but not in release? I >>> understand the comment before assign_compile_id, so this is more of the >>> philosophical question. >> Compilation IDs are only different if -XX:CICountOSR is set, which is >> defaulted to false. >>> sharedRuntime.cpp: >>> * Why do you need "2653 return;" in the method tail? >> Thanks for spotting this. I missed it during the cleanup. >> >> Best, >> Albert >>> Thanks, >>> -Aleksey. >> > From niclas.adlertz at oracle.com Mon Oct 28 12:17:18 2013 From: niclas.adlertz at oracle.com (niclas.adlertz at oracle.com) Date: Mon, 28 Oct 2013 19:17:18 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131028191730.33D9E627A1@hg.openjdk.java.net> Changeset: f01788f13696 Author: adlertz Date: 2013-10-25 10:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f01788f13696 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Summary: Remove input to junk phi if they also become dead during post_allocate_copy_removal Reviewed-by: roland ! src/share/vm/opto/postaloc.cpp Changeset: 7ae254fd0b3c Author: adlertz Date: 2013-10-25 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ae254fd0b3c Merge From vladimir.kozlov at oracle.com Mon Oct 28 12:58:10 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2013 12:58:10 -0700 Subject: RFR(XS) 8026940: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc In-Reply-To: <526968BD.8030502@oracle.com> References: <526968BD.8030502@oracle.com> Message-ID: <526EC1D2.1070206@oracle.com> Niclas, Currently this code eliminates phi node only when it has unique input. But in bug case Phi node also has no users (outcnt == 0) since it is only the explanation why you need to do recursive removal. Do you know why we get Phi without uses? Why it was not eliminated when uses were removed? We do remove non-phi nodes in such case: 558 if(n->outcnt() == 0 && // Dead? I don't think one decrement is enough now: + phi_dex--; because other phi nodes could be removed from the block since you remove dead nodes recursively. Next old code may also have this problem (may process not Phi nodes because some Phi was removed recursively): 443 for (uint k = 1; k < phi_dex; k++) { 444 elide_copy(block->get_node(k), j, block, *blk2value[pb->_pre_order], *blk2regnd[pb->_pre_order], false); 445 } Please, look on all use cases of yank_if_dead_recurse() to make sure the return value is used correctly. Note, the expression "j -= yank_if_dead()" is fine - some previous nodes will be processed again in worst case, that is all. Thanks, Vladimir On 10/24/13 11:36 AM, Niclas Adlertz wrote: > Hi all, > > When removing junk phi nodes in post_allocate_copy_removal() we don't check if the inputs of the phi node die. > This results in 'assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc'. > Fix is to remove input recursively if they go dead. > > Tested with JPRT and CTW. Fixes the IeeeRecommendedTests failure. > > WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8026940/webrev00 > JBS: https://bugs.openjdk.java.net/browse/JDK-8026940 > > Kind Regards, > Niclas Adlertz From vladimir.kozlov at oracle.com Mon Oct 28 13:57:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2013 13:57:29 -0700 Subject: RFR (S): 8026478: -XX:+VerifyAdapterSharing is broken In-Reply-To: <526A2B1C.2070905@oracle.com> References: <525D238F.2080501@oracle.com> <525D9194.3070403@oracle.com> <525E2C11.9050100@oracle.com> <34569632-9CA9-4205-BDED-09177AB0EFB0@oracle.com> <5267D401.6070403@oracle.com> <420AA490-51F4-459C-982A-606F885FD575@oracle.com> <526912D4.4080000@oracle.com> <2B208669-E266-4D60-AF44-311FD0DB3D1D@oracle.com> <526A2B1C.2070905@oracle.com> Message-ID: <526ECFB9.6070705@oracle.com> Looks good. Thanks, Vladimir On 10/25/13 1:26 AM, Albert Noll wrote: > Hi Chris, > > thanks for looking at this again. I moved the !VerifyAdapterCalls as you proposed. > That seems more logical to me as well. > > I also updated the comment that describes the contains_all_checks variable. > If you do not understand it, it is not well decribed, but it should be. Please let > me know if it is clearer now. If not, I'll update the comment. > > *+ // StubRoutines::code2() is initialized after this function can be called. As a result,* > *+ // VerifyAdapterCalls and VerifyAdapterSharing can fail if we re-use code that generated* > *+ // prior to StubRoutines::code2() being set. Checks refer to checks generated in an I2C* > *+ // stub that ensure that an I2C stub is called from an interpreter frame.* > > > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8026478/webrev.05/ > > Best, > Albert > > On 24.10.2013 18:24, Christian Thalinger wrote: >> *src/share/vm/runtime/sharedRuntime.cpp:* >> *+ bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls;* >> Could you move the *!VerifyAdapterCalls *check to here: >> *+ if (contains_all_checks) {* >> And I still don?t know what ?checks? means in this context. Anyway, this looks good. >> >> On Oct 24, 2013, at 5:30 AM, Albert Noll > wrote: >> >>> Hi John, >>> >>> thank you for looking at this. You are right, the changes to free_entry are not correct when -XX:VerifyAdapterSharing is >>> specified. >>> >>> An alternative way to solve the problem is to add entrys only if the entry contains all checks and >>> -XX:+VerifyAdapterCalls is specified. With this version, we also do not need the _contains_all_checks >>> field in AdapterHandlerEntry. >>> >>> What do you think about this version? >>> http://cr.openjdk.java.net/~anoll/8026478/webrev.04/ >>> Best, >>> Albert >>> >>> >>> On 23.10.2013 18:59, John Rose wrote: >>>> I have a question: The amended free_entry function indirectly unlinks the selected 'entry', but may also unlink >>>> other entries with the same hash and fingerprint. Isn't this working against the use for free_entry, where a >>>> pre-existing shared_entry is to be favored and returned? Won't the shared_entry be unlinked also? That would seem >>>> to lead to a storage leak. >>>> >>>> (Minor style nit: You code the hash comparison and key comparison as nested ifs; they would be just as readable >>>> connected by an '&&', and with less nesting.) >>>> >>>> ? John >>>> >>>> On Oct 23, 2013, at 6:49 AM, Albert Noll > wrote: >>>> >>>>> Hi, >>>>> >>>>> unfortunately, the patch was not correct, as revealed by jprt. >>>>> The problem was that entries into the hashmap are not removed >>>>> correctly. >>>>> >>>>> This version fixes the problem. The patch is currently in jprt. >>>>> So far, everything looks good. >>>>> >>>>> Many thanks for another round. Here is the updated webrev: >>>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.03/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 16.10.2013 19:43, Christian Thalinger wrote: >>>>>> It would be nice to have a comment on this guy: >>>>>> *+ bool _contains_all_checks;* >>>>>> No need for another webrev if you decide to add the comment. >>>>>> >>>>>> Looks good. >>>>>> >>>>>> On Oct 15, 2013, at 11:02 PM, Albert Noll > wrote: >>>>>> >>>>>>> Forgot to adjust the comment. This version should be fine. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~anoll/8026478/webrev.02/ >>>>>>> >>>>>>> Albert >>>>>>> >>>>>>> On 15.10.2013 21:03, Vladimir Kozlov wrote: >>>>>>>> Albert, >>>>>>>> >>>>>>>> contains_all_stubs name is incorrect. It should be contains_all_checks. Adapter code does not have stubs in it. >>>>>>>> >>>>>>>> I think the next check should be: >>>>>>>> >>>>>>>> bool contains_all_checks = (StubRoutines::code2() != NULL) || !VerifyAdapterCalls; >>>>>>>> >>>>>>>> because code does not change when VerifyAdapterCalls is false. >>>>>>>> Then you don't need to check VerifyAdapterCalls in next condition: >>>>>>>> >>>>>>>> + if ((VerifyAdapterCalls || VerifyAdapterSharing) && !entry->contains_all_checks()) { >>>>>>>> >>>>>>>> And we need to regenerate adapter regardless VerifyAdapterSharing because, as you said, VerifyAdapterCalls >>>>>>>> potentially reports a false error if check for code2 is not generated. >>>>>>>> >>>>>>>> So the condition should be simple "if (!entry->contains_all_checks())". >>>>>>>> >>>>>>>> Could you leave next lines unchanged (use 2 lines for arguments)?: >>>>>>>> ! buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, >>>>>>>> >>>>>>>> sizeof(buffer_locs)/sizeof(relocInfo)); >>>>>>>> MacroAssembler _masm(&buffer); >>>>>>>> >>>>>>>> Cleanup is fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/15/13 4:14 AM, Albert Noll wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> could I have reviews for this small patch? >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8026478 >>>>>>>>> webrev: http://cr.openjdk.java.net/~anoll/8026478/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem: This flag is broken. The reason is that adapters >>>>>>>>> (gen_i2c_adapter()) that are generated during VM startup do not include >>>>>>>>> the range for StubRoutines::code2() if -XX:+VerifyAdapterCalls is >>>>>>>>> specified. StubRoutines::code2() is only allocated later during startup; >>>>>>>>> consequently, code2() is NULL. As a result, the size of the generated >>>>>>>>> adapter as well as the code itself does not mactch. >>>>>>>>> >>>>>>>>> Solution: Defer check (VerifyAdapterSharing) until VM is initialzied. >>>>>>>>> Note that this patch also fixes potential issues with >>>>>>>>> -XX:+VerifyAdapterCalls, which is a dignostic flag. The patch also >>>>>>>>> removes some unused field of VerifyAdapterSharing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Many thanks in advance, >>>>>>>>> Albert >>>>>>>>> ** >>>>>>> >>>>>> >>>>> >>>> >>> >> > From roland.westrelin at oracle.com Mon Oct 28 15:06:50 2013 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Mon, 28 Oct 2013 22:06:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131028220700.E0158627AE@hg.openjdk.java.net> Changeset: 6c2f07d1495f Author: roland Date: 2013-10-28 09:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6c2f07d1495f 8027140: Assertion in compiler when running bigapps/Kitchensink/stability Summary: filter() code for TypeKlassPtr not moved when permgen removal was introduced Reviewed-by: twisti, iveresov ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: bfdb530cdffa Author: roland Date: 2013-10-28 12:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bfdb530cdffa Merge From igor.veresov at oracle.com Mon Oct 28 17:24:46 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 29 Oct 2013 00:24:46 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 2 new changesets Message-ID: <20131029002453.D6720627C3@hg.openjdk.java.net> Changeset: a196f1aaec86 Author: anoll Date: 2013-10-25 22:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a196f1aaec86 8026949: -Xint flag prints wrong warning: Initialization of C1 thread failed (no space to run compilers) Summary: Exit compiler threads early during startup so that wrong error message is not printed Reviewed-by: iveresov, twisti ! src/share/vm/compiler/compileBroker.cpp + test/compiler/startup/StartupOutput.java Changeset: 8c16f426dbb2 Author: iveresov Date: 2013-10-28 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8c16f426dbb2 Merge From igor.veresov at oracle.com Mon Oct 28 19:45:30 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 29 Oct 2013 02:45:30 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 54 new changesets Message-ID: <20131029024731.56AE3627CD@hg.openjdk.java.net> Changeset: f9d4ed6c88dd Author: dholmes Date: 2013-10-21 20:51 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f9d4ed6c88dd 8026872: [TESTBUG] Classes OOMCrashClass4000_1.class and OOMCrashClass1960_2.class from runtime/ClassFile/ tests won't run on compact profiles Reviewed-by: sla, sspitsyn ! test/TEST.groups Changeset: 8cd1abf3ecab Author: dholmes Date: 2013-10-21 21:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8cd1abf3ecab Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! test/TEST.groups - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 2036c97e3af0 Author: dholmes Date: 2013-10-21 22:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2036c97e3af0 Merge Changeset: 7fe6ef09d242 Author: farvidsson Date: 2013-10-16 09:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fe6ef09d242 8025638: jmap returns 0 instead of 1 when it fails. Summary: Re-factored some code handling return values and fails/errors during tool execution. Reviewed-by: sla, kevinw Contributed-by: fredrik.arvidsson at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FinalizerInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/FlagDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JSnap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/StackTrace.java ! agent/src/share/classes/sun/jvm/hotspot/tools/SysPropsDumper.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/JSDB.java ! agent/src/share/classes/sun/jvm/hotspot/tools/soql/SOQL.java Changeset: 042cf42c72bd Author: simonis Date: 2013-10-16 15:06 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/042cf42c72bd 8026703: Wrongly placed element in Event-Based JVM Tracing .xsl files Reviewed-by: sla, kamg ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceEventIds.xsl ! src/share/vm/trace/traceTypes.xsl Changeset: d248425bcfe8 Author: hseigel Date: 2013-10-16 14:32 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d248425bcfe8 8024804: Crash when InterfaceMethodref resolves to Object.registerNatives Summary: Added check for NULL prior to continuation of method look up to avoid runtime crash during look up of Object's superclass' methods. Reviewed-by: coleenp, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8024804/RegisterNatives.java Changeset: 9e0ef3f02648 Author: hseigel Date: 2013-10-16 15:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9e0ef3f02648 Merge Changeset: 1bee3014cf2a Author: dsamersoff Date: 2013-10-17 16:08 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1bee3014cf2a 8025812: tmtools/jmap/heap_config tests fail on Linux-ia32 because it Cant attach to the core file Summary: Coredump store memsz elf field rounded up to page Reviewed-by: dholmes, sla ! agent/src/os/linux/ps_core.c Changeset: ffb471203842 Author: erikj Date: 2013-10-17 16:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ffb471203842 8026792: HOTSPOT: licensee reports a JDK8 build failure after 8005849/8005008 fixes integrated. Reviewed-by: dholmes, sla ! make/windows/makefiles/trace.make Changeset: ad8e901ca2e1 Author: sla Date: 2013-10-17 12:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ad8e901ca2e1 Merge Changeset: d2db09f281ca Author: dsamersoff Date: 2013-10-17 16:45 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d2db09f281ca 8005810: Update Hotspot Serviceability Agent for Method Parameter Reflection and Generic Type Signature Data Summary: Hotspot was updated to store method parameter reflection and generic type signature data at runtime. Serviceability agent support was updated for this data Reviewed-by: coleenp, minqi, sla Contributed-by: eric.mccorkle at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! src/share/vm/runtime/vmStructs.cpp Changeset: b942ac65ac86 Author: dsamersoff Date: 2013-10-17 17:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b942ac65ac86 Merge Changeset: d0453d2fd045 Author: dsamersoff Date: 2013-10-18 10:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d0453d2fd045 Merge Changeset: ee99e1a7c5fb Author: ccheung Date: 2013-10-18 19:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ee99e1a7c5fb Merge ! src/share/vm/interpreter/linkResolver.cpp - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp ! src/share/vm/runtime/vmStructs.cpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 996d1f2f056f Author: dsamersoff Date: 2013-10-19 21:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/996d1f2f056f 8026930: In ManagementAgent.start it should be possible to set the jdp.name parameter (hotspot part) Summary: Pass one more property from Agent to JdpController Reviewed-by: jbachorik, sla ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp Changeset: 1327b7f85503 Author: ccheung Date: 2013-10-21 17:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1327b7f85503 Merge Changeset: 662c154d2749 Author: hseigel Date: 2013-10-22 14:47 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/662c154d2749 8026394: Eclipse fails with JDK8 build 111 Summary: If the resolved interface does not itself contain "clone" or "finalize" methods, the method/interface method resolution looks to the interface's super class, java.lang.Object. With the JDK 8 interface method accessability check requirement, since these two methods are declared within Object as protected, they must be special cased in LinkResolver::check_method_accessability() in order to avoid an IAE. Reviewed-by: acorn, dholmes Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp + test/runtime/8026394/InterfaceObjectTest.java Changeset: b8860472c377 Author: iklam Date: 2013-10-22 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b8860472c377 8014910: deadlock between JVM/TI ClassPrepare event handler and CompilerThread Summary: Revert changes in JDK-8008962 Reviewed-by: coleenp, sspitsyn ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiEnv.cpp Changeset: 28be4c586b70 Author: iklam Date: 2013-10-22 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/28be4c586b70 Merge Changeset: a997d762fa20 Author: hseigel Date: 2013-10-22 15:54 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a997d762fa20 8026809: [TESTBUG] Create regression test for JDK-8026041 Summary: Created simple regression test for the bug Reviewed-by: hseigel, lfoltan, zgu Contributed-by: mikhailo.seledtsov at oracle.com + test/runtime/CommandLine/PrintGCApplicationConcurrentTime.java Changeset: c183576a2dd1 Author: hseigel Date: 2013-10-22 22:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c183576a2dd1 Merge Changeset: b658cfe35857 Author: farvidsson Date: 2013-10-23 10:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b658cfe35857 8026808: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failed with unexpected exit value Summary: Fixes a bug with vmArgs when using JDKToolLauncher Reviewed-by: sla, dholmes ! test/testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java Changeset: b3a4d4279fa3 Author: ccheung Date: 2013-10-24 17:20 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b3a4d4279fa3 Merge Changeset: 395499125cb0 Author: iveresov Date: 2013-10-24 16:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/395499125cb0 Merge - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 6b32b911d723 Author: iveresov Date: 2013-10-24 16:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6b32b911d723 Merge ! src/share/vm/runtime/vmStructs.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: 1d1ea10fe09f Author: mgerdin Date: 2013-10-15 13:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1d1ea10fe09f 8015255: NPG: Don't waste fragment at the end of a VirtualSpaceNode before retiring it. Summary: Chunk up the last piece of committed memory in a VSN when getting a new one. Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/prims/jni.cpp Changeset: 91a88c8450f4 Author: mgerdin Date: 2013-10-18 09:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/91a88c8450f4 8026698: Incorrect error handling in Metaspace::allocate Reviewed-by: stefank, jwilhelm ! src/share/vm/memory/metaspace.cpp Changeset: a1b05d4a6fd0 Author: stefank Date: 2013-10-21 09:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a1b05d4a6fd0 8026781: Add missing test to exercise -XX:+UseLargePagesInMetaspace Reviewed-by: mgerdin, brutisso + test/gc/TestSystemGC.java Changeset: 3dd24766da44 Author: stefank Date: 2013-10-21 01:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3dd24766da44 Merge Changeset: 2fab5b7e6140 Author: ehelin Date: 2013-10-21 14:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2fab5b7e6140 8025834: NPE in Parallel Scavenge with -XX:+CheckUnhandledOops Reviewed-by: coleenp, mgerdin, sspitsyn ! src/share/vm/prims/jvmtiImpl.cpp Changeset: c7f403b05168 Author: sjohanss Date: 2013-10-22 11:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c7f403b05168 8026848: -XX:+G1SummarizeRSetStats can result in wrong exit code and crash Summary: Changed the use of %d to SIZE_FORMAT macro in format string when printing size_t values. Reviewed-by: stefank, ehelin ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp Changeset: 0823c8bac468 Author: jcoomes Date: 2013-10-22 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0823c8bac468 Merge Changeset: 1b422ef5288a Author: tschatzl Date: 2013-10-23 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1b422ef5288a 8025728: Missing volatile specifier for field G1AllocRegion::_alloc_region Summary: The field G1AllocRegion::_alloc_region needs to be declared volatile as it is used with that intention. Otherwise the compiler may generate the code that reloads the value which might have changed in the meantime, leading to spurious crashes. Reviewed-by: iveresov, simonis, tschatzl Contributed-by: Axel Siebenborn ! src/share/vm/gc_implementation/g1/g1AllocRegion.hpp Changeset: 0dcdec729cda Author: jcoomes Date: 2013-10-25 08:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0dcdec729cda Merge Changeset: 5c599c419c1d Author: hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.seigel at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: d840f02d03b4 Author: chegar Date: 2013-07-15 11:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d840f02d03b4 Merge - src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp - src/os_cpu/solaris_sparc/vm/assembler_solaris_sparc.cpp Changeset: 7ec210434b3c Author: chegar Date: 2013-07-22 14:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7ec210434b3c Merge - src/share/vm/memory/klassInfoClosure.hpp - src/share/vm/runtime/aprofiler.cpp - src/share/vm/runtime/aprofiler.hpp Changeset: ca9029490fce Author: chegar Date: 2013-07-25 17:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ca9029490fce Merge Changeset: 8f66130f7b5c Author: chegar Date: 2013-08-02 11:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f66130f7b5c Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 38f9393d1847 Author: sgabdura Date: 2013-08-09 11:03 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/38f9393d1847 8020789: Disable exporting of gc.heap_dump diagnostic command Reviewed-by: fparain, ahgross ! src/share/vm/services/diagnosticCommand.cpp Changeset: ee7a7aa7c6bb Author: chegar Date: 2013-08-09 14:30 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ee7a7aa7c6bb Merge Changeset: 8f3c59225a5c Author: chegar Date: 2013-08-15 21:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8f3c59225a5c Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 7638e35cabc6 Author: erikj Date: 2013-08-19 17:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7638e35cabc6 8015614: Update build settings Reviewed-by: tbell, dholmes, ahgross ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make Changeset: d4fa23d6c35b Author: chegar Date: 2013-08-23 22:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d4fa23d6c35b Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 07b5f47d7a18 Author: chegar Date: 2013-08-30 09:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/07b5f47d7a18 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 98a2169ed7ac Author: iklam Date: 2013-08-24 00:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/98a2169ed7ac 8023683: Enhance class file parsing Summary: Use the value returned by REALLOC_RESOURCE_ARRAY() Reviewed-by: coleenp, ahgross ! src/share/vm/classfile/classFileParser.cpp Changeset: 8321dcc18438 Author: chegar Date: 2013-10-13 21:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8321dcc18438 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: 1a93f2c5945a Author: lana Date: 2013-10-17 14:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1a93f2c5945a Merge ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! src/share/vm/classfile/classFileParser.cpp Changeset: 4589b398ab03 Author: amurillo Date: 2013-10-22 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4589b398ab03 Merge - src/share/vm/memory/metablock.cpp - src/share/vm/memory/metablock.hpp - test/compiler/8013496/Test8013496.sh - test/gc/7168848/HumongousAlloc.java Changeset: 4a1128861221 Author: cl Date: 2013-10-24 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4a1128861221 Added tag jdk8-b113 for changeset 4589b398ab03 ! .hgtags Changeset: 82a9cdbf683e Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/82a9cdbf683e Merge ! src/share/vm/services/diagnosticCommand.cpp - test/compiler/intrinsics/mathexact/CondTest.java - test/compiler/intrinsics/mathexact/ConstantTest.java - test/compiler/intrinsics/mathexact/LoadTest.java - test/compiler/intrinsics/mathexact/LoopDependentTest.java - test/compiler/intrinsics/mathexact/NonConstantTest.java - test/compiler/intrinsics/mathexact/RepeatTest.java Changeset: bde83ddf920c Author: amurillo Date: 2013-10-25 13:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bde83ddf920c Added tag hs25-b56 for changeset 82a9cdbf683e ! .hgtags Changeset: f94a9f0746d8 Author: amurillo Date: 2013-10-25 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f94a9f0746d8 8027173: new hotspot build - hs25-b57 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fc1632f5021a Author: iveresov Date: 2013-10-28 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fc1632f5021a Merge From rickard.backman at oracle.com Tue Oct 29 00:30:50 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Tue, 29 Oct 2013 07:30:50 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Message-ID: <20131029073056.CCD8C627D6@hg.openjdk.java.net> Changeset: a57a165b8296 Author: rbackman Date: 2013-10-28 08:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a57a165b8296 8027353: Exact intrinsics: assert(n != NULL) failed: must not be null Reviewed-by: kvn, roland ! src/share/vm/opto/library_call.cpp ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java From rickard.backman at oracle.com Wed Oct 30 06:17:34 2013 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Wed, 30 Oct 2013 14:17:34 +0100 Subject: RFR(XS): 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 Message-ID: <20131030131734.GC7280@rbackman> Hi, can I please have this change reviewed? One of the loop optimizations we are doing doesn't work well with the MathExact nodes recently added. The short term fix is to disable the loop optimization if we detect a MathExact node (or rather a FlagsProj node). I'll file a RFE for fixing this. Bug: https://bugs.openjdk.java.net/browse/JDK-8027444 Webrev: http://cr.openjdk.java.net/~rbackman/8027444/ /R From vladimir.kozlov at oracle.com Wed Oct 30 10:11:01 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2013 10:11:01 -0700 Subject: RFR(XS): 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <20131030131734.GC7280@rbackman> References: <20131030131734.GC7280@rbackman> Message-ID: <52713DA5.7080907@oracle.com> Good. Thanks, Vladimir On 10/30/13 6:17 AM, Rickard B?ckman wrote: > Hi, can I please have this change reviewed? > > One of the loop optimizations we are doing doesn't work well with the > MathExact nodes recently added. The short term fix is to disable the > loop optimization if we detect a MathExact node (or rather a FlagsProj > node). I'll file a RFE for fixing this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027444 > Webrev: http://cr.openjdk.java.net/~rbackman/8027444/ > > /R > From roland.westrelin at oracle.com Wed Oct 30 10:36:54 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 30 Oct 2013 18:36:54 +0100 Subject: RFR(XS): 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <20131030131734.GC7280@rbackman> References: <20131030131734.GC7280@rbackman> Message-ID: <736048BC-4525-48FC-9064-9407184C779B@oracle.com> > Webrev: http://cr.openjdk.java.net/~rbackman/8027444/ That looks good. Roland. From roland.westrelin at oracle.com Wed Oct 30 11:36:30 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 30 Oct 2013 19:36:30 +0100 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I Message-ID: http://cr.openjdk.java.net/~roland/8027445/webrev.00/ On 64 bit, the integer length input to the StrEquals node may have some bits set in its higher half and cannot be used directly for pointer arithmetic. StrComp is not affected because we add and subtract the length for each memory access. AryEq is not affected because we reload the length for both arrays. I added test cases for all of them anyway. I wasn?t able to reproduce it on x86 but it?s unclear to me whether something similar could happen or not. Roland. From vladimir.kozlov at oracle.com Wed Oct 30 12:09:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2013 12:09:06 -0700 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: References: Message-ID: <52715952.6050806@oracle.com> On x86 in 64-bit mode any 32-bit arithmetic will clear upper 32 bits. That is why it is not problem on x86. On SPARC we need explicitly clear upper bits. We have special macroassembler instruction signx(Register d ), please use it instead of sra(). And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. You are correct about code in enc_String_Compare but for consistency I would suggest to do sign extension there too before next instruction (since chr1_reg is used later): __ subcc(limit_reg, 1 * sizeof(jchar), chr1_reg); One additional instruction outside a loop will not kill performance. Thanks, Vladimir On 10/30/13 11:36 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8027445/webrev.00/ > > On 64 bit, the integer length input to the StrEquals node may have some bits set in its higher half and cannot be used directly for pointer arithmetic. StrComp is not affected because we add and subtract the length for each memory access. AryEq is not affected because we reload the length for both arrays. I added test cases for all of them anyway. I wasn?t able to reproduce it on x86 but it?s unclear to me whether something similar could happen or not. > > Roland. > From roland.westrelin at oracle.com Wed Oct 30 13:16:53 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 30 Oct 2013 21:16:53 +0100 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: <52715952.6050806@oracle.com> References: <52715952.6050806@oracle.com> Message-ID: <8917A33C-E071-4BCB-8A10-534D6CFA16E5@oracle.com> Thanks for the review, Vladimir. Here is a new webrev: http://cr.openjdk.java.net/~roland/8027445/webrev.01/ Roland. On Oct 30, 2013, at 8:09 PM, Vladimir Kozlov wrote: > On x86 in 64-bit mode any 32-bit arithmetic will clear upper 32 bits. That is why it is not problem on x86. > > On SPARC we need explicitly clear upper bits. We have special macroassembler instruction signx(Register d ), please use it instead of sra(). And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. > > You are correct about code in enc_String_Compare but for consistency I would suggest to do sign extension there too before next instruction (since chr1_reg is used later): > > __ subcc(limit_reg, 1 * sizeof(jchar), chr1_reg); > > One additional instruction outside a loop will not kill performance. > > Thanks, > Vladimir > > On 10/30/13 11:36 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8027445/webrev.00/ >> >> On 64 bit, the integer length input to the StrEquals node may have some bits set in its higher half and cannot be used directly for pointer arithmetic. StrComp is not affected because we add and subtract the length for each memory access. AryEq is not affected because we reload the length for both arrays. I added test cases for all of them anyway. I wasn?t able to reproduce it on x86 but it?s unclear to me whether something similar could happen or not. >> >> Roland. >> From rickard.backman at oracle.com Wed Oct 30 13:30:28 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Wed, 30 Oct 2013 20:30:28 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 Message-ID: <20131030203035.514C162849@hg.openjdk.java.net> Changeset: 60a32bb8ff99 Author: rbackman Date: 2013-10-30 13:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/60a32bb8ff99 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 Reviewed-by: duke ! src/share/vm/opto/loopTransform.cpp + test/compiler/intrinsics/mathexact/NestedMathExactTest.java From vladimir.kozlov at oracle.com Wed Oct 30 14:00:58 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2013 14:00:58 -0700 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: <8917A33C-E071-4BCB-8A10-534D6CFA16E5@oracle.com> References: <52715952.6050806@oracle.com> <8917A33C-E071-4BCB-8A10-534D6CFA16E5@oracle.com> Message-ID: <5271738A.8010600@oracle.com> Good. Thanks, Vladimir On 10/30/13 1:16 PM, Roland Westrelin wrote: > Thanks for the review, Vladimir. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8027445/webrev.01/ > > Roland. > > > On Oct 30, 2013, at 8:09 PM, Vladimir Kozlov wrote: > >> On x86 in 64-bit mode any 32-bit arithmetic will clear upper 32 bits. That is why it is not problem on x86. >> >> On SPARC we need explicitly clear upper bits. We have special macroassembler instruction signx(Register d ), please use it instead of sra(). And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. >> >> You are correct about code in enc_String_Compare but for consistency I would suggest to do sign extension there too before next instruction (since chr1_reg is used later): >> >> __ subcc(limit_reg, 1 * sizeof(jchar), chr1_reg); >> >> One additional instruction outside a loop will not kill performance. >> >> Thanks, >> Vladimir >> >> On 10/30/13 11:36 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8027445/webrev.00/ >>> >>> On 64 bit, the integer length input to the StrEquals node may have some bits set in its higher half and cannot be used directly for pointer arithmetic. StrComp is not affected because we add and subtract the length for each memory access. AryEq is not affected because we reload the length for both arrays. I added test cases for all of them anyway. I wasn?t able to reproduce it on x86 but it?s unclear to me whether something similar could happen or not. >>> >>> Roland. >>> > From igor.veresov at oracle.com Wed Oct 30 15:38:36 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Oct 2013 15:38:36 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError Message-ID: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> CHA in C1 incorrectly treats calls to interfaces with default methods. We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ Testing: affected tests in java/util/stream, the regression test From igor.veresov at oracle.com Wed Oct 30 16:04:14 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Oct 2013 16:04:14 -0700 Subject: RFR(S): 8024919 G1: SPECjbb2013 crashes due to a broken object reference Message-ID: <72A9BBC9-E84C-4A2A-BBC9-0AEDA256D26A@oracle.com> C1 had passed incorrect new value to the post_barrer() in Unsafe.getAndSetObject() intrinsic. Instead of the new value, on which G1 executes a bunch filters it passed the old value. That caused sporadic barrier omissions and missing rset entries as a result. Huge thanks to Mikael Gerdin for helping to track this hard to reproduce issue. Webrev: http://cr.openjdk.java.net/~iveresov/8024919/webrev.0/ igor From vladimir.kozlov at oracle.com Wed Oct 30 16:23:52 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2013 16:23:52 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError In-Reply-To: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> References: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> Message-ID: <52719508.8010100@oracle.com> Fix looks good. We use new naming for tests now, please, change to next (or better name if you find): test/compiler/inlining/InlineDefaultMethod.java Thanks, Vladimir On 10/30/13 3:38 PM, Igor Veresov wrote: > CHA in C1 incorrectly treats calls to interfaces with default methods. > We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. > > Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ > Testing: affected tests in java/util/stream, the regression test > From vladimir.kozlov at oracle.com Wed Oct 30 16:25:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2013 16:25:36 -0700 Subject: RFR(S): 8024919 G1: SPECjbb2013 crashes due to a broken object reference In-Reply-To: <72A9BBC9-E84C-4A2A-BBC9-0AEDA256D26A@oracle.com> References: <72A9BBC9-E84C-4A2A-BBC9-0AEDA256D26A@oracle.com> Message-ID: <52719570.5050505@oracle.com> Good. Thanks, Vladimir On 10/30/13 4:04 PM, Igor Veresov wrote: > C1 had passed incorrect new value to the post_barrer() in Unsafe.getAndSetObject() intrinsic. > Instead of the new value, on which G1 executes a bunch filters it passed the old value. That caused sporadic barrier omissions and missing rset entries as a result. > > Huge thanks to Mikael Gerdin for helping to track this hard to reproduce issue. > > Webrev: http://cr.openjdk.java.net/~iveresov/8024919/webrev.0/ > > igor > From igor.veresov at oracle.com Wed Oct 30 17:18:55 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Oct 2013 17:18:55 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError In-Reply-To: <52719508.8010100@oracle.com> References: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> <52719508.8010100@oracle.com> Message-ID: <7F43ACD7-5D37-4FA4-9910-4FD4EEC9AC91@oracle.com> Thanks! Here's the renamed updated webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.1/ igor On Oct 30, 2013, at 4:23 PM, Vladimir Kozlov wrote: > Fix looks good. > We use new naming for tests now, please, change to next (or better name if you find): > > test/compiler/inlining/InlineDefaultMethod.java > > Thanks, > Vladimir > > On 10/30/13 3:38 PM, Igor Veresov wrote: >> CHA in C1 incorrectly treats calls to interfaces with default methods. >> We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ >> Testing: affected tests in java/util/stream, the regression test >> From igor.veresov at oracle.com Wed Oct 30 17:19:09 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Oct 2013 17:19:09 -0700 Subject: RFR(S): 8024919 G1: SPECjbb2013 crashes due to a broken object reference In-Reply-To: <52719570.5050505@oracle.com> References: <72A9BBC9-E84C-4A2A-BBC9-0AEDA256D26A@oracle.com> <52719570.5050505@oracle.com> Message-ID: <751B2C99-B413-47E8-A003-69147434FB1E@oracle.com> Thanks, Vladimir! igor On Oct 30, 2013, at 4:25 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/30/13 4:04 PM, Igor Veresov wrote: >> C1 had passed incorrect new value to the post_barrer() in Unsafe.getAndSetObject() intrinsic. >> Instead of the new value, on which G1 executes a bunch filters it passed the old value. That caused sporadic barrier omissions and missing rset entries as a result. >> >> Huge thanks to Mikael Gerdin for helping to track this hard to reproduce issue. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8024919/webrev.0/ >> >> igor >> From vladimir.kozlov at oracle.com Wed Oct 30 18:32:10 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2013 18:32:10 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError In-Reply-To: <7F43ACD7-5D37-4FA4-9910-4FD4EEC9AC91@oracle.com> References: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> <52719508.8010100@oracle.com> <7F43ACD7-5D37-4FA4-9910-4FD4EEC9AC91@oracle.com> Message-ID: <5271B31A.6060209@oracle.com> On 10/30/13 5:18 PM, Igor Veresov wrote: > Thanks! > > Here's the renamed updated webrev: > http://cr.openjdk.java.net/~iveresov/8026735/webrev.1/ Don't use bugid 8026735 for subdir. I suggested 'inlining' to collect all jtreg tests related to inlining. Thanks, Vladimir > > igor > > On Oct 30, 2013, at 4:23 PM, Vladimir Kozlov wrote: > >> Fix looks good. >> We use new naming for tests now, please, change to next (or better name if you find): >> >> test/compiler/inlining/InlineDefaultMethod.java >> >> Thanks, >> Vladimir >> >> On 10/30/13 3:38 PM, Igor Veresov wrote: >>> CHA in C1 incorrectly treats calls to interfaces with default methods. >>> We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ >>> Testing: affected tests in java/util/stream, the regression test >>> > From igor.veresov at oracle.com Wed Oct 30 19:24:07 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Oct 2013 19:24:07 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError In-Reply-To: <5271B31A.6060209@oracle.com> References: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> <52719508.8010100@oracle.com> <7F43ACD7-5D37-4FA4-9910-4FD4EEC9AC91@oracle.com> <5271B31A.6060209@oracle.com> Message-ID: <43386FF6-C2C2-4F00-9911-AD11B6728168@oracle.com> All right. Moved it: http://cr.openjdk.java.net/~iveresov/8026735/webrev.2/ igor On Oct 30, 2013, at 6:32 PM, Vladimir Kozlov wrote: > On 10/30/13 5:18 PM, Igor Veresov wrote: >> Thanks! >> >> Here's the renamed updated webrev: >> http://cr.openjdk.java.net/~iveresov/8026735/webrev.1/ > > Don't use bugid 8026735 for subdir. I suggested 'inlining' to collect all jtreg tests related to inlining. > > Thanks, > Vladimir > >> >> igor >> >> On Oct 30, 2013, at 4:23 PM, Vladimir Kozlov wrote: >> >>> Fix looks good. >>> We use new naming for tests now, please, change to next (or better name if you find): >>> >>> test/compiler/inlining/InlineDefaultMethod.java >>> >>> Thanks, >>> Vladimir >>> >>> On 10/30/13 3:38 PM, Igor Veresov wrote: >>>> CHA in C1 incorrectly treats calls to interfaces with default methods. >>>> We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ >>>> Testing: affected tests in java/util/stream, the regression test >>>> >> From vladimir.kozlov at oracle.com Wed Oct 30 19:56:58 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2013 19:56:58 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError In-Reply-To: <43386FF6-C2C2-4F00-9911-AD11B6728168@oracle.com> References: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> <52719508.8010100@oracle.com> <7F43ACD7-5D37-4FA4-9910-4FD4EEC9AC91@oracle.com> <5271B31A.6060209@oracle.com> <43386FF6-C2C2-4F00-9911-AD11B6728168@oracle.com> Message-ID: <5271C6FA.4070003@oracle.com> Good. Vladimir On 10/30/13 7:24 PM, Igor Veresov wrote: > All right. Moved it: http://cr.openjdk.java.net/~iveresov/8026735/webrev.2/ > > igor > > On Oct 30, 2013, at 6:32 PM, Vladimir Kozlov wrote: > >> On 10/30/13 5:18 PM, Igor Veresov wrote: >>> Thanks! >>> >>> Here's the renamed updated webrev: >>> http://cr.openjdk.java.net/~iveresov/8026735/webrev.1/ >> >> Don't use bugid 8026735 for subdir. I suggested 'inlining' to collect all jtreg tests related to inlining. >> >> Thanks, >> Vladimir >> >>> >>> igor >>> >>> On Oct 30, 2013, at 4:23 PM, Vladimir Kozlov wrote: >>> >>>> Fix looks good. >>>> We use new naming for tests now, please, change to next (or better name if you find): >>>> >>>> test/compiler/inlining/InlineDefaultMethod.java >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/30/13 3:38 PM, Igor Veresov wrote: >>>>> CHA in C1 incorrectly treats calls to interfaces with default methods. >>>>> We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ >>>>> Testing: affected tests in java/util/stream, the regression test >>>>> >>> > From christian.thalinger at oracle.com Wed Oct 30 21:43:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Oct 2013 21:43:15 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError In-Reply-To: <43386FF6-C2C2-4F00-9911-AD11B6728168@oracle.com> References: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> <52719508.8010100@oracle.com> <7F43ACD7-5D37-4FA4-9910-4FD4EEC9AC91@oracle.com> <5271B31A.6060209@oracle.com> <43386FF6-C2C2-4F00-9911-AD11B6728168@oracle.com> Message-ID: <02725876-99BF-47E7-883E-EE5B022AEFFC@oracle.com> Looks good. Thank you for fixing this. On Oct 30, 2013, at 7:24 PM, Igor Veresov wrote: > All right. Moved it: http://cr.openjdk.java.net/~iveresov/8026735/webrev.2/ > > igor > > On Oct 30, 2013, at 6:32 PM, Vladimir Kozlov wrote: > >> On 10/30/13 5:18 PM, Igor Veresov wrote: >>> Thanks! >>> >>> Here's the renamed updated webrev: >>> http://cr.openjdk.java.net/~iveresov/8026735/webrev.1/ >> >> Don't use bugid 8026735 for subdir. I suggested 'inlining' to collect all jtreg tests related to inlining. >> >> Thanks, >> Vladimir >> >>> >>> igor >>> >>> On Oct 30, 2013, at 4:23 PM, Vladimir Kozlov wrote: >>> >>>> Fix looks good. >>>> We use new naming for tests now, please, change to next (or better name if you find): >>>> >>>> test/compiler/inlining/InlineDefaultMethod.java >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/30/13 3:38 PM, Igor Veresov wrote: >>>>> CHA in C1 incorrectly treats calls to interfaces with default methods. >>>>> We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ >>>>> Testing: affected tests in java/util/stream, the regression test >>>>> >>> > From christian.thalinger at oracle.com Wed Oct 30 21:58:30 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Oct 2013 21:58:30 -0700 Subject: RFR(XS): 8027444: mathExact: assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <20131030131734.GC7280@rbackman> References: <20131030131734.GC7280@rbackman> Message-ID: <5957EE6D-D9FD-4E76-85E2-34F67B5C35B4@oracle.com> It would be nice to have at least some evaluation in the bug report. The text below would already be enough. Please link the RFE you?re filing also to JDK-8027444. On Oct 30, 2013, at 6:17 AM, Rickard B?ckman wrote: > Hi, can I please have this change reviewed? > > One of the loop optimizations we are doing doesn't work well with the > MathExact nodes recently added. The short term fix is to disable the > loop optimization if we detect a MathExact node (or rather a FlagsProj > node). I'll file a RFE for fixing this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8027444 > Webrev: http://cr.openjdk.java.net/~rbackman/8027444/ > > /R From christian.thalinger at oracle.com Wed Oct 30 22:03:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 30 Oct 2013 22:03:13 -0700 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: <8917A33C-E071-4BCB-8A10-534D6CFA16E5@oracle.com> References: <52715952.6050806@oracle.com> <8917A33C-E071-4BCB-8A10-534D6CFA16E5@oracle.com> Message-ID: <1E30A850-2607-4CE1-8C25-70D258E7F76C@oracle.com> Looks good. Maybe you should remove ?64 bit? from the comments. On Oct 30, 2013, at 1:16 PM, Roland Westrelin wrote: > Thanks for the review, Vladimir. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8027445/webrev.01/ > > Roland. > > > On Oct 30, 2013, at 8:09 PM, Vladimir Kozlov wrote: > >> On x86 in 64-bit mode any 32-bit arithmetic will clear upper 32 bits. That is why it is not problem on x86. >> >> On SPARC we need explicitly clear upper bits. We have special macroassembler instruction signx(Register d ), please use it instead of sra(). And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. >> >> You are correct about code in enc_String_Compare but for consistency I would suggest to do sign extension there too before next instruction (since chr1_reg is used later): >> >> __ subcc(limit_reg, 1 * sizeof(jchar), chr1_reg); >> >> One additional instruction outside a loop will not kill performance. >> >> Thanks, >> Vladimir >> >> On 10/30/13 11:36 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8027445/webrev.00/ >>> >>> On 64 bit, the integer length input to the StrEquals node may have some bits set in its higher half and cannot be used directly for pointer arithmetic. StrComp is not affected because we add and subtract the length for each memory access. AryEq is not affected because we reload the length for both arrays. I added test cases for all of them anyway. I wasn?t able to reproduce it on x86 but it?s unclear to me whether something similar could happen or not. >>> >>> Roland. >>> > From igor.veresov at oracle.com Wed Oct 30 22:07:48 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 30 Oct 2013 22:07:48 -0700 Subject: RFR(S): 8026735 Stream tests throw java.lang.IncompatibleClassChangeError In-Reply-To: <02725876-99BF-47E7-883E-EE5B022AEFFC@oracle.com> References: <45B5F200-0420-4293-ACF9-6B9C8304B44D@oracle.com> <52719508.8010100@oracle.com> <7F43ACD7-5D37-4FA4-9910-4FD4EEC9AC91@oracle.com> <5271B31A.6060209@oracle.com> <43386FF6-C2C2-4F00-9911-AD11B6728168@oracle.com> <02725876-99BF-47E7-883E-EE5B022AEFFC@oracle.com> Message-ID: <82A0B8A7-7F06-4EAE-96C7-8B79C236EEA5@oracle.com> Thanks, Chris! igor On Oct 30, 2013, at 9:43 PM, Christian Thalinger wrote: > Looks good. Thank you for fixing this. > > On Oct 30, 2013, at 7:24 PM, Igor Veresov wrote: > >> All right. Moved it: http://cr.openjdk.java.net/~iveresov/8026735/webrev.2/ >> >> igor >> >> On Oct 30, 2013, at 6:32 PM, Vladimir Kozlov wrote: >> >>> On 10/30/13 5:18 PM, Igor Veresov wrote: >>>> Thanks! >>>> >>>> Here's the renamed updated webrev: >>>> http://cr.openjdk.java.net/~iveresov/8026735/webrev.1/ >>> >>> Don't use bugid 8026735 for subdir. I suggested 'inlining' to collect all jtreg tests related to inlining. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> igor >>>> >>>> On Oct 30, 2013, at 4:23 PM, Vladimir Kozlov wrote: >>>> >>>>> Fix looks good. >>>>> We use new naming for tests now, please, change to next (or better name if you find): >>>>> >>>>> test/compiler/inlining/InlineDefaultMethod.java >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/30/13 3:38 PM, Igor Veresov wrote: >>>>>> CHA in C1 incorrectly treats calls to interfaces with default methods. >>>>>> We decided to put a temporary bandaid to disable CHA-driven inlining for invokeinterface on interfaces with default methods in C1. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8026735/webrev.0/ >>>>>> Testing: affected tests in java/util/stream, the regression test >>>>>> >>>> >> > From roland.westrelin at oracle.com Thu Oct 31 01:25:04 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 Oct 2013 09:25:04 +0100 Subject: RFR(S): 8024919 G1: SPECjbb2013 crashes due to a broken object reference In-Reply-To: <72A9BBC9-E84C-4A2A-BBC9-0AEDA256D26A@oracle.com> References: <72A9BBC9-E84C-4A2A-BBC9-0AEDA256D26A@oracle.com> Message-ID: <131DBA9E-336B-4700-BFBE-B1C6E3AB83DE@oracle.com> > Webrev: http://cr.openjdk.java.net/~iveresov/8024919/webrev.0/ It looks good. Roland. From igor.veresov at oracle.com Thu Oct 31 01:19:33 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 31 Oct 2013 08:19:33 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8026735: Stream tests throw java.lang.IncompatibleClassChangeError Message-ID: <20131031081947.519F76286B@hg.openjdk.java.net> Changeset: 4d3575d37a07 Author: iveresov Date: 2013-10-30 22:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4d3575d37a07 8026735: Stream tests throw java.lang.IncompatibleClassChangeError Summary: Put a band-aid to disable CHA-based inlining for interfaces with default methods in C1 Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp + test/compiler/inlining/InlineDefaultMethod.java From roland.westrelin at oracle.com Thu Oct 31 02:26:08 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 Oct 2013 10:26:08 +0100 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: <52715952.6050806@oracle.com> References: <52715952.6050806@oracle.com> Message-ID: > And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. In 32bit mode, it can happen that the upper half of a register is non null but that won?t affect the following load because the upper half is ignored on the memory access anyway. So this is really 64 bit only. Roland. From igor.veresov at oracle.com Thu Oct 31 03:57:26 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 31 Oct 2013 03:57:26 -0700 Subject: RFR(S): 8024919 G1: SPECjbb2013 crashes due to a broken object reference In-Reply-To: <131DBA9E-336B-4700-BFBE-B1C6E3AB83DE@oracle.com> References: <72A9BBC9-E84C-4A2A-BBC9-0AEDA256D26A@oracle.com> <131DBA9E-336B-4700-BFBE-B1C6E3AB83DE@oracle.com> Message-ID: Thanks, Roland! igor On Oct 31, 2013, at 1:25 AM, Roland Westrelin wrote: >> Webrev: http://cr.openjdk.java.net/~iveresov/8024919/webrev.0/ > > It looks good. > > Roland. From vladimir.kozlov at oracle.com Thu Oct 31 08:39:31 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Oct 2013 08:39:31 -0700 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: References: <52715952.6050806@oracle.com> Message-ID: <527279B3.3060604@oracle.com> On 10/31/13 2:26 AM, Roland Westrelin wrote: > >> And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. > > In 32bit mode, it can happen that the upper half of a register is non null but that won?t affect the following load because the upper half is ignored on the memory access anyway. So this is really 64 bit only. Yes, you are right. Vladimir > > Roland. > From roland.westrelin at oracle.com Thu Oct 31 08:47:06 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 Oct 2013 16:47:06 +0100 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: <527279B3.3060604@oracle.com> References: <52715952.6050806@oracle.com> <527279B3.3060604@oracle.com> Message-ID: >>> And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. >> >> In 32bit mode, it can happen that the upper half of a register is non null but that won?t affect the following load because the upper half is ignored on the memory access anyway. So this is really 64 bit only. > > Yes, you are right. Should I add the #ifdef LP64 back or leave it as it is? Roland. From vladimir.kozlov at oracle.com Thu Oct 31 08:57:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Oct 2013 08:57:32 -0700 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: References: <52715952.6050806@oracle.com> <527279B3.3060604@oracle.com> Message-ID: <52727DEC.6010909@oracle.com> On 10/31/13 8:47 AM, Roland Westrelin wrote: >>>> And it can happen in 32 bit mode since SPARC's registers are 64-bit, so don't put it under #ifdef LP64. >>> >>> In 32bit mode, it can happen that the upper half of a register is non null but that won?t affect the following load because the upper half is ignored on the memory access anyway. So this is really 64 bit only. >> >> Yes, you are right. > > Should I add the #ifdef LP64 back or leave it as it is? Leave as it is because, first, we don't support 32-bit SPARC anymore and, second, in other places (for different reasons) we don't use such #ifdef for signx(). Third, it is safe to execute it in 32-bit since code is still correct. Vladimir > > Roland. > From roland.westrelin at oracle.com Thu Oct 31 09:09:07 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 Oct 2013 17:09:07 +0100 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: <52727DEC.6010909@oracle.com> References: <52715952.6050806@oracle.com> <527279B3.3060604@oracle.com> <52727DEC.6010909@oracle.com> Message-ID: > Leave as it is because, first, we don't support 32-bit SPARC anymore and, second, in other places (for different reasons) we don't use such #ifdef for signx(). Third, it is safe to execute it in 32-bit since code is still correct. Ok. Thanks. Roland. From roland.westrelin at oracle.com Thu Oct 31 09:10:01 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 31 Oct 2013 17:10:01 +0100 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: <1E30A850-2607-4CE1-8C25-70D258E7F76C@oracle.com> References: <52715952.6050806@oracle.com> <8917A33C-E071-4BCB-8A10-534D6CFA16E5@oracle.com> <1E30A850-2607-4CE1-8C25-70D258E7F76C@oracle.com> Message-ID: > Looks good. Maybe you should remove ?64 bit? from the comments. Thanks for the review. As discussed with Vladimir this only affects execution on 64 bit so I?ll leave the comments untouched. Roland. From igor.veresov at oracle.com Thu Oct 31 14:45:05 2013 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 31 Oct 2013 21:45:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8024919: G1: SPECjbb2013 crashes due to a broken object reference Message-ID: <20131031214511.DACA3628BC@hg.openjdk.java.net> Changeset: 946a8294ab15 Author: iveresov Date: 2013-10-31 04:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/946a8294ab15 8024919: G1: SPECjbb2013 crashes due to a broken object reference Summary: Pass correct new value to post_barrer() in Unsafe.getAndSetObject() C1 intrinsic Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp From christian.thalinger at oracle.com Thu Oct 31 15:02:56 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 31 Oct 2013 15:02:56 -0700 Subject: 8027445: SIGSEGV at TestFloatingDecimal.testAppendToDouble()I In-Reply-To: References: <52715952.6050806@oracle.com> <8917A33C-E071-4BCB-8A10-534D6CFA16E5@oracle.com> <1E30A850-2607-4CE1-8C25-70D258E7F76C@oracle.com> Message-ID: <3338E61F-61C5-4185-8562-FCE8DA5C3575@oracle.com> Yes, I agree. Looks good. On Oct 31, 2013, at 9:10 AM, Roland Westrelin wrote: >> Looks good. Maybe you should remove ?64 bit? from the comments. > > Thanks for the review. As discussed with Vladimir this only affects execution on 64 bit so I?ll leave the comments untouched. > > Roland. From mikael.vidstedt at oracle.com Thu Oct 31 16:09:09 2013 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 31 Oct 2013 16:09:09 -0700 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION Message-ID: <5272E315.5080201@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8026775 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.01/webrev/ Exec summary: The stack banging code in the UncommonTrapBlob is not pre-touching all the stack shadow pages as it should. The result is that under some circumstances it may leave unmapped "holes" on the stack, and when a compiled method later touches a stack page on the other side of the hole Windows will raise an exception because it requires all stack pages to be touched/mapped in order. Details: The code in MacroAssembler::bang_stack_size() is supposed to generate code which touches enough stack pages to make room for the interpreter frame for the deoptimized method and then touch an additional StackShadowPages pages. However, the code fails to do this because: a) it touches the same page twice (the last page touched in the first loop is the exact same address touched the first time in the second loop), and b) it doesn't loop all the way up to *and including* StackShadowPages (the "-1" is incorrect, and so is the less than) The corresponding code in AbstractInterpreterGenerator::bang_stack_shadow_pages() touches all pages from 1 page below sp all the way down to StackShadowPages below sp *inclusive*. The UncommonTrapBlob is supposed to mimic that exact same behavior. Cheers, Mikael From christian.thalinger at oracle.com Thu Oct 31 16:33:40 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 31 Oct 2013 16:33:40 -0700 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: <5272E315.5080201@oracle.com> References: <5272E315.5080201@oracle.com> Message-ID: <71FADC2F-75BF-4CD4-BACC-9E6FC7D2380E@oracle.com> Looks good. Thanks for getting to the bottom of this! On Oct 31, 2013, at 4:09 PM, Mikael Vidstedt wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026775 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.01/webrev/ > > Exec summary: > > The stack banging code in the UncommonTrapBlob is not pre-touching all the stack shadow pages as it should. The result is that under some circumstances it may leave unmapped "holes" on the stack, and when a compiled method later touches a stack page on the other side of the hole Windows will raise an exception because it requires all stack pages to be touched/mapped in order. > > > Details: > > The code in MacroAssembler::bang_stack_size() is supposed to generate code which touches enough stack pages to make room for the interpreter frame for the deoptimized method and then touch an additional StackShadowPages pages. However, the code fails to do this because: > > a) it touches the same page twice (the last page touched in the first loop is the exact same address touched the first time in the second loop), and > b) it doesn't loop all the way up to *and including* StackShadowPages (the "-1" is incorrect, and so is the less than) > > The corresponding code in AbstractInterpreterGenerator::bang_stack_shadow_pages() touches all pages from 1 page below sp all the way down to StackShadowPages below sp *inclusive*. The UncommonTrapBlob is supposed to mimic that exact same behavior. > > Cheers, > Mikael > From vladimir.kozlov at oracle.com Thu Oct 31 16:53:06 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Oct 2013 16:53:06 -0700 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: <5272E315.5080201@oracle.com> References: <5272E315.5080201@oracle.com> Message-ID: <5272ED62.5000002@oracle.com> Good. Thanks, Vladimir On 10/31/13 4:09 PM, Mikael Vidstedt wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026775 > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.01/webrev/ > > Exec summary: > > The stack banging code in the UncommonTrapBlob is not pre-touching all > the stack shadow pages as it should. The result is that under some > circumstances it may leave unmapped "holes" on the stack, and when a > compiled method later touches a stack page on the other side of the hole > Windows will raise an exception because it requires all stack pages to > be touched/mapped in order. > > > Details: > > The code in MacroAssembler::bang_stack_size() is supposed to generate > code which touches enough stack pages to make room for the interpreter > frame for the deoptimized method and then touch an additional > StackShadowPages pages. However, the code fails to do this because: > > a) it touches the same page twice (the last page touched in the first > loop is the exact same address touched the first time in the second > loop), and > b) it doesn't loop all the way up to *and including* StackShadowPages > (the "-1" is incorrect, and so is the less than) > > The corresponding code in > AbstractInterpreterGenerator::bang_stack_shadow_pages() touches all > pages from 1 page below sp all the way down to StackShadowPages below sp > *inclusive*. The UncommonTrapBlob is supposed to mimic that exact same > behavior. > > Cheers, > Mikael > From igor.veresov at oracle.com Thu Oct 31 17:49:28 2013 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 31 Oct 2013 17:49:28 -0700 Subject: RFR (S): 8026775: nsk/jvmti/RedefineClasses/StressRedefine crashes due to EXCEPTION_ACCESS_VIOLATION In-Reply-To: <5272E315.5080201@oracle.com> References: <5272E315.5080201@oracle.com> Message-ID: <06335212-81F2-459C-A17E-566E19D5C3E6@oracle.com> That was a fun one! Looks good. igor On Oct 31, 2013, at 4:09 PM, Mikael Vidstedt wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8026775 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8026775/webrev.01/webrev/ > > Exec summary: > > The stack banging code in the UncommonTrapBlob is not pre-touching all the stack shadow pages as it should. The result is that under some circumstances it may leave unmapped "holes" on the stack, and when a compiled method later touches a stack page on the other side of the hole Windows will raise an exception because it requires all stack pages to be touched/mapped in order. > > > Details: > > The code in MacroAssembler::bang_stack_size() is supposed to generate code which touches enough stack pages to make room for the interpreter frame for the deoptimized method and then touch an additional StackShadowPages pages. However, the code fails to do this because: > > a) it touches the same page twice (the last page touched in the first loop is the exact same address touched the first time in the second loop), and > b) it doesn't loop all the way up to *and including* StackShadowPages (the "-1" is incorrect, and so is the less than) > > The corresponding code in AbstractInterpreterGenerator::bang_stack_shadow_pages() touches all pages from 1 page below sp all the way down to StackShadowPages below sp *inclusive*. The UncommonTrapBlob is supposed to mimic that exact same behavior. > > Cheers, > Mikael >