From rickard.backman at oracle.com Mon Dec 1 08:15:50 2014 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 1 Dec 2014 09:15:50 +0100 Subject: RFR(XS): 8066045: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <1F4744BB-A554-4990-A606-FEAF6E9E838D@oracle.com> References: <1F4744BB-A554-4990-A606-FEAF6E9E838D@oracle.com> Message-ID: <20141201081550.GC4076@rbackman> Looks good. /R On 11/27, Roland Westrelin wrote: > Fix for 8054478 made incorrect assumption about graph shape: > > http://cr.openjdk.java.net/~roland/8066045/webrev.00/ > > Roland. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From tobias.hartmann at oracle.com Mon Dec 1 08:27:00 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 01 Dec 2014 09:27:00 +0100 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <54786A47.2030505@oracle.com> References: <54786A47.2030505@oracle.com> Message-ID: <547C2654.8030808@oracle.com> Hi Pavel, the tests fail with a client VM: > Error occurred during initialization of VM > Incompatible compilation policy selected Please execute them on JPRT to make sure they work on all platforms. Best, Tobias On 28.11.2014 13:27, Pavel Punegov wrote: > Hi all, > > please review new tests developed as a part of the test task: > JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 > webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ > > Description: > There are two tests to verify level transitions in Tiered Compilation: > 1. LevelTransitionTest verifies that in case of no load on compiler queues test > methods go through common transition patterns: > 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different > trivial methods, and 0 -> 4 after deoptimization. > Test provokes compilations of the method and checks that all transitions are > correct for CompilationPolicyChoice=2 and 3. > > 2. ConstantGettersTransitions is a test adapted from the test Tobias used for > 8056071 (see [*] for details). It checks that all constant getters are always > compiled with C1. > > [*] https://bugs.openjdk.java.net/browse/JDK-8028590 > > Testing: done locally > From roland.westrelin at oracle.com Mon Dec 1 08:44:34 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Dec 2014 09:44:34 +0100 Subject: RFR(XS): 8066045: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <20141201081550.GC4076@rbackman> References: <1F4744BB-A554-4990-A606-FEAF6E9E838D@oracle.com> <20141201081550.GC4076@rbackman> Message-ID: Thanks for the review, Rickard but I pushed this already with a single review as it was a very simple change. Roland. > On Dec 1, 2014, at 9:15 AM, Rickard B?ckman wrote: > > Looks good. > > /R > > On 11/27, Roland Westrelin wrote: >> Fix for 8054478 made incorrect assumption about graph shape: >> >> http://cr.openjdk.java.net/~roland/8066045/webrev.00/ >> >> Roland. From tatiana.pivovarova at oracle.com Mon Dec 1 10:02:50 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 01 Dec 2014 13:02:50 +0300 Subject: RFR(XXS): 8066141: compiler/whitebox/GetNMethodTest.java: java.lang.RuntimeException: blob_type[MethodProfiled] for 2 level isn't MethodNonProfiled In-Reply-To: References: <5478B7BC.90600@oracle.com> Message-ID: <547C3CCA.1040902@oracle.com> Hi Igor, Thanks for your reviews! Tatiana On 11/29/2014 01:37 AM, Igor Veresov wrote: > Looks fine. > > igor > >> On Nov 28, 2014, at 9:58 AM, Tatiana Pivovarova wrote: >> >> Hi, >> >> please review this small patch >> >> bugid: https://bugs.openjdk.java.net/browse/JDK-8066141 >> webrev: http://cr.openjdk.java.net/~iignatyev/tpivovarova/8066141/webrev.00/ >> >> Problem: >> It is a small testbug. NMethod compares with BlobType.MethodNonProfiled whereas must be compared with BlobType.MethodProfiled. >> >> Solution: >> >> Testing: >> Reproduced locally with parameters "-server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:NativeMemoryTracking=detail -XX:ReservedCodeCacheSize=256M -XX:TieredStopAtLevel=3" on the latest jdk. >> Test passed after changes. >> >> Thanks, >> Tatiana From roland.westrelin at oracle.com Mon Dec 1 12:28:56 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Dec 2014 13:28:56 +0100 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 Message-ID: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> http://cr.openjdk.java.net/~roland/8064703/webrev.00/ If an arraycopy is used to initialize a just allocated array, when possible we skip the array initialization and let arraycopy do the initialization. If an uncommon trap is triggered after the allocation and before the arraycopy, then an uninitialized array can escape the compiled method to the interpreter. This is fixed by making the uncommon trap resume execution at the allocation rather than the arraycopy and redo the allocation (Vladimir?s suggestion). Roland. From roland.westrelin at oracle.com Mon Dec 1 14:46:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Dec 2014 15:46:00 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses Message-ID: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> http://cr.openjdk.java.net/~roland/8066103/webrev.00/ Given a list of range checks of the form i + constant http://cr.openjdk.java.net/~roland/8048170/webrev.00/ After range check smearing, an array access may depend on multiple range checks to be valid. PhaseIdealLoop::split_if_with_blocks_post() shouldn?t replace an IF by a dominated IF for the same test for range checks otherwise it can make an array access bypass a range check that it depends on. Roland. From vladimir.x.ivanov at oracle.com Mon Dec 1 16:14:06 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 01 Dec 2014 20:14:06 +0400 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 In-Reply-To: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> References: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> Message-ID: <547C93CE.2020200@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/1/14, 4:28 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8064703/webrev.00/ > > If an arraycopy is used to initialize a just allocated array, when possible we skip the array initialization and let arraycopy do the initialization. If an uncommon trap is triggered after the allocation and before the arraycopy, then an uninitialized array can escape the compiled method to the interpreter. This is fixed by making the uncommon trap resume execution at the allocation rather than the arraycopy and redo the allocation (Vladimir?s suggestion). > > Roland. > From vladimir.kozlov at oracle.com Mon Dec 1 17:28:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 09:28:08 -0800 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 In-Reply-To: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> References: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> Message-ID: <547CA528.4000804@oracle.com> null_check() will "confuse" tightly_coupled_allocation(). Why you moved it? Thanks, Vladimir k On 12/1/14 4:28 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8064703/webrev.00/ > > If an arraycopy is used to initialize a just allocated array, when possible we skip the array initialization and let arraycopy do the initialization. If an uncommon trap is triggered after the allocation and before the arraycopy, then an uninitialized array can escape the compiled method to the interpreter. This is fixed by making the uncommon trap resume execution at the allocation rather than the arraycopy and redo the allocation (Vladimir?s suggestion). > > Roland. > From vladimir.kozlov at oracle.com Mon Dec 1 17:41:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 09:41:33 -0800 Subject: RFR(XS): 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed In-Reply-To: <34E8B442-C805-4217-8CC0-EF7D93D3C410@oracle.com> References: <34E8B442-C805-4217-8CC0-EF7D93D3C410@oracle.com> Message-ID: <547CA84D.4060807@oracle.com> Looks good. Thanks, Vladimir On 12/1/14 7:11 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8048170/webrev.00/ > > After range check smearing, an array access may depend on multiple range checks to be valid. PhaseIdealLoop::split_if_with_blocks_post() shouldn?t replace an IF by a dominated IF for the same test for range checks otherwise it can make an array access bypass a range check that it depends on. > > Roland. > From roland.westrelin at oracle.com Mon Dec 1 18:05:10 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 1 Dec 2014 19:05:10 +0100 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 In-Reply-To: <547CA528.4000804@oracle.com> References: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> <547CA528.4000804@oracle.com> Message-ID: <52E958EF-842B-4A53-8846-61A360361768@oracle.com> > null_check() will "confuse" tightly_coupled_allocation(). Why you moved it? I moved tightly_coupled_allocation() back where it was in 8 and before. So tightly_coupled_allocation() only succeeds if the null_check is a noop. Roland. > > Thanks, > Vladimir k > > On 12/1/14 4:28 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8064703/webrev.00/ >> >> If an arraycopy is used to initialize a just allocated array, when possible we skip the array initialization and let arraycopy do the initialization. If an uncommon trap is triggered after the allocation and before the arraycopy, then an uninitialized array can escape the compiled method to the interpreter. This is fixed by making the uncommon trap resume execution at the allocation rather than the arraycopy and redo the allocation (Vladimir?s suggestion). >> >> Roland. >> From vladimir.kozlov at oracle.com Mon Dec 1 18:31:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 10:31:44 -0800 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 In-Reply-To: <52E958EF-842B-4A53-8846-61A360361768@oracle.com> References: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> <547CA528.4000804@oracle.com> <52E958EF-842B-4A53-8846-61A360361768@oracle.com> Message-ID: <547CB410.8000208@oracle.com> On 12/1/14 10:05 AM, Roland Westrelin wrote: >> null_check() will "confuse" tightly_coupled_allocation(). Why you moved it? > > I moved tightly_coupled_allocation() back where it was in 8 and before. So tightly_coupled_allocation() only succeeds if the null_check is a noop. Got it. Looks good. Thanks, Vladimir > > Roland. > >> >> Thanks, >> Vladimir k >> >> On 12/1/14 4:28 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8064703/webrev.00/ >>> >>> If an arraycopy is used to initialize a just allocated array, when possible we skip the array initialization and let arraycopy do the initialization. If an uncommon trap is triggered after the allocation and before the arraycopy, then an uninitialized array can escape the compiled method to the interpreter. This is fixed by making the uncommon trap resume execution at the allocation rather than the arraycopy and redo the allocation (Vladimir?s suggestion). >>> >>> Roland. >>> > From vladimir.kozlov at oracle.com Mon Dec 1 18:50:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 10:50:42 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> Message-ID: <547CB882.8040500@oracle.com> The propose fix is correct. Comments are good. (nb_checks == 0) check and rc0 could be moved before (index1) to avoid duplication on both paths. Add tests with i-c negative constants (and combinations -c and +c) when i starts with > c value. Thanks, Vladimir On 12/1/14 6:46 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8066103/webrev.00/ > > Given a list of range checks of the form i + constant > Roland. > From igor.ignatyev at oracle.com Mon Dec 1 20:52:59 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 01 Dec 2014 23:52:59 +0300 Subject: RFR (XS) : JDK-8066290 : Port JDK-8066191 into hotspot Message-ID: <547CD52B.7040505@oracle.com> http://cr.openjdk.java.net/~iignatyev/8066290/webrev.00/ 86 lines changed: 86 ins; 0 del; 0 mod; Hi all, please review porting TimeLimitedRunner from jdk testlibrary to hotspot. bug: https://bugs.openjdk.java.net/browse/JDK-8066290 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029928.html -- Thanks, Igor From vladimir.kozlov at oracle.com Mon Dec 1 22:19:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 14:19:05 -0800 Subject: RFR (XS) : JDK-8066290 : Port JDK-8066191 into hotspot In-Reply-To: <547CD52B.7040505@oracle.com> References: <547CD52B.7040505@oracle.com> Message-ID: <547CE959.7030102@oracle.com> Looks good. Thanks, Vladimir On 12/1/14 12:52 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8066290/webrev.00/ > 86 lines changed: 86 ins; 0 del; 0 mod; > > Hi all, > > please review porting TimeLimitedRunner from jdk testlibrary to hotspot. > > bug: https://bugs.openjdk.java.net/browse/JDK-8066290 > review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029928.html > > From christian.thalinger at oracle.com Mon Dec 1 22:49:25 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 1 Dec 2014 14:49:25 -0800 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <5477075A.1090205@oracle.com> References: <5477075A.1090205@oracle.com> Message-ID: <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> I didn?t verify all new messages but this looks very useful. The only thing I could complain about is: + "JVMStartup should have exit value '%d'.%n%s", JVMStartup probably refers to some internal method. A more general message might be better. In any case, looks good to me. > On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova wrote: > > Hi, > > Could you please review fix for 8054892? > Problem: CLI tests do not show what exactly went wrong when test failed. They show an error behavior is not as expected. > Solution: Added explanation which behavior is expected and why it is so. > > Base class /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java changed to use error string, submitted by tests classes. > -exitErrorMessage message to be shown if exit code of JVM process is not as expected. > -wrongWarningMessage message to be shown if warning messages in output are not as expected. > -optionErrorString to be shown if option value is not as expected. > Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ and test/compiler/intrinsics/sha/cli folders. > > bug: https://bugs.openjdk.java.net/browse/JDK-8054892 > webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ > > Thanks, > Evgeniya Stepanova > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Tue Dec 2 00:20:56 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 1 Dec 2014 16:20:56 -0800 (PST) Subject: JEP 233: Generate Run-Time Compiler Tests Automatically Message-ID: <20141202002056.9834144C12@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/233 - Mark From mark.reinhold at oracle.com Tue Dec 2 00:30:52 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 1 Dec 2014 16:30:52 -0800 (PST) Subject: JEP 234: Additional Run-Time Compiler JVM Trace Events Message-ID: <20141202003052.DE74044C1A@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/234 - Mark From vladimir.kozlov at oracle.com Tue Dec 2 01:54:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 17:54:16 -0800 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <5477A263.6090102@oracle.com> References: <5477A263.6090102@oracle.com> Message-ID: <547D1BC8.7000301@oracle.com> Why you need new Unsafe.getCompiler()? thanks, Vladimir On 11/27/14 2:14 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ > 220 lines changed: 212 ins; 8 del; 0 mod; > > http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ > 4 lines changed: 4 ins; 0 del; 0 mod; > > Hi all, > > please review the patch which adds > - a new whitebox method 'deoptimizeFrames' which deoptimizes methods > which are currently on stack > - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net which > returns 0, 1, 2 if it is interpreted, compiled by c1, c2 accordingly. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 > testing: jprt + new added test > From vladimir.kozlov at oracle.com Tue Dec 2 02:03:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 18:03:56 -0800 Subject: RFR(M) : 8064669 : compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts In-Reply-To: <5471999B.8010604@oracle.com> References: <546619CA.7080801@oracle.com> <546E4304.4030301@oracle.com> <546F5B62.4000707@oracle.com> <5471999B.8010604@oracle.com> Message-ID: <547D1E0C.9060802@oracle.com> Looks good now. Thanks, Vladimir On 11/23/14 12:23 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8064669/webrev.01/ > 346 lines changed: 271 ins; 42 del; 33 mod; > > On 11/21/2014 06:33 PM, Igor Ignatyev wrote: >> Vladimir, >> >> On 11/20/2014 10:37 PM, Vladimir Kozlov wrote: >>> Could you add comments to create_sweeper_thread()? It is not clear from >>> first glance. >> sure. > - replaced instantiation of j.l.Thread by Thread::allocate_threadObj method > - added comments >>> >>> You create a second CodeCacheSweeperThread (first is created during VM >>> startup) to just run sweeper_thread_entry(). Right? How these 2 threads >>> interacts (I mean do we need locks?). Or CodeCache_lock in >>> sweeper_thread_entry() is enough? >> it is enough for everything except statistics like _flushed_count, >> _zombified_count, _total_time_sweeping, etc. I'll think how to deal w/ >> them. > - introduced NMethodSweeper::_stat_lock -- the mutex which is used > during sweeper's statistics updates > - moved statistics updates from NMethodSweeper::process_nmethod >>> >>> How you stop InfiniteLoop daemon thread? It will run after VM exits? >> not it won't, deamon threads stop on VM exit. >> >>> >>> The rest change seems fine. > during testing, I found that sweeper_thread can complete its work and be > deleted, so sweeper_thread->threadObj() can be collected before > JNIHandles::make_local creates a handler. to prevent such situations, I > moved Thread::start after JNIHandles::make_local >>> >>> Thanks, >>> Vladimir >>> >>> On 11/14/14 7:03 AM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8064669/webrev.00/ >>>> 261 lines changed: 231 ins; 22 del; 8 mod; >>>> >>>> Hi all, >>>> >>>> Please review patch: >>>> >>>> Problems: >>>> 0. NMethodSweeper::possibly_sweep is executed outside >>>> CodeCacheSweeperThread >>>> 1. DummyBlob is initialized after the lock is released, so other >>>> threads >>>> are able to see uninitialized blob >>>> 2. NMethodSweeper::sweep_code_cache can pass null to process_nmethod, >>>> this also can lead to a crash. this situation can happen if safepoint >>>> happens during sweeping and after safepoint another thread iterates >>>> over >>>> all nmethods. >>>> >>>> Fix: >>>> 0. WB_ForceNMethodSweep use CodeCacheSweeperThread to execute >>>> possibly_sweep >>>> 1. move ctor invocation to locked section >>>> 2. handle safepoint after processing nmethod in >>>> NMethodSweeper::sweep_code_cache >>>> >>>> 3. added new test to verify that forceNMethodSweep actually work >>>> 4. AllocationCodeBlobTest is modified >>>> - to checks that deoptimization works fine w/ dummy blobs >>>> - to execute forceNMethodSweep more often to increase a chance to >>>> catch such kind problems >>>> >>>> jbs:https://bugs.openjdk.java.net/browse/JDK-8064669 >>>> testing: jprt + compiler/whitebox tests From vladimir.kozlov at oracle.com Tue Dec 2 02:41:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 18:41:42 -0800 Subject: [9] RFR(S) 8065618: C2 RA incorrectly removes kill projections In-Reply-To: <20141124082829.GN27319@rbackman> References: <546FD9AF.6080008@oracle.com> <20141124082829.GN27319@rbackman> Message-ID: <547D26E6.4050005@oracle.com> Good suggestion, Rickard. I filed RFE: https://bugs.openjdk.java.net/browse/JDK-8066312 Thanks, Vladimir On 11/24/14 12:28 AM, Rickard B?ckman wrote: > Vladimir, > > I think it would be great if the for loop that looks for the SCMemProj > could be moved out to be a function on it's own and just have > if (n->is_MachProj() && n->has_SCMemProj()) { > return false; > } > > has_SCMemProj() could be replaced by something else. > > Otherwise it looks good. > > /R > > On 11/21, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8065618/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8065618 >> >> Some nodes have SCMemProj projection node to keep them alive even >> when their result is not used because they have memory side effects. >> For example, EncodeISOArrayNode and loadstore nodes like >> CompareAndSwapPNode. Generated code for such nodes may kill some >> registers and flags during execution. Killed registers are declared >> in 'effect' list in mach nodes definitions in .ad files. For each >> killed register MachProj node is created without use: >> >> 112 encode_iso_array === 103 125 113 114 108 119 >> 120 121 122 [[ 116 117 118 123 124 127 131 134 102 156 >> ]] !jvms: ISO_8859_1$Encoder::encode @ bci:32 Test6896617::test @ >> bci:26 >> 116 MachProj === 112 [[]] #1 >> 117 MachProj === 112 [[]] #2 >> 118 MachProj === 112 [[]] #3 >> 127 SCMemProj === 112 [[ 126 136 138 139 140 150 >> 160 ]] Memory: @BotPTR *+bot, idx=Bot; !jvms: >> ISO_8859_1$Encoder::encode @ bci:32 Test6896617::test @ bci:26 >> 123 MachProj === 112 [[]] #4 >> 124 MachProj === 112 [[]] #5 >> >> Register Allocator in PhaseChaitin::build_ifg_physical() removes >> nodes which are not used (dead). Nodes with >> >> To keep such nodes alive when their result is not used there method >> PhaseChaitin::add_input_to_liveout() puts node's LiveRange on >> liveout list when the node has SCMemProj projection. >> >> Unfortunately SCMemProj node could be placed in a block in such >> order that kill MachProj nodes are processed first (as in example >> above). When those MachProj are processed the def node looks like >> dead and these nodes are removed from graph. As result killed >> register is not marked as killed anymore and it could be used after >> code which kills/modifies it. >> >> I was not able to write test with existing VM code. encodeISOArray() >> method can't be called directly - it is part of >> sun.nio.cs.ISO_8859_1$Encoder::encode() which calls it in a loop. >> There is enough code after encodeISOArray() call in encode() method >> which prevents using the same register after encode(). I have >> experimental project with intrinsics which hits this problem and I >> verified the fix with it. >> >> Thanks, >> Vladimir >> >> >> >> From vladimir.kozlov at oracle.com Tue Dec 2 03:12:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 01 Dec 2014 19:12:33 -0800 Subject: RFC: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 In-Reply-To: <3426B0AC-E3EC-403C-AFC7-DFE54B93B024@oracle.com> References: <8EDF29FA-40E0-4C5E-BC4C-0AF4067338EE@oracle.com> <546BD3E7.9020503@oracle.com> <538B6724-FD67-4EDF-AE49-1ED9D857FE18@oracle.com> <97D74749-A4EB-4E96-AD87-D42D250612A9@oracle.com> <546E5701.5090605@oracle.com> <3426B0AC-E3EC-403C-AFC7-DFE54B93B024@oracle.com> Message-ID: <547D2E21.5020403@oracle.com> This looks good. Thanks, Vladimir On 11/26/14 1:52 AM, Roland Westrelin wrote: > Here is a new webrev that should address the comments: > > http://cr.openjdk.java.net/~roland/6898462/webrev.01/ > > Popping all frames made the change much simpler. > > Roland. > >> On Nov 20, 2014, at 10:48 PM, John Rose wrote: >> >> Some more thoughts on testing this fix: >> >> Existing tests cover the intentions of this fix, since the fix responds to existing test crashes. This fix should upgrade their behavior to a more graceful OOME instead of a crash. >> >> A regression test we need for this is one which exercises the new code. If we are sure existing stress tests do this already, and if we are confident that we will recognize regressions from this code, I think that's enough to get by. >> >> The small reproducer unit test (TestDeoptOOM.java) should reliably exercise OOME and reallocating deopts at the same time, and nothing else; it should expect an OOME and not crash. Its value is disagnose-ability, since it exercises the new code paths. It doesn't really increase coverage. >> >> Does it need to be tested nightly or on multiple platforms? No, I think not. >> >> ? John >> >> On Nov 20, 2014, at 1:02 PM, Vladimir Kozlov wrote: >> >>> Most likely we still fail existing tests since OOM behavior is different (delayed) with EA and this fix. GCBasher test we can fix (disable EA or change catch code) and I hope Kitchensink does not care where OOM is thrown. >>> >>> I would say to not spend time on existing tests failures which are hard to reproduce. Fix current bug, closed is as resolved and if some tests fail after that we create a new bug and see how we can fix them. >>> >>> Thanks, >>> >>> >>> On 11/20/14 11:57 AM, Roland Westrelin wrote: >>>>> So, I concur that popping all the frames is the best thing to do for now. >>>> >>>> Thanks and thanks for the other comments. I?ll send an updated webrev. >>>> >>>> The other question is how much testing we think we need for this. Is it sufficient to check that it doesn?t break normal execution and that the regression test I?m adding covers all scenarios we can think of? Or do we want to reproduce failures that were reported on existing tests? The problem with doing that is that they are all hard to reproduce and it seems it would be very time consuming. Also I?m not sure what guarantees we would get out of it: from one run to another depending how much inlining a compilation does we could pop more or less frames in case of an OOM so the effect on the test case could vary. That this change doesn?t break a test case won?t mean it doesn?t break it on another run. What do you think? >>>> >>>> Roland. >>>> >> > From roland.westrelin at oracle.com Tue Dec 2 09:24:41 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 2 Dec 2014 10:24:41 +0100 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 In-Reply-To: <547CB410.8000208@oracle.com> References: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> <547CA528.4000804@oracle.com> <52E958EF-842B-4A53-8846-61A360361768@oracle.com> <547CB410.8000208@oracle.com> Message-ID: <8ED6357C-C473-4776-B04E-2994D997C73A@oracle.com> Thanks for the reviews Vladimir & Vladimir. Roland. > On Dec 1, 2014, at 7:31 PM, Vladimir Kozlov wrote: > > On 12/1/14 10:05 AM, Roland Westrelin wrote: >>> null_check() will "confuse" tightly_coupled_allocation(). Why you moved it? >> >> I moved tightly_coupled_allocation() back where it was in 8 and before. So tightly_coupled_allocation() only succeeds if the null_check is a noop. > > Got it. > > Looks good. > > Thanks, > Vladimir > >> >> Roland. >> >>> >>> Thanks, >>> Vladimir k >>> >>> On 12/1/14 4:28 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8064703/webrev.00/ >>>> >>>> If an arraycopy is used to initialize a just allocated array, when possible we skip the array initialization and let arraycopy do the initialization. If an uncommon trap is triggered after the allocation and before the arraycopy, then an uninitialized array can escape the compiled method to the interpreter. This is fixed by making the uncommon trap resume execution at the allocation rather than the arraycopy and redo the allocation (Vladimir?s suggestion). >>>> >>>> Roland. >>>> >> From roland.westrelin at oracle.com Tue Dec 2 09:25:04 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 2 Dec 2014 10:25:04 +0100 Subject: RFR(XS): 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed In-Reply-To: <547CA84D.4060807@oracle.com> References: <34E8B442-C805-4217-8CC0-EF7D93D3C410@oracle.com> <547CA84D.4060807@oracle.com> Message-ID: <593C1895-537A-4C2E-AAA1-D3108EEBB509@oracle.com> Thanks for the review, Vladimir. Roland. > On Dec 1, 2014, at 6:41 PM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 12/1/14 7:11 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8048170/webrev.00/ >> >> After range check smearing, an array access may depend on multiple range checks to be valid. PhaseIdealLoop::split_if_with_blocks_post() shouldn?t replace an IF by a dominated IF for the same test for range checks otherwise it can make an array access bypass a range check that it depends on. >> >> Roland. >> From roland.westrelin at oracle.com Tue Dec 2 09:25:33 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 2 Dec 2014 10:25:33 +0100 Subject: RFC: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 In-Reply-To: <547D2E21.5020403@oracle.com> References: <8EDF29FA-40E0-4C5E-BC4C-0AF4067338EE@oracle.com> <546BD3E7.9020503@oracle.com> <538B6724-FD67-4EDF-AE49-1ED9D857FE18@oracle.com> <97D74749-A4EB-4E96-AD87-D42D250612A9@oracle.com> <546E5701.5090605@oracle.com> <3426B0AC-E3EC-403C-AFC7-DFE54B93B024@oracle.com> <547D2E21.5020403@oracle.com> Message-ID: <26815317-54C3-4FC4-8346-BBE16A5FBF8E@oracle.com> Thanks for the review, Vladimir. Roland. > On Dec 2, 2014, at 4:12 AM, Vladimir Kozlov wrote: > > This looks good. > > Thanks, > Vladimir > > On 11/26/14 1:52 AM, Roland Westrelin wrote: >> Here is a new webrev that should address the comments: >> >> http://cr.openjdk.java.net/~roland/6898462/webrev.01/ >> >> Popping all frames made the change much simpler. >> >> Roland. >> >>> On Nov 20, 2014, at 10:48 PM, John Rose wrote: >>> >>> Some more thoughts on testing this fix: >>> >>> Existing tests cover the intentions of this fix, since the fix responds to existing test crashes. This fix should upgrade their behavior to a more graceful OOME instead of a crash. >>> >>> A regression test we need for this is one which exercises the new code. If we are sure existing stress tests do this already, and if we are confident that we will recognize regressions from this code, I think that's enough to get by. >>> >>> The small reproducer unit test (TestDeoptOOM.java) should reliably exercise OOME and reallocating deopts at the same time, and nothing else; it should expect an OOME and not crash. Its value is disagnose-ability, since it exercises the new code paths. It doesn't really increase coverage. >>> >>> Does it need to be tested nightly or on multiple platforms? No, I think not. >>> >>> ? John >>> >>> On Nov 20, 2014, at 1:02 PM, Vladimir Kozlov wrote: >>> >>>> Most likely we still fail existing tests since OOM behavior is different (delayed) with EA and this fix. GCBasher test we can fix (disable EA or change catch code) and I hope Kitchensink does not care where OOM is thrown. >>>> >>>> I would say to not spend time on existing tests failures which are hard to reproduce. Fix current bug, closed is as resolved and if some tests fail after that we create a new bug and see how we can fix them. >>>> >>>> Thanks, >>>> >>>> >>>> On 11/20/14 11:57 AM, Roland Westrelin wrote: >>>>>> So, I concur that popping all the frames is the best thing to do for now. >>>>> >>>>> Thanks and thanks for the other comments. I?ll send an updated webrev. >>>>> >>>>> The other question is how much testing we think we need for this. Is it sufficient to check that it doesn?t break normal execution and that the regression test I?m adding covers all scenarios we can think of? Or do we want to reproduce failures that were reported on existing tests? The problem with doing that is that they are all hard to reproduce and it seems it would be very time consuming. Also I?m not sure what guarantees we would get out of it: from one run to another depending how much inlining a compilation does we could pop more or less frames in case of an OOM so the effect on the test case could vary. That this change doesn?t break a test case won?t mean it doesn?t break it on another run. What do you think? >>>>> >>>>> Roland. >>>>> >>> >> From roland.westrelin at oracle.com Tue Dec 2 09:26:05 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 2 Dec 2014 10:26:05 +0100 Subject: RFC: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 In-Reply-To: <97D74749-A4EB-4E96-AD87-D42D250612A9@oracle.com> References: <8EDF29FA-40E0-4C5E-BC4C-0AF4067338EE@oracle.com> <546BD3E7.9020503@oracle.com> <538B6724-FD67-4EDF-AE49-1ED9D857FE18@oracle.com> <97D74749-A4EB-4E96-AD87-D42D250612A9@oracle.com> Message-ID: <8CD3358E-2351-47D3-A870-7F8FCB9C3B71@oracle.com> > Please file a follow-up RFE to consider reserving memory for OOME exception processing. (Cold, never-used memory would be reserved to recharge a thread's TLAB in some TBD gated manner, to allow catch clauses a better chance to complete.) I'm not saying we have to do this, but we want to be ready if a use case comes up. The follow up RFE is https://bugs.openjdk.java.net/browse/JDK-8066400 Roland. From igor.ignatyev at oracle.com Tue Dec 2 09:32:19 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 02 Dec 2014 12:32:19 +0300 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <547D1BC8.7000301@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> Message-ID: <547D8723.6090102@oracle.com> Vladimir, I need Unsafe.getCompiler for DeoptimizeFramesTest, because in 'non-makeNotEntrant' case, there's no way to determine if the method was deoptimized. Thanks, Igor On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: > Why you need new Unsafe.getCompiler()? > > thanks, > Vladimir > > On 11/27/14 2:14 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >> 220 lines changed: 212 ins; 8 del; 0 mod; >> >> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >> 4 lines changed: 4 ins; 0 del; 0 mod; >> >> Hi all, >> >> please review the patch which adds >> - a new whitebox method 'deoptimizeFrames' which deoptimizes methods >> which are currently on stack >> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net which >> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 accordingly. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >> testing: jprt + new added test >> From goetz.lindenmaier at sap.com Tue Dec 2 10:50:17 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Dec 2014 10:50:17 +0000 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 In-Reply-To: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> References: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF2B637@DEWDFEMB12A.global.corp.sap> Hi Roland, The change looks good! Good you do some extra tuning by passing 'true' to maybe_cast_profiled_obj(). I ran some tests on ppc with it, and saw no problems any more. Best regards, Goetz -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Montag, 1. Dezember 2014 13:29 To: hotspot-compiler-dev at openjdk.java.net compiler Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 http://cr.openjdk.java.net/~roland/8064703/webrev.00/ If an arraycopy is used to initialize a just allocated array, when possible we skip the array initialization and let arraycopy do the initialization. If an uncommon trap is triggered after the allocation and before the arraycopy, then an uninitialized array can escape the compiled method to the interpreter. This is fixed by making the uncommon trap resume execution at the allocation rather than the arraycopy and redo the allocation (Vladimir?s suggestion). Roland. From evgeniya.stepanova at oracle.com Tue Dec 2 10:55:28 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Tue, 02 Dec 2014 14:55:28 +0400 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> Message-ID: <547D9AA0.5010103@oracle.com> Hi Christian, Thank you very much for the review I've replaced message + "JVMStartup should have exit value '%d'.%n%s", with the + "JVM process should have exit value '%d'.%n%s", and + "JVMStartup should be successful with option '%s'.", with the + "JVM should start with option '%s' without errors.", new webrev is http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ Thanks, Evgeniya Stepanova On 02.12.2014 2:49, Christian Thalinger wrote: > I didn?t verify all new messages but this looks very useful. The only > thing I could complain about is: > > + "JVMStartup should have exit value '%d'.%n%s", > > JVMStartup probably refers to some internal method. A more general > message might be better. > > In any case, looks good to me. > >> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova >> > > wrote: >> >> Hi, >> >> Could you please review fix for 8054892? >> Problem: CLI tests do not show what exactly went wrong when test >> failed. They show an error behavior is not as expected. >> Solution: Added explanation which behavior is expected and why it is so. >> >> Base class >> /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >> changed to use error string, submitted by tests classes. >> -exitErrorMessage message to be shown if exit code of JVM process is >> not as expected. >> -wrongWarningMessage message to be shown if warning messages in >> output are not as expected. >> -optionErrorString to be shown if option value is not as expected. >> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ and >> test/compiler/intrinsics/sha/cli folders. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >> >> Thanks, >> Evgeniya Stepanova >> > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Tue Dec 2 12:45:11 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 2 Dec 2014 13:45:11 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <547CB882.8040500@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> Message-ID: <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> > The propose fix is correct. Comments are good. > > (nb_checks == 0) check and rc0 could be moved before (index1) to avoid duplication on both paths. > > Add tests with i-c negative constants (and combinations -c and +c) when i starts with > c value. Thanks for the review. Here is a new webrev: http://cr.openjdk.java.net/~roland/8066103/webrev.01/ Roland. > > Thanks, > Vladimir > > On 12/1/14 6:46 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8066103/webrev.00/ >> >> Given a list of range checks of the form i + constant > >> Roland. >> From filipp.zhinkin at oracle.com Tue Dec 2 14:20:57 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 02 Dec 2014 18:20:57 +0400 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <547D9AA0.5010103@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> Message-ID: <547DCAC9.5000105@oracle.com> Evgeniya, thank you for taking care of it! Sorry that I'm asking you about that only now, but could use the same order of arguments in verifyJVMStartup and verifySameJVMStartup? public static void verifyJVMStartup(String expectedMessages[], String unexpectedMessages[], ExitCode exitCode, String exitErrorMessage, String wrongWarningMessage, boolean addTestVMOptions, String... options) public static void verifySameJVMStartup(String expectedMessages[], String unexpectedMessages[], String exitErrorMessage, String wrongWarningMessage, ExitCode exitCode, String... options) Could you place exitCode after *Message in both methods? Otherwise the change looks good. Thanks, Filipp. On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: > Hi Christian, > > Thank you very much for the review > > I've replaced message > + "JVMStartup should have exit value '%d'.%n%s", > with the > + "JVM process should have exit value '%d'.%n%s", > and > + "JVMStartup should be successful with option '%s'.", > with the > + "JVM should start with option '%s' without errors.", > > new webrev is > http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ > > Thanks, > Evgeniya Stepanova > > On 02.12.2014 2:49, Christian Thalinger wrote: >> I didn?t verify all new messages but this looks very useful. The only thing >> I could complain about is: >> >> + "JVMStartup should have exit value '%d'.%n%s", >> >> JVMStartup probably refers to some internal method. A more general message >> might be better. >> >> In any case, looks good to me. >> >>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova >>> > wrote: >>> >>> Hi, >>> >>> Could you please review fix for 8054892? >>> Problem: CLI tests do not show what exactly went wrong when test failed. >>> They show an error behavior is not as expected. >>> Solution: Added explanation which behavior is expected and why it is so. >>> >>> Base class >>> /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >>> changed to use error string, submitted by tests classes. >>> -exitErrorMessage message to be shown if exit code of JVM process is not >>> as expected. >>> -wrongWarningMessage message to be shown if warning messages in output are >>> not as expected. >>> -optionErrorString to be shown if option value is not as expected. >>> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ and >>> test/compiler/intrinsics/sha/cli folders. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>> >>> Thanks, >>> Evgeniya Stepanova >>> >> > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Tue Dec 2 14:59:57 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 2 Dec 2014 15:59:57 +0100 Subject: RFR(S): 8064703: crash running specjvm98's javac following 8060252 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF2B637@DEWDFEMB12A.global.corp.sap> References: <3D4529D1-5C10-49EE-A815-6C3EA92F6A5B@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF2B637@DEWDFEMB12A.global.corp.sap> Message-ID: > The change looks good! > Good you do some extra tuning by passing 'true' to maybe_cast_profiled_obj(). > > I ran some tests on ppc with it, and saw no problems any more. Thanks for reviewing the change and trying the fix, Goetz! Roland. From evgeniya.stepanova at oracle.com Tue Dec 2 15:10:03 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Tue, 02 Dec 2014 19:10:03 +0400 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <547DCAC9.5000105@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> <547DCAC9.5000105@oracle.com> Message-ID: <547DD64B.7070704@oracle.com> Hi Filipp, Thanks for the review! No problems, only changes in test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java were needed to do that. new webrev http://cr.openjdk.java.net/~eistepan/8054892/webrev.02/ On 02.12.2014 18:20, Filipp Zhinkin wrote: > Evgeniya, > > thank you for taking care of it! > > Sorry that I'm asking you about that only now, > but could use the same order of arguments in > verifyJVMStartup and verifySameJVMStartup? > > public static void verifyJVMStartup(String expectedMessages[], > String unexpectedMessages[], ExitCode exitCode, > String exitErrorMessage, String wrongWarningMessage, > boolean addTestVMOptions, String... options) > > public static void verifySameJVMStartup(String expectedMessages[], > String unexpectedMessages[], String exitErrorMessage, > String wrongWarningMessage, ExitCode exitCode, String... > options) > > Could you place exitCode after *Message in both methods? > > Otherwise the change looks good. > > Thanks, > Filipp. > > On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: >> Hi Christian, >> >> Thank you very much for the review >> >> I've replaced message >> + "JVMStartup should have exit value '%d'.%n%s", >> with the >> + "JVM process should have exit value '%d'.%n%s", >> and >> + "JVMStartup should be successful with option '%s'.", >> with the >> + "JVM should start with option '%s' without errors.", >> >> new webrev is >> http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ >> >> Thanks, >> Evgeniya Stepanova >> >> On 02.12.2014 2:49, Christian Thalinger wrote: >>> I didn?t verify all new messages but this looks very useful. The >>> only thing I could complain about is: >>> >>> + "JVMStartup should have exit value '%d'.%n%s", >>> >>> JVMStartup probably refers to some internal method. A more general >>> message might be better. >>> >>> In any case, looks good to me. >>> >>>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> Could you please review fix for 8054892? >>>> Problem: CLI tests do not show what exactly went wrong when test >>>> failed. They show an error behavior is not as expected. >>>> Solution: Added explanation which behavior is expected and why it >>>> is so. >>>> >>>> Base class >>>> /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >>>> changed to use error string, submitted by tests classes. >>>> -exitErrorMessage message to be shown if exit code of JVM process >>>> is not as expected. >>>> -wrongWarningMessage message to be shown if warning messages in >>>> output are not as expected. >>>> -optionErrorString to be shown if option value is not as expected. >>>> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ >>>> and test/compiler/intrinsics/sha/cli folders. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> >>> >> >> -- >> /Evgeniya Stepanova/ > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Tue Dec 2 15:05:59 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 02 Dec 2014 19:05:59 +0400 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <547DD64B.7070704@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> <547DCAC9.5000105@oracle.com> <547DD64B.7070704@oracle.com> Message-ID: <547DD557.60509@oracle.com> Evgeniya, thanks! The change looks good (not a Reviewer). Regards, Filipp. On 12/02/2014 07:10 PM, Evgeniya Stepanova wrote: > Hi Filipp, > Thanks for the review! > No problems, only changes in > test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java > were needed to do that. > new webrev > http://cr.openjdk.java.net/~eistepan/8054892/webrev.02/ > > On 02.12.2014 18:20, Filipp Zhinkin wrote: >> Evgeniya, >> >> thank you for taking care of it! >> >> Sorry that I'm asking you about that only now, >> but could use the same order of arguments in >> verifyJVMStartup and verifySameJVMStartup? >> >> public static void verifyJVMStartup(String expectedMessages[], >> String unexpectedMessages[], ExitCode exitCode, >> String exitErrorMessage, String wrongWarningMessage, >> boolean addTestVMOptions, String... options) >> >> public static void verifySameJVMStartup(String expectedMessages[], >> String unexpectedMessages[], String exitErrorMessage, >> String wrongWarningMessage, ExitCode exitCode, String... options) >> >> Could you place exitCode after *Message in both methods? >> >> Otherwise the change looks good. >> >> Thanks, >> Filipp. >> >> On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: >>> Hi Christian, >>> >>> Thank you very much for the review >>> >>> I've replaced message >>> + "JVMStartup should have exit value '%d'.%n%s", >>> with the >>> + "JVM process should have exit value '%d'.%n%s", >>> and >>> + "JVMStartup should be successful with option '%s'.", >>> with the >>> + "JVM should start with option '%s' without errors.", >>> >>> new webrev is >>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ >>> >>> Thanks, >>> Evgeniya Stepanova >>> >>> On 02.12.2014 2:49, Christian Thalinger wrote: >>>> I didn?t verify all new messages but this looks very useful. The only >>>> thing I could complain about is: >>>> >>>> + "JVMStartup should have exit value '%d'.%n%s", >>>> >>>> JVMStartup probably refers to some internal method. A more general message >>>> might be better. >>>> >>>> In any case, looks good to me. >>>> >>>>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova >>>>> > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could you please review fix for 8054892? >>>>> Problem: CLI tests do not show what exactly went wrong when test failed. >>>>> They show an error behavior is not as expected. >>>>> Solution: Added explanation which behavior is expected and why it is so. >>>>> >>>>> Base class >>>>> /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >>>>> changed to use error string, submitted by tests classes. >>>>> -exitErrorMessage message to be shown if exit code of JVM process is not >>>>> as expected. >>>>> -wrongWarningMessage message to be shown if warning messages in output >>>>> are not as expected. >>>>> -optionErrorString to be shown if option value is not as expected. >>>>> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ and >>>>> test/compiler/intrinsics/sha/cli folders. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>>>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> >>>> >>> >>> -- >>> /Evgeniya Stepanova/ >> > > -- > /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Dec 2 17:45:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Dec 2014 09:45:40 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> Message-ID: <547DFAC4.101@oracle.com> Looks good. Thanks, Vladimir On 12/2/14 4:45 AM, Roland Westrelin wrote: >> The propose fix is correct. Comments are good. >> >> (nb_checks == 0) check and rc0 could be moved before (index1) to avoid duplication on both paths. >> >> Add tests with i-c negative constants (and combinations -c and +c) when i starts with > c value. > > Thanks for the review. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8066103/webrev.01/ > > Roland. > >> >> Thanks, >> Vladimir >> >> On 12/1/14 6:46 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8066103/webrev.00/ >>> >>> Given a list of range checks of the form i + constant >> >>> Roland. >>> > From vladimir.kozlov at oracle.com Tue Dec 2 19:36:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Dec 2014 11:36:57 -0800 Subject: [9] RFR (XS) 8066199: C2 escape analysis prevents VM from exiting quickly Message-ID: <547E14D9.3070302@oracle.com> http://cr.openjdk.java.net/~kvn/8066199/webrev/ https://bugs.openjdk.java.net/browse/JDK-8066199 Check for safepoint and block during EA Connection graph construction. Aleksey Shipilev verify the fix. Thanks, Vladimir From vladimir.x.ivanov at oracle.com Tue Dec 2 18:39:52 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 02 Dec 2014 22:39:52 +0400 Subject: [9] RFR (XS) 8066199: C2 escape analysis prevents VM from exiting quickly In-Reply-To: <547E14D9.3070302@oracle.com> References: <547E14D9.3070302@oracle.com> Message-ID: <547E0778.4090909@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/2/14, 11:36 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8066199/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8066199 > > Check for safepoint and block during EA Connection graph construction. > > Aleksey Shipilev verify the fix. > > Thanks, > Vladimir From roland.westrelin at oracle.com Tue Dec 2 19:42:35 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 2 Dec 2014 20:42:35 +0100 Subject: [9] RFR (XS) 8066199: C2 escape analysis prevents VM from exiting quickly In-Reply-To: <547E14D9.3070302@oracle.com> References: <547E14D9.3070302@oracle.com> Message-ID: Looks good to me. Roland. > On Dec 2, 2014, at 8:36 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8066199/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8066199 > > Check for safepoint and block during EA Connection graph construction. > > Aleksey Shipilev verify the fix. > > Thanks, > Vladimir From aleksey.shipilev at oracle.com Tue Dec 2 19:43:26 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 02 Dec 2014 22:43:26 +0300 Subject: [9] RFR (XS) 8066199: C2 escape analysis prevents VM from exiting quickly In-Reply-To: <547E14D9.3070302@oracle.com> References: <547E14D9.3070302@oracle.com> Message-ID: <547E165E.9000607@oracle.com> On 02.12.2014 22:36, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8066199/webrev/ Looks good. > https://bugs.openjdk.java.net/browse/JDK-8066199 > > Check for safepoint and block during EA Connection graph construction. > > Aleksey Shipilev verify the fix. Yes, the fix is verified, see the comments in the bug. -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From vladimir.kozlov at oracle.com Tue Dec 2 19:58:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Dec 2014 11:58:41 -0800 Subject: [9] RFR (XS) 8066199: C2 escape analysis prevents VM from exiting quickly In-Reply-To: References: <547E14D9.3070302@oracle.com> Message-ID: <547E19F1.6040607@oracle.com> Thank you, Roland Vladimir On 12/2/14 11:42 AM, Roland Westrelin wrote: > Looks good to me. > > Roland. > >> On Dec 2, 2014, at 8:36 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8066199/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8066199 >> >> Check for safepoint and block during EA Connection graph construction. >> >> Aleksey Shipilev verify the fix. >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Dec 2 20:01:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Dec 2014 12:01:32 -0800 Subject: [9] RFR (XS) 8066199: C2 escape analysis prevents VM from exiting quickly In-Reply-To: <547E165E.9000607@oracle.com> References: <547E14D9.3070302@oracle.com> <547E165E.9000607@oracle.com> Message-ID: <547E1A9C.2050105@oracle.com> Thank you, Aleksey Vladimir On 12/2/14 11:43 AM, Aleksey Shipilev wrote: > On 02.12.2014 22:36, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8066199/webrev/ > > Looks good. > >> https://bugs.openjdk.java.net/browse/JDK-8066199 >> >> Check for safepoint and block during EA Connection graph construction. >> >> Aleksey Shipilev verify the fix. > > Yes, the fix is verified, see the comments in the bug. > > -Aleksey. > > From vladimir.kozlov at oracle.com Tue Dec 2 20:22:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Dec 2014 12:22:30 -0800 Subject: [9] RFR (XS) 8066199: C2 escape analysis prevents VM from exiting quickly In-Reply-To: <547E0778.4090909@oracle.com> References: <547E14D9.3070302@oracle.com> <547E0778.4090909@oracle.com> Message-ID: <547E1F86.5070405@oracle.com> Thank you, Vladimir I Vladimir K On 12/2/14 10:39 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 12/2/14, 11:36 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8066199/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8066199 >> >> Check for safepoint and block during EA Connection graph construction. >> >> Aleksey Shipilev verify the fix. >> >> Thanks, >> Vladimir From vladimir.kozlov at oracle.com Tue Dec 2 21:54:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 02 Dec 2014 13:54:50 -0800 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <547D8723.6090102@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> Message-ID: <547E352A.5040806@oracle.com> On 12/2/14 1:32 AM, Igor Ignatyev wrote: > Vladimir, > > I need Unsafe.getCompiler for DeoptimizeFramesTest, because in > 'non-makeNotEntrant' case, there's no way to determine if the method was > deoptimized. I don't understand how you check that in the test. If you only want to check if method was deoptimized you can check MethodData::decompile_count(). I don't like extending Unsafe API for just this test. Thanks, Vladimir > > Thanks, > Igor > > On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >> Why you need new Unsafe.getCompiler()? >> >> thanks, >> Vladimir >> >> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>> 220 lines changed: 212 ins; 8 del; 0 mod; >>> >>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>> 4 lines changed: 4 ins; 0 del; 0 mod; >>> >>> Hi all, >>> >>> please review the patch which adds >>> - a new whitebox method 'deoptimizeFrames' which deoptimizes methods >>> which are currently on stack >>> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net which >>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 accordingly. >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>> testing: jprt + new added test >>> From christian.thalinger at oracle.com Tue Dec 2 22:28:58 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Dec 2014 14:28:58 -0800 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <547DD64B.7070704@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> <547DCAC9.5000105@oracle.com> <547DD64B.7070704@oracle.com> Message-ID: Looks good. > On Dec 2, 2014, at 7:10 AM, Evgeniya Stepanova wrote: > > Hi Filipp, > Thanks for the review! > No problems, only changes in test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java were needed to do that. > new webrev > http://cr.openjdk.java.net/~eistepan/8054892/webrev.02/ > > On 02.12.2014 18:20, Filipp Zhinkin wrote: >> Evgeniya, >> >> thank you for taking care of it! >> >> Sorry that I'm asking you about that only now, >> but could use the same order of arguments in >> verifyJVMStartup and verifySameJVMStartup? >> >> public static void verifyJVMStartup(String expectedMessages[], >> String unexpectedMessages[], ExitCode exitCode, >> String exitErrorMessage, String wrongWarningMessage, >> boolean addTestVMOptions, String... options) >> >> public static void verifySameJVMStartup(String expectedMessages[], >> String unexpectedMessages[], String exitErrorMessage, >> String wrongWarningMessage, ExitCode exitCode, String... options) >> >> Could you place exitCode after *Message in both methods? >> >> Otherwise the change looks good. >> >> Thanks, >> Filipp. >> >> On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: >>> Hi Christian, >>> >>> Thank you very much for the review >>> >>> I've replaced message >>> + "JVMStartup should have exit value '%d'.%n%s", >>> with the >>> + "JVM process should have exit value '%d'.%n%s", >>> and >>> + "JVMStartup should be successful with option '%s'.", >>> with the >>> + "JVM should start with option '%s' without errors.", >>> >>> new webrev is >>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ >>> >>> Thanks, >>> Evgeniya Stepanova >>> >>> On 02.12.2014 2:49, Christian Thalinger wrote: >>>> I didn?t verify all new messages but this looks very useful. The only thing I could complain about is: >>>> >>>> + "JVMStartup should have exit value '%d'.%n%s", >>>> >>>> JVMStartup probably refers to some internal method. A more general message might be better. >>>> >>>> In any case, looks good to me. >>>> >>>>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could you please review fix for 8054892? >>>>> Problem: CLI tests do not show what exactly went wrong when test failed. They show an error behavior is not as expected. >>>>> Solution: Added explanation which behavior is expected and why it is so. >>>>> >>>>> Base class /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java changed to use error string, submitted by tests classes. >>>>> -exitErrorMessage message to be shown if exit code of JVM process is not as expected. >>>>> -wrongWarningMessage message to be shown if warning messages in output are not as expected. >>>>> -optionErrorString to be shown if option value is not as expected. >>>>> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ and test/compiler/intrinsics/sha/cli folders. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>>>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> >>>> >>> >>> -- >>> Evgeniya Stepanova >> > > -- > Evgeniya Stepanova -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Dec 2 23:54:36 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Dec 2014 15:54:36 -0800 Subject: RFR(XS): 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed In-Reply-To: <34E8B442-C805-4217-8CC0-EF7D93D3C410@oracle.com> References: <34E8B442-C805-4217-8CC0-EF7D93D3C410@oracle.com> Message-ID: Reviewed. I wish we had a less ambiguous way to mark the overloaded 'If' nodes. I suggest adding a comment linking your change to IfNode and the concept of smearing: + // If this is a range check (IfNode::is_range_check), do not reorder because + // Compile::allow_range_check_smearing might have changed the check. return; // Let IGVN transformation change control dependence. I suggest adding comments to the test case so that it can be read without referring to the bug report. Perhaps (although I'm not certain my comments are correct!): 38 if (array[i] < 0) { // range check (i+0) dominates equivalent check below 49.9 // IfNode::Ideal will rewrite some range checks if Compile::allow_range_check_smearing 50 if (array[i-1] == 9) { // range check (i-1) changed to off_lo = (i-3) 51 int res = array[i-3]; // range check (i-3) changed to off_hi = (i+0) 51.1 // the previous access might be hoisted by PhaseIdealLoop::split_if_with_blocks_post 51.2 // because it appears to have the same guard, but it also depends on the previous guard 52 res += array[i]; // removed redundant range check 53 res += array[i-2]; // removed redundant range check 54 return res; 55 } > On Dec 1, 2014, at 7:11 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8048170/webrev.00/ > > After range check smearing, an array access may depend on multiple range checks to be valid. PhaseIdealLoop::split_if_with_blocks_post() shouldn?t replace an IF by a dominated IF for the same test for range checks otherwise it can make an array access bypass a range check that it depends on. > > Roland. From john.r.rose at oracle.com Wed Dec 3 00:20:08 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Dec 2014 16:20:08 -0800 Subject: RFC: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 In-Reply-To: <8CD3358E-2351-47D3-A870-7F8FCB9C3B71@oracle.com> References: <8EDF29FA-40E0-4C5E-BC4C-0AF4067338EE@oracle.com> <546BD3E7.9020503@oracle.com> <538B6724-FD67-4EDF-AE49-1ED9D857FE18@oracle.com> <97D74749-A4EB-4E96-AD87-D42D250612A9@oracle.com> <8CD3358E-2351-47D3-A870-7F8FCB9C3B71@oracle.com> Message-ID: Thanks. Nice work! Using obj==null as a sentinel for failed allocation is good. Then the flag becomes mostly an extra assertion predicate, which is much safer than having the extra state variable. I have only cosmetic comments at this point. I suggest moving the line "+ if (realloc_failures) {" outside of the call to 'handle_failed_reallocs', and removing the parameter. Also, suggest s/handle_failed_reallocs/pop_frames_failed_realloc/, to more specifically tie it to the frame-popping logic (Thread::frames_to_pop_failed_realloc). (Maybe also s/frames_to_pop_failed_realloc/pop_frames_failed_realloc/, to strengthen the correspondence; not sure about that one.) ? John > On Dec 2, 2014, at 1:26 AM, Roland Westrelin wrote: > >> Please file a follow-up RFE to consider reserving memory for OOME exception processing. (Cold, never-used memory would be reserved to recharge a thread's TLAB in some TBD gated manner, to allow catch clauses a better chance to complete.) I'm not saying we have to do this, but we want to be ready if a use case comes up. > > The follow up RFE is https://bugs.openjdk.java.net/browse/JDK-8066400 > > Roland. From igor.veresov at oracle.com Wed Dec 3 04:51:48 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 2 Dec 2014 20:51:48 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> Message-ID: Seems good. You don?t have to prefix every declaration of RangeCheck variable with the ?struct? though. igor > On Dec 2, 2014, at 4:45 AM, Roland Westrelin wrote: > >> The propose fix is correct. Comments are good. >> >> (nb_checks == 0) check and rc0 could be moved before (index1) to avoid duplication on both paths. >> >> Add tests with i-c negative constants (and combinations -c and +c) when i starts with > c value. > > Thanks for the review. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8066103/webrev.01/ > > Roland. > >> >> Thanks, >> Vladimir >> >> On 12/1/14 6:46 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8066103/webrev.00/ >>> >>> Given a list of range checks of the form i + constant >> >>> Roland. >>> > From john.r.rose at oracle.com Wed Dec 3 05:14:12 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 2 Dec 2014 21:14:12 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> Message-ID: <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> Reviewed. The test cases are very good. One suggestion: Use a driver routine to warm up, execute, and verify all the tests. As written, it is a little hard to verify by hand that all the bits are being done correctly. (I sent you an example by skype to show you what I mean.) Do the test cases exercise all the new paths in the code? It seems they are intended to, and I wonder if you verified that (with temporary print statements or something similar). Update comment: /Scan for the top 2 checks and collect range of offsets/s/top 2 checks/top checks/ Also: /widening a check can make us speculative enter/s/speculative/speculatively/ Suggest "const int NRC = 3" instead the approx. 7 occurrences of the constant "3". ref: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-NamedCons (But I see that the code doesn't work for any other value of "3". :-) ) Isn't this statement always a no-op? + adjust_check(rc0.ctl, range1, index1, flip1, off_lo, igvn); I see that it reproduces the previous behavior, so it's OK. As far as I can see, the main point of this path in the code is that the IfNode can idealize to a dominating duplicate test, just as if it were not a special range check. Is that true? If that's true, perhaps the search loop should just record (outside of the prev_doms array) the shallowest exact match for the current node. Then, if the range check smearing logic fails to work, the Ideal method can simply return the exact match. In any case, the associated comment "Valid only if there's a single dominating range check" makes me nervous, since it's possible that there are other dominating range checks which we simply failed to find (due to the search cutoff of 999). If there is a real change to make (if it's not a no-op), we should disable the change if the loop hit 999. The case of nb_checks>=2 and index1!=NULL is where all the interesting new logic is. It is extremely well commented. Because the logic makes changes to nodes under an unchanged dominating test (rc0), the logic here is immune to whether the search loop hit 999. ? John > On Dec 2, 2014, at 4:45 AM, Roland Westrelin wrote: > >> The propose fix is correct. Comments are good. >> >> (nb_checks == 0) check and rc0 could be moved before (index1) to avoid duplication on both paths. >> >> Add tests with i-c negative constants (and combinations -c and +c) when i starts with > c value. > > Thanks for the review. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8066103/webrev.01/ > > Roland. > >> >> Thanks, >> Vladimir >> >> On 12/1/14 6:46 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8066103/webrev.00/ >>> >>> Given a list of range checks of the form i + constant >> >>> Roland. >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Wed Dec 3 09:31:37 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 3 Dec 2014 10:31:37 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> Message-ID: <26DDF2E1-B492-4061-9D78-EB56E208DA98@oracle.com> On Dec 3, 2014, at 6:14 AM, John Rose wrote: > Reviewed. > > The test cases are very good. I agree, as an outsider looking in they are really valuable and useful to reverse engineer the often mysterious workings of the compiler. > One suggestion: Use a driver routine to warm up, execute, and verify all the tests. +1 the repetition makes it harder to read/maintain. I am not sure what John suggests but since all methods can support the same signature you could create a functional interface for the signature (int[], int, boolean)int and sprinkle some method refs around to avoid the boiler plate of inner classes for each test (assuming indy does not get in the way of the compiler doing what is to be tested). e.g.: test(TestRangeCheckSmearing::m1); test(TestRangeCheckSmearing::m2); etc. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From evgeniya.stepanova at oracle.com Wed Dec 3 10:16:03 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Wed, 03 Dec 2014 14:16:03 +0400 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> <547DCAC9.5000105@oracle.com> <547DD64B.7070704@oracle.com> Message-ID: <547EE2E3.90000@oracle.com> Christian, Thank you for the review! On 03.12.2014 2:28, Christian Thalinger wrote: > Looks good. > >> On Dec 2, 2014, at 7:10 AM, Evgeniya Stepanova >> > > wrote: >> >> Hi Filipp, >> Thanks for the review! >> No problems, only changes in >> test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >> were needed to do that. >> new webrev >> http://cr.openjdk.java.net/~eistepan/8054892/webrev.02/ >> >> On 02.12.2014 18:20, Filipp Zhinkin wrote: >>> Evgeniya, >>> >>> thank you for taking care of it! >>> >>> Sorry that I'm asking you about that only now, >>> but could use the same order of arguments in >>> verifyJVMStartup and verifySameJVMStartup? >>> >>> public static void verifyJVMStartup(String expectedMessages[], >>> String unexpectedMessages[], ExitCode exitCode, >>> String exitErrorMessage, String wrongWarningMessage, >>> boolean addTestVMOptions, String... options) >>> >>> public static void verifySameJVMStartup(String expectedMessages[], >>> String unexpectedMessages[], String exitErrorMessage, >>> String wrongWarningMessage, ExitCode exitCode, String... >>> options) >>> >>> Could you place exitCode after *Message in both methods? >>> >>> Otherwise the change looks good. >>> >>> Thanks, >>> Filipp. >>> >>> On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: >>>> Hi Christian, >>>> >>>> Thank you very much for the review >>>> >>>> I've replaced message >>>> + "JVMStartup should have exit value '%d'.%n%s", >>>> with the >>>> + "JVM process should have exit value '%d'.%n%s", >>>> and >>>> + "JVMStartup should be successful with option '%s'.", >>>> with the >>>> + "JVM should start with option '%s' without errors.", >>>> >>>> new webrev is >>>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ >>>> >>>> Thanks, >>>> Evgeniya Stepanova >>>> >>>> On 02.12.2014 2:49, Christian Thalinger wrote: >>>>> I didn?t verify all new messages but this looks very useful. The >>>>> only thing I could complain about is: >>>>> >>>>> + "JVMStartup should have exit value '%d'.%n%s", >>>>> >>>>> JVMStartup probably refers to some internal method. A more >>>>> general message might be better. >>>>> >>>>> In any case, looks good to me. >>>>> >>>>>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could you please review fix for 8054892? >>>>>> Problem: CLI tests do not show what exactly went wrong when test >>>>>> failed. They show an error behavior is not as expected. >>>>>> Solution: Added explanation which behavior is expected and why >>>>>> it is so. >>>>>> >>>>>> Base class >>>>>> /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >>>>>> changed to use error string, submitted by tests classes. >>>>>> -exitErrorMessage message to be shown if exit code of JVM >>>>>> process is not as expected. >>>>>> -wrongWarningMessage message to be shown if warning messages in >>>>>> output are not as expected. >>>>>> -optionErrorString to be shown if option value is not as expected. >>>>>> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ >>>>>> and test/compiler/intrinsics/sha/cli folders. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>>>>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Evgeniya Stepanova >>>>>> >>>>> >>>> >>>> -- >>>> /Evgeniya Stepanova/ >>> >> >> -- >> /Evgeniya Stepanova/ > -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Wed Dec 3 13:44:37 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 03 Dec 2014 14:44:37 +0100 Subject: [9] RFR(S): 8066448: SmallCodeCacheStartup.java exits with exit code 1 Message-ID: <547F13C5.4010700@oracle.com> Hi, please review the following small patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8066448 Webrev: http://cr.openjdk.java.net/~thartmann/8066448/webrev.00/ Problem: JDK-8064696 changed the test to always expect an exit value of 0. However, the test is run with a very small code cache size to check for compiler startup failures and may fail during initialization with a VirtualMachineError because we are "Out of space in CodeCache for method handle adapters". Solution: I changed the test to check for a VirtualMachineError in case VM initialization failed. I also fixed the "Out of space in CodeCache for adapters" message to be consistent with the "Out of space in CodeCache for method handle adapters" message (upper-case "O"). Testing: - Failing test on JPRT Thanks, Tobias From vladimir.kozlov at oracle.com Wed Dec 3 16:46:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Dec 2014 08:46:30 -0800 Subject: [9] RFR(S): 8066448: SmallCodeCacheStartup.java exits with exit code 1 In-Reply-To: <547F13C5.4010700@oracle.com> References: <547F13C5.4010700@oracle.com> Message-ID: <547F3E66.5070701@oracle.com> Good. Thanks, Vladimir On 12/3/14 5:44 AM, Tobias Hartmann wrote: > Hi, > > please review the following small patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066448 > Webrev: http://cr.openjdk.java.net/~thartmann/8066448/webrev.00/ > > Problem: > JDK-8064696 changed the test to always expect an exit value of 0. However, the > test is run with a very small code cache size to check for compiler startup > failures and may fail during initialization with a VirtualMachineError because > we are "Out of space in CodeCache for method handle adapters". > > Solution: > I changed the test to check for a VirtualMachineError in case VM initialization > failed. I also fixed the "Out of space in CodeCache for adapters" message to be > consistent with the "Out of space in CodeCache for method handle adapters" > message (upper-case "O"). > > Testing: > - Failing test on JPRT > > Thanks, > Tobias > From roland.westrelin at oracle.com Wed Dec 3 19:27:14 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Dec 2014 20:27:14 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> Message-ID: > Seems good. You don?t have to prefix every declaration of RangeCheck variable with the ?struct? though. Thanks for the review, Igor. I will remove the ?structs?. Roland. > > igor > >> On Dec 2, 2014, at 4:45 AM, Roland Westrelin wrote: >> >>> The propose fix is correct. Comments are good. >>> >>> (nb_checks == 0) check and rc0 could be moved before (index1) to avoid duplication on both paths. >>> >>> Add tests with i-c negative constants (and combinations -c and +c) when i starts with > c value. >> >> Thanks for the review. Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8066103/webrev.01/ >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 12/1/14 6:46 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8066103/webrev.00/ >>>> >>>> Given a list of range checks of the form i + constant >>> >>>> Roland. >>>> >> > From roland.westrelin at oracle.com Wed Dec 3 21:13:57 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Dec 2014 22:13:57 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> Message-ID: <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> > Reviewed. Thanks for the review. New webrev: http://cr.openjdk.java.net/~roland/8066103/webrev.02/ > The test cases are very good. One suggestion: Use a driver routine to warm up, execute, and verify all the tests. As written, it is a little hard to verify by hand that all the bits are being done correctly. (I sent you an example by skype to show you what I mean.) Thanks for reworking the tests. I took your example and used the whitebox API where you suggested to. > Do the test cases exercise all the new paths in the code? It seems they are intended to, and I wonder if you verified that (with temporary print statements or something similar). I modified the range check smearing code for every (or at least most) subtests and checked the test would fail. For instance, if first constant is the min, I changed the range smearing code to adjust the first range check with the max et check that the corresponding test case fails etc. > Update comment: > /Scan for the top 2 checks and collect range of offsets/s/top 2 checks/top checks/ done. > Also: > /widening a check can make us speculative enter/s/speculative/speculatively/ done. > Suggest "const int NRC = 3" instead the approx. 7 occurrences of the constant "3". > ref: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-NamedCons > (But I see that the code doesn't work for any other value of "3". :-) ) done. > Isn't this statement always a no-op? > + adjust_check(rc0.ctl, range1, index1, flip1, off_lo, igvn); > I see that it reproduces the previous behavior, so it's OK. As far as I can see, the main point of this path in the code is that the IfNode can idealize to a dominating duplicate test, just as if it were not a special range check. Is that true? It?s true it?s a no-op so I removed it. > If that's true, perhaps the search loop should just record (outside of the prev_doms array) the shallowest exact match for the current node. Then, if the range check smearing logic fails to work, the Ideal method can simply return the exact match. > > In any case, the associated comment "Valid only if there's a single dominating range check" makes me nervous, since it's possible that there are other dominating range checks which we simply failed to find (due to the search cutoff of 999). If there is a real change to make (if it's not a no-op), we should disable the change if the loop hit 999. The comment must be misleading. I reworded it. What we want is that there?s no other range check between the range check that we?re calling Ideal on and the top range check that is identical. Otherwise something like 8048170 (that you reviewed yesterday as well) could happen. if i The case of nb_checks>=2 and index1!=NULL is where all the interesting new logic is. It is extremely well commented. Because the logic makes changes to nodes under an unchanged dominating test (rc0), the logic here is immune to whether the search loop hit 999. > > ? John > >> On Dec 2, 2014, at 4:45 AM, Roland Westrelin wrote: >> >>> The propose fix is correct. Comments are good. >>> >>> (nb_checks == 0) check and rc0 could be moved before (index1) to avoid duplication on both paths. >>> >>> Add tests with i-c negative constants (and combinations -c and +c) when i starts with > c value. >> >> Thanks for the review. Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8066103/webrev.01/ >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 12/1/14 6:46 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8066103/webrev.00/ >>>> >>>> Given a list of range checks of the form i + constant >>> >>>> Roland. >>>> >> > From roland.westrelin at oracle.com Wed Dec 3 21:15:14 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Dec 2014 22:15:14 +0100 Subject: RFR(XS): 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed In-Reply-To: References: <34E8B442-C805-4217-8CC0-EF7D93D3C410@oracle.com> Message-ID: <3940727A-3C0E-4981-8194-3805F9BB46CA@oracle.com> > Reviewed. Thanks for the review. > > I wish we had a less ambiguous way to mark the overloaded 'If' nodes. > > I suggest adding a comment linking your change to IfNode and the concept of smearing: > > + // If this is a range check (IfNode::is_range_check), do not reorder because > + // Compile::allow_range_check_smearing might have changed the check. > return; // Let IGVN transformation change control dependence. I?ll do that before I push the change. > I suggest adding comments to the test case so that it can be read without referring to the bug report. > > Perhaps (although I'm not certain my comments are correct!): > > 38 if (array[i] < 0) { // range check (i+0) dominates equivalent check below > 49.9 // IfNode::Ideal will rewrite some range checks if Compile::allow_range_check_smearing > 50 if (array[i-1] == 9) { // range check (i-1) changed to off_lo = (i-3) > 51 int res = array[i-3]; // range check (i-3) changed to off_hi = (i+0) > 51.1 // the previous access might be hoisted by PhaseIdealLoop::split_if_with_blocks_post > 51.2 // because it appears to have the same guard, but it also depends on the previous guard > 52 res += array[i]; // removed redundant range check > 53 res += array[i-2]; // removed redundant range check > 54 return res; > 55 } I?ll add the comments in the test case as well. Roland. > > > >> On Dec 1, 2014, at 7:11 AM, Roland Westrelin wrote: >> >> http://cr.openjdk.java.net/~roland/8048170/webrev.00/ >> >> After range check smearing, an array access may depend on multiple range checks to be valid. PhaseIdealLoop::split_if_with_blocks_post() shouldn?t replace an IF by a dominated IF for the same test for range checks otherwise it can make an array access bypass a range check that it depends on. >> >> Roland. > From roland.westrelin at oracle.com Wed Dec 3 21:17:20 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 3 Dec 2014 22:17:20 +0100 Subject: RFC: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 In-Reply-To: References: <8EDF29FA-40E0-4C5E-BC4C-0AF4067338EE@oracle.com> <546BD3E7.9020503@oracle.com> <538B6724-FD67-4EDF-AE49-1ED9D857FE18@oracle.com> <97D74749-A4EB-4E96-AD87-D42D250612A9@oracle.com> <8CD3358E-2351-47D3-A870-7F8FCB9C3B71@oracle.com> Message-ID: > Thanks. Nice work! Thanks for taking another look. > Using obj==null as a sentinel for failed allocation is good. Then the flag becomes mostly an extra assertion predicate, which is much safer than having the extra state variable. > > I have only cosmetic comments at this point. > > I suggest moving the line "+ if (realloc_failures) {" outside of the call to 'handle_failed_reallocs', and removing the parameter. Also, suggest s/handle_failed_reallocs/pop_frames_failed_realloc/, to more specifically tie it to the frame-popping logic (Thread::frames_to_pop_failed_realloc). > > (Maybe also s/frames_to_pop_failed_realloc/pop_frames_failed_realloc/, to strengthen the correspondence; not sure about that one.) I?ll make those changes. I assume there?s no need for an updated webrev? Roland. > > ? John > > >> On Dec 2, 2014, at 1:26 AM, Roland Westrelin wrote: >> >>> Please file a follow-up RFE to consider reserving memory for OOME exception processing. (Cold, never-used memory would be reserved to recharge a thread's TLAB in some TBD gated manner, to allow catch clauses a better chance to complete.) I'm not saying we have to do this, but we want to be ready if a use case comes up. >> >> The follow up RFE is https://bugs.openjdk.java.net/browse/JDK-8066400 >> >> Roland. > From john.r.rose at oracle.com Wed Dec 3 22:04:18 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 3 Dec 2014 14:04:18 -0800 Subject: RFC: 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 In-Reply-To: References: <8EDF29FA-40E0-4C5E-BC4C-0AF4067338EE@oracle.com> <546BD3E7.9020503@oracle.com> <538B6724-FD67-4EDF-AE49-1ED9D857FE18@oracle.com> <97D74749-A4EB-4E96-AD87-D42D250612A9@oracle.com> <8CD3358E-2351-47D3-A870-7F8FCB9C3B71@oracle.com> Message-ID: <0276CA4A-A5A5-431C-9350-569193ED3302@oracle.com> On Dec 3, 2014, at 1:17 PM, Roland Westrelin wrote: >> es_failed_realloc/, to strengthen the correspondence; not sure about that one.) > > I?ll make those changes. I assume there?s no need for an updated webrev? Thanks. No new webrev needed. From john.r.rose at oracle.com Wed Dec 3 22:55:52 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 3 Dec 2014 14:55:52 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> Message-ID: <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> On Dec 3, 2014, at 1:13 PM, Roland Westrelin wrote: > ? >> Isn't this statement always a no-op? >> + adjust_check(rc0.ctl, range1, index1, flip1, off_lo, igvn); >> I see that it reproduces the previous behavior, so it's OK. As far as I can see, the main point of this path in the code is that the IfNode can idealize to a dominating duplicate test, just as if it were not a special range check. Is that true? > > It?s true it?s a no-op so I removed it. > >> If that's true, perhaps the search loop should just record (outside of the prev_doms array) the shallowest exact match for the current node. Then, if the range check smearing logic fails to work, the Ideal method can simply return the exact match. >> >> In any case, the associated comment "Valid only if there's a single dominating range check" makes me nervous, since it's possible that there are other dominating range checks which we simply failed to find (due to the search cutoff of 999). If there is a real change to make (if it's not a no-op), we should disable the change if the loop hit 999. > > The comment must be misleading. I reworded it. What we want is that there?s no other range check between the range check that we?re calling Ideal on and the top range check that is identical. Otherwise something like 8048170 (that you reviewed yesterday as well) could happen. That's the part I was missing, and comment explains the problem much better. Let me suggest a further tweak to your comment: + // If we match the test exactly, then the top test covers + // both our lower and upper bounds. Valid only if there's no + // other range check between us and the top test. + // Given Bottom -dom-> Middle? -dom-> Top, with + // us at the bottom, we can't float up past any middle + // checks, because for all we + // know our range check was widened and accesses that + // depend on it also depend on the middle range checks to + // be correct. Also, now that I understand it better, I think that logic sometimes applies to the nb_checks==2 case where you currently return NULL, and I think the "replace immediate" logic should precede all nb_checks tests except nb_checks==0: + if (index1) { ! RangeCheck rc0 = prev_checks[chk0]; + if (nb_checks == 1) { + if (rc0.ctl->in(0)->in(1) == in(1)) { + // If we match the test exactly ? be correct. + prev_dom = rc0.ctl; + } else { + return NULL; } - // Test is now covered by prior checks, dominate it out - prev_dom = prev_chk2; } else { ==> + if (index1) { ! RangeCheck rc0 = prev_checks[chk0]; + if (rc0.ctl->in(0)->in(1) == in(1)) { + // If we match the test exactly ? be correct. + prev_dom = rc0.ctl; + } else if (nb_checks == 1) { + return NULL; } else { That is, do the dance with hi/lo and three range checks, but before that happens prefer to merge back-to-back identical tests. That will catch cases like "a[i+8] += (expr);" where the bytecodes include two range checks that might be separated. It would also make the logic of nb_checks==1 less mysterious, and less obviously buggy with respect to search failures (the 999 problem). (?Or am I missing another point here?) As we saw with the other bug, interchanging 'if'-order is a tricky business, and RC smearing makes it harder. I think our IR doesn't serve us as well as it could here, because there is no way to pin the control of a node to two or more control inputs: You can pin only to zero or one. But after performing RC smearing, what you really want is for the elided RC's dependents to depend on the both rc1 and rc2, simultaneously. If that were expressible, then the 'if'-reordering optimizations later on would be able to correctly place the dependent code. Not that we can do it in C2, but if we were to reverse the order of control edges (as Graal does) it would be more natural to express multi-control placement (at the expense of other things, naturally). > if i x = array[i] > > // some stuff that blocks range check smearing > > if i-1 x = array[i-1] > if i-3 x = array[i-3] > if i x = array[i] > if i-2 x = array[i-2] > > Assuming the second series is optimized: > > if i x = array[i] > > // some stuff that blocks range check smearing > > if i-1 x = array[i-1] > if i-3 x = array[i-3] > if i x = array[i] > x = array[i-2] > > and now if the stuff that blocks range check smearing is optimized out and if i > if i x = array[i] > x = array[i-2] > > if i-1 x = array[i-1] > if i-3 x = array[i-3] > > And we can do an out of bound array access. That is the best explanation I've seen yet of how these bugs work. Would you mind attaching it (verbatim, if you wish) to JDK-8066103? > So the cut off at 999 is not a problem here. The problem is that we can?t substitute a range check for another identical one if there are range checks in between. Excellent. ? John From vladimir.kozlov at oracle.com Thu Dec 4 01:21:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Dec 2014 17:21:37 -0800 Subject: [8u40] RFR(XS) 8066649: 8u backport for 8065618 is incorrect Message-ID: <547FB721.1030107@oracle.com> http://cr.openjdk.java.net/~kvn/8066649/webrev/ https://bugs.openjdk.java.net/browse/JDK-8066649 The new code in 8u backport should not return but instead should guard the execution of the following code. Thanks, Vladimir From igor.veresov at oracle.com Thu Dec 4 01:25:48 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 3 Dec 2014 17:25:48 -0800 Subject: [8u40] RFR(XS) 8066649: 8u backport for 8065618 is incorrect In-Reply-To: <547FB721.1030107@oracle.com> References: <547FB721.1030107@oracle.com> Message-ID: <33D23653-69B9-40A9-AAA7-B7334E01B917@oracle.com> Looks fine. igor > On Dec 3, 2014, at 5:21 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8066649/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8066649 > > The new code in 8u backport should not return but instead should guard the execution of the following code. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Dec 4 01:31:07 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 03 Dec 2014 17:31:07 -0800 Subject: [8u40] RFR(XS) 8066649: 8u backport for 8065618 is incorrect In-Reply-To: <33D23653-69B9-40A9-AAA7-B7334E01B917@oracle.com> References: <547FB721.1030107@oracle.com> <33D23653-69B9-40A9-AAA7-B7334E01B917@oracle.com> Message-ID: <547FB95B.9030201@oracle.com> Thanks! Vladimir On 12/3/14 5:25 PM, Igor Veresov wrote: > Looks fine. > > igor > >> On Dec 3, 2014, at 5:21 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8066649/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8066649 >> >> The new code in 8u backport should not return but instead should guard the execution of the following code. >> >> Thanks, >> Vladimir > From tobias.hartmann at oracle.com Thu Dec 4 06:02:35 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 04 Dec 2014 07:02:35 +0100 Subject: [9] RFR(S): 8066448: SmallCodeCacheStartup.java exits with exit code 1 In-Reply-To: <547F3E66.5070701@oracle.com> References: <547F13C5.4010700@oracle.com> <547F3E66.5070701@oracle.com> Message-ID: <547FF8FB.7050206@oracle.com> Thanks, Vladimir. Best, Tobias On 03.12.2014 17:46, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/3/14 5:44 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following small patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066448 >> Webrev: http://cr.openjdk.java.net/~thartmann/8066448/webrev.00/ >> >> Problem: >> JDK-8064696 changed the test to always expect an exit value of 0. However, the >> test is run with a very small code cache size to check for compiler startup >> failures and may fail during initialization with a VirtualMachineError because >> we are "Out of space in CodeCache for method handle adapters". >> >> Solution: >> I changed the test to check for a VirtualMachineError in case VM initialization >> failed. I also fixed the "Out of space in CodeCache for adapters" message to be >> consistent with the "Out of space in CodeCache for method handle adapters" >> message (upper-case "O"). >> >> Testing: >> - Failing test on JPRT >> >> Thanks, >> Tobias >> From roland.westrelin at oracle.com Thu Dec 4 09:20:02 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 4 Dec 2014 10:20:02 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> Message-ID: <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> Hi John, Thanks for the discussion on this. >> ? >>> Isn't this statement always a no-op? >>> + adjust_check(rc0.ctl, range1, index1, flip1, off_lo, igvn); >>> I see that it reproduces the previous behavior, so it's OK. As far as I can see, the main point of this path in the code is that the IfNode can idealize to a dominating duplicate test, just as if it were not a special range check. Is that true? >> >> It?s true it?s a no-op so I removed it. >> >>> If that's true, perhaps the search loop should just record (outside of the prev_doms array) the shallowest exact match for the current node. Then, if the range check smearing logic fails to work, the Ideal method can simply return the exact match. >>> >>> In any case, the associated comment "Valid only if there's a single dominating range check" makes me nervous, since it's possible that there are other dominating range checks which we simply failed to find (due to the search cutoff of 999). If there is a real change to make (if it's not a no-op), we should disable the change if the loop hit 999. >> >> The comment must be misleading. I reworded it. What we want is that there?s no other range check between the range check that we?re calling Ideal on and the top range check that is identical. Otherwise something like 8048170 (that you reviewed yesterday as well) could happen. > > That's the part I was missing, and comment explains the problem much better. > > Let me suggest a further tweak to your comment: > > + // If we match the test exactly, then the top test covers > + // both our lower and upper bounds. Valid only if there's no > + // other range check between us and the top test. > + // Given Bottom -dom-> Middle? -dom-> Top, with > + // us at the bottom, we can't float up past any middle > + // checks, because for all we > + // know our range check was widened and accesses that > + // depend on it also depend on the middle range checks to > + // be correct. Looks better indeed. Thanks for the improved comment. > > Also, now that I understand it better, I think that logic sometimes applies to the nb_checks==2 case > where you currently return NULL, and I think the "replace immediate" logic should precede > all nb_checks tests except nb_checks==0: > > + if (index1) { > ! RangeCheck rc0 = prev_checks[chk0]; > + if (nb_checks == 1) { > + if (rc0.ctl->in(0)->in(1) == in(1)) { > + // If we match the test exactly ? be correct. > + prev_dom = rc0.ctl; > + } else { > + return NULL; > } > - // Test is now covered by prior checks, dominate it out > - prev_dom = prev_chk2; > } else { > > ==> > > + if (index1) { > ! RangeCheck rc0 = prev_checks[chk0]; > + if (rc0.ctl->in(0)->in(1) == in(1)) { > + // If we match the test exactly ? be correct. > + prev_dom = rc0.ctl; > + } else if (nb_checks == 1) { > + return NULL; > } else { > > That is, do the dance with hi/lo and three range checks, but before that happens prefer to merge back-to-back identical tests. That will catch cases like "a[i+8] += (expr);" where the bytecodes include two range checks that might be separated. It would also make the logic of nb_checks==1 less mysterious, and less obviously buggy with respect to search failures (the 999 problem). (?Or am I missing another point here?) With your change above, wouldn?t we end up with an out of bound array access in my example because it?s now applied even if nb_checks>2? Consider the following example: if i As we saw with the other bug, interchanging 'if'-order is a tricky business, and RC smearing makes it harder. I think our IR doesn't serve us as well as it could here, because there is no way to pin the control of a node to two or more control inputs: You can pin only to zero or one. But after performing RC smearing, what you really want is for the elided RC's dependents to depend on the both rc1 and rc2, simultaneously. If that were expressible, then the 'if'-reordering optimizations later on would be able to correctly place the dependent code. Not that we can do it in C2, but if we were to reverse the order of control edges (as Graal does) it would be more natural to express multi-control placement (at the expense of other things, naturally). 8054478 introduced CastII that cannot be removed because they carry a dependence (to fix an unrelated problem). Wouldn?t that be a conceptually cleaner way of expressing the dependence between a range check and an array access? A Load node wouldn?t need a control but the index computation would depend on a CastII whose control depend on the range check. Then dependency on multiple range check could be expressed with a chain of CastII nodes. >> if i > x = array[i] >> >> // some stuff that blocks range check smearing >> >> if i-1 > x = array[i-1] >> if i-3 > x = array[i-3] >> if i > x = array[i] >> if i-2 > x = array[i-2] >> >> Assuming the second series is optimized: >> >> if i > x = array[i] >> >> // some stuff that blocks range check smearing >> >> if i-1 > x = array[i-1] >> if i-3 > x = array[i-3] >> if i > x = array[i] >> x = array[i-2] >> >> and now if the stuff that blocks range check smearing is optimized out and if i > >> if i > x = array[i] >> x = array[i-2] >> >> if i-1 > x = array[i-1] >> if i-3 > x = array[i-3] >> >> And we can do an out of bound array access. > > That is the best explanation I've seen yet of how these bugs work. Would you mind attaching it (verbatim, if you wish) to JDK-8066103? Done. Roland. > >> So the cut off at 999 is not a problem here. The problem is that we can?t substitute a range check for another identical one if there are range checks in between. > > Excellent. > > ? John From tatiana.pivovarova at oracle.com Thu Dec 4 16:34:41 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Thu, 04 Dec 2014 19:34:41 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented Message-ID: <54808D21.8020603@oracle.com> Hi all, please review this small patch bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 webrev: http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/webrev.00 Problem: Need WhiteBox::allocateCodeBlob(long, int), currently only WhiteBox::allocateCodeBlob(int, int) exist. Solution: Just change function signature WhiteBox::allocateCodeBlob(int, int) -> WhiteBox::allocateCodeBlob(long, int) Test: jprt Thanks, Tatiana From tatiana.pivovarova at oracle.com Thu Dec 4 16:38:28 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Thu, 04 Dec 2014 19:38:28 +0300 Subject: RFR(XXS): 8066250: compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java fails product Message-ID: <54808E04.9090305@oracle.com> Hi all, please review this small patch bugid: https://bugs.openjdk.java.net/browse/JDK-8066250 webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/webrev.00/ Problem: compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java uses develop flag -XX:-VerifyDependencies which is unavailable in product build Solution: add -XX:+IgnoreUnrecognizedVMOptions option Test: jprt Thanks, Tatiana From vladimir.kozlov at oracle.com Thu Dec 4 16:55:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Dec 2014 08:55:38 -0800 Subject: RFR(XXS): 8066250: compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java fails product In-Reply-To: <54808E04.9090305@oracle.com> References: <54808E04.9090305@oracle.com> Message-ID: <5480920A.6050601@oracle.com> Good. Thanks, Vladimir On 12/4/14 8:38 AM, Tatiana Pivovarova wrote: > Hi all, > > please review this small patch > > bugid: https://bugs.openjdk.java.net/browse/JDK-8066250 > webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/webrev.00/ > > Problem: > compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java uses develop flag -XX:-VerifyDependencies > which is unavailable in product build > > Solution: > add -XX:+IgnoreUnrecognizedVMOptions option > > Test: jprt > > Thanks, > Tatiana From vladimir.kozlov at oracle.com Thu Dec 4 17:01:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Dec 2014 09:01:59 -0800 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <54808D21.8020603@oracle.com> References: <54808D21.8020603@oracle.com> Message-ID: <54809387.7050703@oracle.com> I think you need to add cast from long to int: 949 WB_ENTRY(jlong, WB_AllocateCodeBlob(JNIEnv* env, jobject o, jlong size, jint blob_type)) 950 return (jlong) WhiteBox::allocate_code_blob((int)size, blob_type); since: WhiteBox::allocate_code_blob(int size, int blob_type) { Otherwise some C++ compiler may complain. Thanks, Vladimir On 12/4/14 8:34 AM, Tatiana Pivovarova wrote: > Hi all, > > please review this small patch > > bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 > webrev: http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/webrev.00 > > Problem: > Need WhiteBox::allocateCodeBlob(long, int), currently only WhiteBox::allocateCodeBlob(int, int) exist. > > Solution: > Just change function signature WhiteBox::allocateCodeBlob(int, int) -> WhiteBox::allocateCodeBlob(long, int) > > Test: jprt > > Thanks, > Tatiana From tatiana.pivovarova at oracle.com Thu Dec 4 17:54:07 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Thu, 04 Dec 2014 20:54:07 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <54809387.7050703@oracle.com> References: <54808D21.8020603@oracle.com> <54809387.7050703@oracle.com> Message-ID: <54809FBF.4090601@oracle.com> Hi Vladimir, Thank you for your reviews. On 12/04/2014 08:01 PM, Vladimir Kozlov wrote: > I think you need to add cast from long to int: > > 949 WB_ENTRY(jlong, WB_AllocateCodeBlob(JNIEnv* env, jobject o, jlong > size, jint blob_type)) > 950 return (jlong) WhiteBox::allocate_code_blob((int)size, > blob_type); > You are right. I added this fix. webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.01/ Thanks, Tatiana > since: > > WhiteBox::allocate_code_blob(int size, int blob_type) { > > Otherwise some C++ compiler may complain. > > Thanks, > Vladimir > > On 12/4/14 8:34 AM, Tatiana Pivovarova wrote: >> Hi all, >> >> please review this small patch >> >> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >> webrev: >> http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/webrev.00 >> >> Problem: >> Need WhiteBox::allocateCodeBlob(long, int), currently only >> WhiteBox::allocateCodeBlob(int, int) exist. >> >> Solution: >> Just change function signature WhiteBox::allocateCodeBlob(int, int) >> -> WhiteBox::allocateCodeBlob(long, int) >> >> Test: jprt >> >> Thanks, >> Tatiana From vladimir.kozlov at oracle.com Thu Dec 4 18:10:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Dec 2014 10:10:58 -0800 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <54809FBF.4090601@oracle.com> References: <54808D21.8020603@oracle.com> <54809387.7050703@oracle.com> <54809FBF.4090601@oracle.com> Message-ID: <5480A3B2.60208@oracle.com> Good. Thanks, Vladimir On 12/4/14 9:54 AM, Tatiana Pivovarova wrote: > Hi Vladimir, > > Thank you for your reviews. > > On 12/04/2014 08:01 PM, Vladimir Kozlov wrote: >> I think you need to add cast from long to int: >> >> 949 WB_ENTRY(jlong, WB_AllocateCodeBlob(JNIEnv* env, jobject o, jlong >> size, jint blob_type)) >> 950 return (jlong) WhiteBox::allocate_code_blob((int)size, >> blob_type); >> > You are right. I added this fix. > webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.01/ > > Thanks, > Tatiana > >> since: >> >> WhiteBox::allocate_code_blob(int size, int blob_type) { >> >> Otherwise some C++ compiler may complain. >> >> Thanks, >> Vladimir >> >> On 12/4/14 8:34 AM, Tatiana Pivovarova wrote: >>> Hi all, >>> >>> please review this small patch >>> >>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/webrev.00 >>> >>> Problem: >>> Need WhiteBox::allocateCodeBlob(long, int), currently only >>> WhiteBox::allocateCodeBlob(int, int) exist. >>> >>> Solution: >>> Just change function signature WhiteBox::allocateCodeBlob(int, int) >>> -> WhiteBox::allocateCodeBlob(long, int) >>> >>> Test: jprt >>> >>> Thanks, >>> Tatiana > From tatiana.pivovarova at oracle.com Thu Dec 4 18:20:01 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Thu, 04 Dec 2014 21:20:01 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <5480A3B2.60208@oracle.com> References: <54808D21.8020603@oracle.com> <54809387.7050703@oracle.com> <54809FBF.4090601@oracle.com> <5480A3B2.60208@oracle.com> Message-ID: <5480A5D1.2060203@oracle.com> Vladimir, thank you for review! Tatiana On 12/04/2014 09:10 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/4/14 9:54 AM, Tatiana Pivovarova wrote: >> Hi Vladimir, >> >> Thank you for your reviews. >> >> On 12/04/2014 08:01 PM, Vladimir Kozlov wrote: >>> I think you need to add cast from long to int: >>> >>> 949 WB_ENTRY(jlong, WB_AllocateCodeBlob(JNIEnv* env, jobject o, jlong >>> size, jint blob_type)) >>> 950 return (jlong) WhiteBox::allocate_code_blob((int)size, >>> blob_type); >>> >> You are right. I added this fix. >> webrev: >> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.01/ >> >> Thanks, >> Tatiana >> >>> since: >>> >>> WhiteBox::allocate_code_blob(int size, int blob_type) { >>> >>> Otherwise some C++ compiler may complain. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/4/14 8:34 AM, Tatiana Pivovarova wrote: >>>> Hi all, >>>> >>>> please review this small patch >>>> >>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >>>> webrev: >>>> http://cr.openjdk.java.net/~iignatyev/tpivovarova/8065134/webrev.00 >>>> >>>> Problem: >>>> Need WhiteBox::allocateCodeBlob(long, int), currently only >>>> WhiteBox::allocateCodeBlob(int, int) exist. >>>> >>>> Solution: >>>> Just change function signature WhiteBox::allocateCodeBlob(int, int) >>>> -> WhiteBox::allocateCodeBlob(long, int) >>>> >>>> Test: jprt >>>> >>>> Thanks, >>>> Tatiana >> From igor.ignatyev at oracle.com Thu Dec 4 19:09:53 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 04 Dec 2014 22:09:53 +0300 Subject: RFR(XXS) : 8066713 : ignore compiler/types/correctness Message-ID: <5480B181.5050508@oracle.com> http://cr.openjdk.java.net/~iignatyev/8066713/webrev.00/ 2 lines changed: 2 ins; 0 del; 0 mod; Hi all, please review the fix which add @ignore to compiler/types/correctness tests. these tests fail due to https://bugs.openjdk.java.net/browse/JDK-8066173 jbs: https://bugs.openjdk.java.net/browse/JDK-8066713 -- Igor From vladimir.kozlov at oracle.com Thu Dec 4 19:13:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Dec 2014 11:13:54 -0800 Subject: RFR(XXS) : 8066713 : ignore compiler/types/correctness In-Reply-To: <5480B181.5050508@oracle.com> References: <5480B181.5050508@oracle.com> Message-ID: <5480B272.8060806@oracle.com> Good. Can you push it to main instead? jdk9/hs/hotspot hs-comp has new changesets which we don't want to merge into main yet. Thanks, Vladimir On 12/4/14 11:09 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8066713/webrev.00/ > 2 lines changed: 2 ins; 0 del; 0 mod; > > Hi all, > > please review the fix which add @ignore to compiler/types/correctness > tests. these tests fail due to > https://bugs.openjdk.java.net/browse/JDK-8066173 > > jbs: https://bugs.openjdk.java.net/browse/JDK-8066713 > From vladimir.kozlov at oracle.com Thu Dec 4 19:20:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 04 Dec 2014 11:20:45 -0800 Subject: RFR(XXS) : 8066713 : ignore compiler/types/correctness In-Reply-To: <5480B272.8060806@oracle.com> References: <5480B181.5050508@oracle.com> <5480B272.8060806@oracle.com> Message-ID: <5480B40D.2000309@oracle.com> Igor, please, let hs-comp merge finish first (David have to rerun it since it hit this problem too). Thanks, Vladimir On 12/4/14 11:13 AM, Vladimir Kozlov wrote: > Good. > > Can you push it to main instead? jdk9/hs/hotspot > hs-comp has new changesets which we don't want to merge into main yet. > > Thanks, > Vladimir > > On 12/4/14 11:09 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8066713/webrev.00/ >> 2 lines changed: 2 ins; 0 del; 0 mod; >> >> Hi all, >> >> please review the fix which add @ignore to compiler/types/correctness >> tests. these tests fail due to >> https://bugs.openjdk.java.net/browse/JDK-8066173 >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8066713 >> From igor.ignatyev at oracle.com Thu Dec 4 19:58:12 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 04 Dec 2014 22:58:12 +0300 Subject: RFR(XXS) : 8066713 : ignore compiler/types/correctness In-Reply-To: <5480B40D.2000309@oracle.com> References: <5480B181.5050508@oracle.com> <5480B272.8060806@oracle.com> <5480B40D.2000309@oracle.com> Message-ID: <5480BCD4.7040003@oracle.com> Vladimir, thanks for review. sure, I'll be push to main. David, could you please ping me when the merge is finished? Igor On 12/04/2014 10:20 PM, Vladimir Kozlov wrote: > Igor, please, let hs-comp merge finish first (David have to rerun it > since it hit this problem too). > > Thanks, > Vladimir > > On 12/4/14 11:13 AM, Vladimir Kozlov wrote: >> Good. >> >> Can you push it to main instead? jdk9/hs/hotspot >> hs-comp has new changesets which we don't want to merge into main yet. >> >> Thanks, >> Vladimir >> >> On 12/4/14 11:09 AM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8066713/webrev.00/ >>> 2 lines changed: 2 ins; 0 del; 0 mod; >>> >>> Hi all, >>> >>> please review the fix which add @ignore to compiler/types/correctness >>> tests. these tests fail due to >>> https://bugs.openjdk.java.net/browse/JDK-8066173 >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8066713 >>> From dmitrij.pochepko at oracle.com Thu Dec 4 19:13:54 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 04 Dec 2014 22:13:54 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 Message-ID: <5480B272.3030808@oracle.com> Hi, Please review changes for https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: JMX- tests and https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in testlibrary for JDK-8059613 It introduce a number of tests for segmented code cache, mostly testing thresholds, usage, memory notifications using respective MemoryPoolMXBean(s). There is also a small modification for testlibrary(8066440) used in tests. Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ Testing: manually, using fastdebug nightly build from 2014-12-02 Additional note: this patch assumes "https://bugs.openjdk.java.net/browse/JDK-8065134 - Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. Thanks, Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.murillo at oracle.com Thu Dec 4 21:28:53 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 04 Dec 2014 14:28:53 -0700 Subject: RFR(XXS) : 8066713 : ignore compiler/types/correctness In-Reply-To: <5480BCD4.7040003@oracle.com> References: <5480B181.5050508@oracle.com> <5480B272.8060806@oracle.com> <5480B40D.2000309@oracle.com> <5480BCD4.7040003@oracle.com> Message-ID: <5480D215.1010307@oracle.com> Hi there, David's job is done, please push this change asap. I plan to start the snap soon after that's in thanks Alejandro On 12/4/2014 12:58 PM, Igor Ignatyev wrote: > Vladimir, > > thanks for review. > sure, I'll be push to main. > > David, > could you please ping me when the merge is finished? > > Igor > > On 12/04/2014 10:20 PM, Vladimir Kozlov wrote: >> Igor, please, let hs-comp merge finish first (David have to rerun it >> since it hit this problem too). >> >> Thanks, >> Vladimir >> >> On 12/4/14 11:13 AM, Vladimir Kozlov wrote: >>> Good. >>> >>> Can you push it to main instead? jdk9/hs/hotspot >>> hs-comp has new changesets which we don't want to merge into main yet. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/4/14 11:09 AM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8066713/webrev.00/ >>>> 2 lines changed: 2 ins; 0 del; 0 mod; >>>> >>>> Hi all, >>>> >>>> please review the fix which add @ignore to compiler/types/correctness >>>> tests. these tests fail due to >>>> https://bugs.openjdk.java.net/browse/JDK-8066173 >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8066713 >>>> -- Alejandro From john.r.rose at oracle.com Thu Dec 4 21:48:27 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 4 Dec 2014 13:48:27 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> Message-ID: > On Dec 4, 2014, at 1:20 AM, Roland Westrelin wrote: > > > With your change above, wouldn?t we end up with an out of bound array access in my example because it?s now applied even if nb_checks>2? You are right. That's because I suggested the wrong code. I meant to suggest merging the last two tests, not the first and last: > + if (nb_checks <= NRC && prev_checks[(nb_checks - NRC) % NRC].ctl->in(0)->in(1) == in(1)) { Or: > + if (most_recent_prev_check.ctl->in(0)->in(1) == in(1)) { (Where most_recent_prev_check is collected in the previous loop only when nb_checks==0.) That logic should cleanly subsume the tricky existing check at nb_checks==1 and generalize well. The adjustment I'm suggesting *only* applies to the last two checks (on the same index1, in the encounter order of the search loop). Since they are always adjacent, and we take care never to reorder range check operations, this would be immune to the failure case you describe. My point is to separate out the adjacent-check merging from the smearing transformation. As originally coded, the two tactics are imperfectly combined in the nb_checks==1 case. > > Consider the following example: > > if i x = array[i] > > // some stuff that blocks range check smearing > > if i-3 x = array[i-3] > if i x = array[i] > if i-2 x = array[i-2] > > optimized to: > > if i x = array[i] > > // some stuff that blocks range check smearing > > if i-3 x = array[i-3] > if i x = array[i] > x = array[i-2] > > if the stuff that blocks is optimized out then we can end up with an out of bound access with nb_checks == 2: > > if i x = array[i] > x = array[i-2] > if i-3 x = array[i-3] That can happen only if the control input of "array[i-2]" gets rewritten from the second 'if' clause to the first 'if' clause. I agree that would be wrong (either here or in the loop opts). But your code is careful to avoid reordering tests; it only removes them. BTW, it seems to me that the degenerate case of off_hi==off_lo is interesting. (I.e., a long run of tests at the same index, perhaps with interfering tests disappearing due to optimization.) I think that your code would fold those into two tests of the same index, wouldn't it? Thanks again! ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From brendan.d.gregg at gmail.com Thu Dec 4 22:55:37 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Thu, 4 Dec 2014 14:55:37 -0800 Subject: A hotspot patch for stack profiling (frame pointer) Message-ID: G'Day, I've hacked hotspot to return the frame pointer, in part to see what this involves, and also to have a working prototype for analysis. Along with an agent to resolve symbols, this has allowed full stack profiling using Linux perf_events. The following flame graphs show the resulting profiles. A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg Same thing, but this time disabling inlining, to show more frames: http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg As expected, performance is worse without inlining. You can compare the flame graphs side by side to see why. Less time spent doing work / I/O! https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff is my patch, and currently only works for x86-64. It removes RBP from the register pools, and inserts "mov(rbp, rsp)" into two function prologues. It is also unsupported: use at your own risk. I'm not a veteran hotspot engineer, so chances I messed something up are high. I'd love to be able to enable frame pointers in Oracle JDK, eg, with an -XX:+NoOmitFramePointer option. It could be put under -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long as we had some way to turn it on. If someone wants to include (improve, rewrite) my patch, please do. I don't have much perf data yet, but on the vert.x microbenchmark it looked like returning the frame pointer cost 2.6% performance. I hope that's somewhat worst-case for production workloads. (I was also able to recover the 2.6% by fine tuning other options, so were this a production change, I'd be hoping not to regress performance at all.) We've discussed this before ( http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) should work very well. The JVM can run as-is, full stacks can be generated on-demand, and symbols should always be correct. The frame pointer approach costs a little performance, and only shows partial stacks after inlining (unless you disable inlining, but that can cost >40% performance). There is the other issue Volker Simonis mentioned as well, where some stacks may not be profiled correctly. And, if you are unlucky, symbols can move during the profile, so any static perf-map-agent map will translate some incorrectly (I've considered developing a way to detect this, and highlight such frames as dubious.) At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this feature is going to be a tough sell, especially when the value of full stack profiling isn't widely understood. I personally think it might be a bit easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try the feature, then consider the better Solaris version after gaining solid experience on why it is so important. We recently blogged about the value of stack profiling and flame graphs, http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was for Node.js, which already has frame pointer support. If anyone wants to try generating these mixed mode CPU flame graphs themselves (in a test environment!), the first step is to compile OpenJDK 8 b132 with the previous patch, and get that running. Also install the packages for the "perf" command. The remaining steps would be something like: # git clone --depth=1 https://github.com/brendangregg/FlameGraph # git clone --depth=1 https://github.com/jrudolph/perf-map-agent # cd perf-map-agent # export JAVA_HOME=/... # cmake . # make # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar net.virtualvoid.perf.AttachOnce `pgrep -n java` # perf script > ../FlameGraph/out.stacks # cd ../FlameGraph # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > out.svg Finally, if you are new to CPU flame graphs, see http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Fri Dec 5 08:16:58 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 05 Dec 2014 12:16:58 +0400 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <547EE2E3.90000@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> <547DCAC9.5000105@oracle.com> <547DD64B.7070704@oracle.com> <547EE2E3.90000@oracle.com> Message-ID: <548169FA.90602@oracle.com> Hi everyone, I need one more review. Could anyone do it for me? Thank you in advance, Evgeniya Stepanova On 03.12.2014 14:16, Evgeniya Stepanova wrote: > Christian, > Thank you for the review! > > On 03.12.2014 2:28, Christian Thalinger wrote: >> Looks good. >> >>> On Dec 2, 2014, at 7:10 AM, Evgeniya Stepanova >>> >> > wrote: >>> >>> Hi Filipp, >>> Thanks for the review! >>> No problems, only changes in >>> test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >>> were needed to do that. >>> new webrev >>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.02/ >>> >>> On 02.12.2014 18:20, Filipp Zhinkin wrote: >>>> Evgeniya, >>>> >>>> thank you for taking care of it! >>>> >>>> Sorry that I'm asking you about that only now, >>>> but could use the same order of arguments in >>>> verifyJVMStartup and verifySameJVMStartup? >>>> >>>> public static void verifyJVMStartup(String expectedMessages[], >>>> String unexpectedMessages[], ExitCode exitCode, >>>> String exitErrorMessage, String wrongWarningMessage, >>>> boolean addTestVMOptions, String... options) >>>> >>>> public static void verifySameJVMStartup(String expectedMessages[], >>>> String unexpectedMessages[], String exitErrorMessage, >>>> String wrongWarningMessage, ExitCode exitCode, >>>> String... options) >>>> >>>> Could you place exitCode after *Message in both methods? >>>> >>>> Otherwise the change looks good. >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: >>>>> Hi Christian, >>>>> >>>>> Thank you very much for the review >>>>> >>>>> I've replaced message >>>>> + "JVMStartup should have exit value '%d'.%n%s", >>>>> with the >>>>> + "JVM process should have exit value '%d'.%n%s", >>>>> and >>>>> + "JVMStartup should be successful with option '%s'.", >>>>> with the >>>>> + "JVM should start with option '%s' without errors.", >>>>> >>>>> new webrev is >>>>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ >>>>> >>>>> Thanks, >>>>> Evgeniya Stepanova >>>>> >>>>> On 02.12.2014 2:49, Christian Thalinger wrote: >>>>>> I didn?t verify all new messages but this looks very useful. The >>>>>> only thing I could complain about is: >>>>>> >>>>>> + "JVMStartup should have exit value '%d'.%n%s", >>>>>> >>>>>> JVMStartup probably refers to some internal method. A more >>>>>> general message might be better. >>>>>> >>>>>> In any case, looks good to me. >>>>>> >>>>>>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Could you please review fix for 8054892? >>>>>>> Problem: CLI tests do not show what exactly went wrong when test >>>>>>> failed. They show an error behavior is not as expected. >>>>>>> Solution: Added explanation which behavior is expected and why >>>>>>> it is so. >>>>>>> >>>>>>> Base class >>>>>>> /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java >>>>>>> changed to use error string, submitted by tests classes. >>>>>>> -exitErrorMessage message to be shown if exit code of JVM >>>>>>> process is not as expected. >>>>>>> -wrongWarningMessage message to be shown if warning messages >>>>>>> in output are not as expected. >>>>>>> -optionErrorString to be shown if option value is not as expected. >>>>>>> Updated tests from test/compiler/rtm/cli/, >>>>>>> test/compiler/rtm/cli/ and test/compiler/intrinsics/sha/cli folders. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>>>>>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> /Evgeniya Stepanova/ >>>> >>> >>> -- >>> /Evgeniya Stepanova/ >> > > -- > /Evgeniya Stepanova/ -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Dec 5 09:00:51 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 05 Dec 2014 10:00:51 +0100 Subject: RFR(XXS): 8066250: compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java fails product In-Reply-To: <54808E04.9090305@oracle.com> References: <54808E04.9090305@oracle.com> Message-ID: <54817443.60901@oracle.com> Hi, looks good. Thanks for fixing this! Best, Tobias On 04.12.2014 17:38, Tatiana Pivovarova wrote: > Hi all, > > please review this small patch > > bugid: https://bugs.openjdk.java.net/browse/JDK-8066250 > webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/webrev.00/ > > Problem: > compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java uses > develop flag -XX:-VerifyDependencies which is unavailable in product build > > Solution: > add -XX:+IgnoreUnrecognizedVMOptions option > > Test: jprt > > Thanks, > Tatiana From roland.westrelin at oracle.com Fri Dec 5 10:35:14 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 5 Dec 2014 11:35:14 +0100 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <548169FA.90602@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> <547DCAC9.5000105@oracle.com> <547DD64B.7070704@oracle.com> <547EE2E3.90000@oracle.com> <548169FA.90602@oracle.com> Message-ID: <02044399-2CD3-40B3-9FA0-68C0F66A1DEA@oracle.com> That looks good to me. Roland. > On Dec 5, 2014, at 9:16 AM, Evgeniya Stepanova wrote: > > Hi everyone, > > I need one more review. Could anyone do it for me? > > Thank you in advance, > Evgeniya Stepanova > On 03.12.2014 14:16, Evgeniya Stepanova wrote: >> Christian, >> Thank you for the review! >> >> On 03.12.2014 2:28, Christian Thalinger wrote: >>> Looks good. >>> >>>> On Dec 2, 2014, at 7:10 AM, Evgeniya Stepanova wrote: >>>> >>>> Hi Filipp, >>>> Thanks for the review! >>>> No problems, only changes in test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java were needed to do that. >>>> new webrev >>>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.02/ >>>> >>>> On 02.12.2014 18:20, Filipp Zhinkin wrote: >>>>> Evgeniya, >>>>> >>>>> thank you for taking care of it! >>>>> >>>>> Sorry that I'm asking you about that only now, >>>>> but could use the same order of arguments in >>>>> verifyJVMStartup and verifySameJVMStartup? >>>>> >>>>> public static void verifyJVMStartup(String expectedMessages[], >>>>> String unexpectedMessages[], ExitCode exitCode, >>>>> String exitErrorMessage, String wrongWarningMessage, >>>>> boolean addTestVMOptions, String... options) >>>>> >>>>> public static void verifySameJVMStartup(String expectedMessages[], >>>>> String unexpectedMessages[], String exitErrorMessage, >>>>> String wrongWarningMessage, ExitCode exitCode, String... options) >>>>> >>>>> Could you place exitCode after *Message in both methods? >>>>> >>>>> Otherwise the change looks good. >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: >>>>>> Hi Christian, >>>>>> >>>>>> Thank you very much for the review >>>>>> >>>>>> I've replaced message >>>>>> + "JVMStartup should have exit value '%d'.%n%s", >>>>>> >>>>>> with the >>>>>> + "JVM process should have exit value '%d'.%n%s", >>>>>> >>>>>> and >>>>>> + "JVMStartup should be successful with option '%s'.", >>>>>> with the >>>>>> + "JVM should start with option '%s' without errors.", >>>>>> >>>>>> new webrev is >>>>>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Evgeniya Stepanova >>>>>> >>>>>> On 02.12.2014 2:49, Christian Thalinger wrote: >>>>>>> I didn?t verify all new messages but this looks very useful. The only thing I could complain about is: >>>>>>> >>>>>>> + "JVMStartup should have exit value '%d'.%n%s", >>>>>>> >>>>>>> JVMStartup probably refers to some internal method. A more general message might be better. >>>>>>> >>>>>>> In any case, looks good to me. >>>>>>> >>>>>>>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could you please review fix for 8054892? >>>>>>>> Problem: CLI tests do not show what exactly went wrong when test failed. They show an error behavior is not as expected. >>>>>>>> Solution: Added explanation which behavior is expected and why it is so. >>>>>>>> >>>>>>>> Base class /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java changed to use error string, submitted by tests classes. >>>>>>>> -exitErrorMessage message to be shown if exit code of JVM process is not as expected. >>>>>>>> -wrongWarningMessage message to be shown if warning messages in output are not as expected. >>>>>>>> -optionErrorString to be shown if option value is not as expected. >>>>>>>> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ and test/compiler/intrinsics/sha/cli folders. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>>>>>>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Evgeniya Stepanova >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Evgeniya Stepanova >>>>> >>>> >>>> -- >>>> Evgeniya Stepanova >>> >> >> -- >> Evgeniya Stepanova > > -- > Evgeniya Stepanova From manasthakur17 at gmail.com Fri Dec 5 10:49:54 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Fri, 5 Dec 2014 16:19:54 +0530 Subject: Locating call sites of methods in C2 Message-ID: <64E2023B-8362-4ED2-B755-366FAA5B615D@gmail.com> Hi Is there a way to access the call-site (possibly in terms of the bytecode offset) of a method being compiled by C2? Doesn?t the current compile task store it in some variable? Regards, Manas From evgeniya.stepanova at oracle.com Fri Dec 5 10:55:27 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Fri, 05 Dec 2014 14:55:27 +0400 Subject: RFR(M): 8054892: Improve compiler's CLI tests error reporting In-Reply-To: <02044399-2CD3-40B3-9FA0-68C0F66A1DEA@oracle.com> References: <5477075A.1090205@oracle.com> <862CB689-C816-4696-B50D-5F2280D04346@oracle.com> <547D9AA0.5010103@oracle.com> <547DCAC9.5000105@oracle.com> <547DD64B.7070704@oracle.com> <547EE2E3.90000@oracle.com> <548169FA.90602@oracle.com> <02044399-2CD3-40B3-9FA0-68C0F66A1DEA@oracle.com> Message-ID: <54818F1F.6060701@oracle.com> Hi Roland, Thank you very much for the review! On 05.12.2014 14:35, Roland Westrelin wrote: > That looks good to me. > > Roland. > >> On Dec 5, 2014, at 9:16 AM, Evgeniya Stepanova wrote: >> >> Hi everyone, >> >> I need one more review. Could anyone do it for me? >> >> Thank you in advance, >> Evgeniya Stepanova >> On 03.12.2014 14:16, Evgeniya Stepanova wrote: >>> Christian, >>> Thank you for the review! >>> >>> On 03.12.2014 2:28, Christian Thalinger wrote: >>>> Looks good. >>>> >>>>> On Dec 2, 2014, at 7:10 AM, Evgeniya Stepanova wrote: >>>>> >>>>> Hi Filipp, >>>>> Thanks for the review! >>>>> No problems, only changes in test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java were needed to do that. >>>>> new webrev >>>>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.02/ >>>>> >>>>> On 02.12.2014 18:20, Filipp Zhinkin wrote: >>>>>> Evgeniya, >>>>>> >>>>>> thank you for taking care of it! >>>>>> >>>>>> Sorry that I'm asking you about that only now, >>>>>> but could use the same order of arguments in >>>>>> verifyJVMStartup and verifySameJVMStartup? >>>>>> >>>>>> public static void verifyJVMStartup(String expectedMessages[], >>>>>> String unexpectedMessages[], ExitCode exitCode, >>>>>> String exitErrorMessage, String wrongWarningMessage, >>>>>> boolean addTestVMOptions, String... options) >>>>>> >>>>>> public static void verifySameJVMStartup(String expectedMessages[], >>>>>> String unexpectedMessages[], String exitErrorMessage, >>>>>> String wrongWarningMessage, ExitCode exitCode, String... options) >>>>>> >>>>>> Could you place exitCode after *Message in both methods? >>>>>> >>>>>> Otherwise the change looks good. >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>>>> >>>>>> On 12/02/2014 02:55 PM, Evgeniya Stepanova wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> Thank you very much for the review >>>>>>> >>>>>>> I've replaced message >>>>>>> + "JVMStartup should have exit value '%d'.%n%s", >>>>>>> >>>>>>> with the >>>>>>> + "JVM process should have exit value '%d'.%n%s", >>>>>>> >>>>>>> and >>>>>>> + "JVMStartup should be successful with option '%s'.", >>>>>>> with the >>>>>>> + "JVM should start with option '%s' without errors.", >>>>>>> >>>>>>> new webrev is >>>>>>> http://cr.openjdk.java.net/~eistepan/8054892/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Evgeniya Stepanova >>>>>>> >>>>>>> On 02.12.2014 2:49, Christian Thalinger wrote: >>>>>>>> I didn?t verify all new messages but this looks very useful. The only thing I could complain about is: >>>>>>>> >>>>>>>> + "JVMStartup should have exit value '%d'.%n%s", >>>>>>>> >>>>>>>> JVMStartup probably refers to some internal method. A more general message might be better. >>>>>>>> >>>>>>>> In any case, looks good to me. >>>>>>>> >>>>>>>>> On Nov 27, 2014, at 3:13 AM, Evgeniya Stepanova wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could you please review fix for 8054892? >>>>>>>>> Problem: CLI tests do not show what exactly went wrong when test failed. They show an error behavior is not as expected. >>>>>>>>> Solution: Added explanation which behavior is expected and why it is so. >>>>>>>>> >>>>>>>>> Base class /testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java changed to use error string, submitted by tests classes. >>>>>>>>> -exitErrorMessage message to be shown if exit code of JVM process is not as expected. >>>>>>>>> -wrongWarningMessage message to be shown if warning messages in output are not as expected. >>>>>>>>> -optionErrorString to be shown if option value is not as expected. >>>>>>>>> Updated tests from test/compiler/rtm/cli/, test/compiler/rtm/cli/ and test/compiler/intrinsics/sha/cli folders. >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8054892 >>>>>>>>> webrev: http://cr.openjdk.java.net/~eistepan/8054892/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Evgeniya Stepanova >>>>>>>>> >>>>>>> -- >>>>>>> Evgeniya Stepanova >>>>> -- >>>>> Evgeniya Stepanova >>> -- >>> Evgeniya Stepanova >> -- >> Evgeniya Stepanova -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tatiana.pivovarova at oracle.com Fri Dec 5 12:37:56 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 05 Dec 2014 15:37:56 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented Message-ID: <5481A724.1070107@oracle.com> Hi all, please review this new small patch bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ Problem: Need WhiteBox::allocateCodeBlob(long, int), currently only WhiteBox::allocateCodeBlob(int, int) exist. I change previous fix to this new patch because this conversation [*] Solution: public long allocateCodeBlob(long size, int type) { return allocateCodeBlob((int) size, type); } Test: jprt [*] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html Thanks, Tatiana From roland.westrelin at oracle.com Fri Dec 5 13:30:47 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 5 Dec 2014 14:30:47 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> Message-ID: <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> Hi John, >> With your change above, wouldn?t we end up with an out of bound array access in my example because it?s now applied even if nb_checks>2? > > You are right. That's because I suggested the wrong code. I meant to suggest merging the last two tests, not the first and last: > >> + if (nb_checks <= NRC && prev_checks[(nb_checks - NRC) % NRC].ctl->in(0)->in(1) == in(1)) { > > Or: > >> + if (most_recent_prev_check.ctl->in(0)->in(1) == in(1)) { > > (Where most_recent_prev_check is collected in the previous loop only when nb_checks==0.) > > That logic should cleanly subsume the tricky existing check at nb_checks==1 and generalize well. > > The adjustment I'm suggesting *only* applies to the last two checks (on the same index1, in the encounter order of the search loop). Since they are always adjacent, and we take care never to reorder range check operations, this would be immune to the failure case you describe. > > My point is to separate out the adjacent-check merging from the smearing transformation. As originally coded, the two tactics are imperfectly combined in the nb_checks==1 case. Is below what you?re suggesting? Indeed it makes sense. It should be nb_checks < NRC, because in case we have 3 checks they could be optimized to 2 range checks which is better than replacing the current range check with the 3rd range check, right? diff --git a/src/share/vm/opto/ifnode.cpp b/src/share/vm/opto/ifnode.cpp --- a/src/share/vm/opto/ifnode.cpp +++ b/src/share/vm/opto/ifnode.cpp @@ -924,23 +924,21 @@ // Non-constant indices must check both low and high. int chk0 = (nb_checks - 1) % NRC; if (index1) { - RangeCheck rc0 = prev_checks[chk0]; - if (nb_checks == 1) { - if (rc0.ctl->in(0)->in(1) == in(1)) { - // If we match the test exactly, then the top test covers - // both our lower and upper bounds. Valid only if there's no - // other range check between us and the top test: for all we - // know this range check was widened and accesses that - // depend on it also depend on the previous range checks to - // be correct. - prev_dom = rc0.ctl; - } else { + if (nb_checks < NRC && prev_checks[nb_checks].ctl->in(0)->in(1) == in(1)) { + // If we match the test exactly, then the test covers both our + // lower and upper bounds. Valid only if there's no other + // range check between us and the test that is identical: for + // all we know this range check was widened and accesses that + // depend on it also depend on the previous range checks to be + // correct. + prev_dom = prev_checks[nb_checks].ctl; + } else if (nb_checks == 1) { return NULL; - } } else { // If the top range check's constant is the min or max of // all constants we widen the next one to cover the whole // range of constants. + RangeCheck rc0 = prev_checks[chk0]; int chk1 = (nb_checks - 2) % NRC; RangeCheck rc1 = prev_checks[chk1]; if (rc0.off == off_lo) { > BTW, it seems to me that the degenerate case of off_hi==off_lo is interesting. (I.e., a long run of tests at the same index, perhaps with interfering tests disappearing due to optimization.) I think that your code would fold those into two tests of the same index, wouldn't it? Wouldn?t we adjust the top 2 range checks and keep 2 of them but the range checks that are adjusted are reprocessed by the IGVN and it would fold the top 2 range checks in a single one because they perform an identical check? Roland. From filipp.zhinkin at oracle.com Fri Dec 5 17:06:21 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 05 Dec 2014 21:06:21 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests Message-ID: <5481E60D.9020309@oracle.com> Hi, please take a look at CLI tests for segmented code cache (JDK-8059623). There are three new tests: compiler/codecache/cli/ codeheapsize/TestCodeHeapSizeOptions printcodecache/TestPrintCodeCacheOption TestSegmentedCodeCacheOption All tests consist of several test cases aimed to verify different aspects of options' processing. These tests partially overlapped with c/c/CheckSegmentedCodeCache test, but add additional value - these tests actually check final values of tested options and verifies PrintCodeCache output. Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ Testing: manual & automated This change depends on: https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI tests error reporting https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in testlibrary for JDK-8059613 Thanks Filipp. From dmitrij.pochepko at oracle.com Fri Dec 5 17:18:49 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 05 Dec 2014 20:18:49 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5480B272.3030808@oracle.com> References: <5480B272.3030808@oracle.com> Message-ID: <5481E8F9.1080307@oracle.com> Adding hotspot-dev for wider audience. > Hi, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: > Test task: JMX- tests > and > https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in > testlibrary for JDK-8059613 > > It introduce a number of tests for segmented code cache, mostly > testing thresholds, usage, > memory notifications using respective MemoryPoolMXBean(s). > There is also a small modification for testlibrary(8066440) used in > tests. > > Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ > > Testing: manually, using fastdebug nightly build from 2014-12-02 > > Additional note: this patch assumes > "https://bugs.openjdk.java.net/browse/JDK-8065134 - > Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" > is fixed. > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Fri Dec 5 19:04:11 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 5 Dec 2014 11:04:11 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> Message-ID: > On Dec 5, 2014, at 5:30 AM, Roland Westrelin wrote: > > Hi John, > >>> With your change above, wouldn?t we end up with an out of bound array access in my example because it?s now applied even if nb_checks>2? >> >> You are right. That's because I suggested the wrong code. I meant to suggest merging the last two tests, not the first and last: >> >>> + if (nb_checks <= NRC && prev_checks[(nb_checks - NRC) % NRC].ctl->in(0)->in(1) == in(1)) { >> >> Or: >> >>> + if (most_recent_prev_check.ctl->in(0)->in(1) == in(1)) { >> >> (Where most_recent_prev_check is collected in the previous loop only when nb_checks==0.) >> >> That logic should cleanly subsume the tricky existing check at nb_checks==1 and generalize well. >> >> The adjustment I'm suggesting *only* applies to the last two checks (on the same index1, in the encounter order of the search loop). Since they are always adjacent, and we take care never to reorder range check operations, this would be immune to the failure case you describe. >> >> My point is to separate out the adjacent-check merging from the smearing transformation. As originally coded, the two tactics are imperfectly combined in the nb_checks==1 case. > > Is below what you?re suggesting? Yes, pretty much, but see the following. > Indeed it makes sense. The first encountered matching test will be stored in prev_checks[0] if and only if 1 <= nb_checks <= NRC. So I was thinking: not: nb_checks < NRC && prev_checks[nb_checks].ctl->in(0)->in(1) == in(1) but: nb_checks <= NRC && prev_checks[0].ctl->in(0)->in(1) == in(1) Or better yet a purely local cutout. (This sketch has a bad goto; the value of 'prev_dom' carried by the goto is what I called 'most_recent_prev_check' above.) diff --git a/src/share/vm/opto/ifnode.cpp b/src/share/vm/opto/ifnode.cpp --- a/src/share/vm/opto/ifnode.cpp +++ b/src/share/vm/opto/ifnode.cpp @@ -876,6 +876,7 @@ // Low and high offsets seen so far jint off_lo = offset1; jint off_hi = offset1; + int nb_checks = 0; // Scan for the top 2 checks and collect range of offsets for( int dist = 0; dist < 999; dist++ ) { // Range-Check scan limit @@ -890,6 +891,15 @@ // the same array bounds. if( flip2 == flip1 && range2 == range1 && index2 == index1 && dom->outcnt() == 2 ) { + if (nb_checks == 0 && dom->in(1) == in(1)) { + // Found an immediately dominating test at the same offset. + // This kind of back-to-back test can be eliminated locally, + // and there is no need to search further for dominating tests. + assert(offset2 == offset1, ""); + prev_dom = dom; + goto got_prev_dom; // FIXME: unstructured control flow + } + nb_checks++; // Gather expanded bounds off_lo = MIN2(off_lo,offset2); off_hi = MAX2(off_hi,offset2); @@ -985,6 +995,7 @@ } // End of Else scan for an equivalent test + got_prev_dom: // FIXME: unstructured control flow // Hit! Remove this IF #ifndef PRODUCT if( TraceIterativeGVN ) { > It should be nb_checks < NRC, because in case we have 3 checks they could be optimized to 2 range checks which is better than replacing the current range check with the 3rd range check, right? That's a fair argument. Except I would say "the same as" rather than "better", because I think we will usually get the same code either way, but in a very different IGVN ordering. The thing I'm getting at is I like to think about the back-to-back case with distinct logic. Local transformations are easier to reason about in IGVN and may be more robust. But it's also a matter of taste here. I'm paying attention to this code because I have visited it before and failed to spot the bug, but remember my feelings of unease. I think this logic (with other RCE) will continue to be important as we invest in "Arrays 2.0". Like you, I want to leave it clearer than before so we can build on it confidently. > diff --git a/src/share/vm/opto/ifnode.cpp b/src/share/vm/opto/ifnode.cpp > ... > > >> BTW, it seems to me that the degenerate case of off_hi==off_lo is interesting. (I.e., a long run of tests at the same index, perhaps with interfering tests disappearing due to optimization.) I think that your code would fold those into two tests of the same index, wouldn't it? > > Wouldn?t we adjust the top 2 range checks and keep 2 of them but the range checks that are adjusted are reprocessed by the IGVN and it would fold the top 2 range checks in a single one because they perform an identical check? That's what I hope for; glad you agree. Two final thoughts, neither of which block this review: We can consider having a CheckNode as a subclass of IfNode, kind of like LoopNode is a subclass of RegionNode. This could make RCE transformations more robust. The important distinction is that the CheckNode can optimistically perform over-strong checks; this makes it different from a normal IfNode and suitable for smeared RCE and other speculative stuff. We need a way for Java library code (our JVM users) to code range checks which can be optimized with the same power as built-in range checks (from "aaload" and similar bytecodes). Supporting RCE for user-written RC's is key for Arrays 2.0. Optimizing "x >= 0 && x < len" to "x References: Message-ID: Hi Brendan, I'm still not understanding who is taking the actual stack traces (let alone the symbols) in your examples. Is this done by 'perf' itself based only on the frame pointer? As I wrote before, this is pretty hard to get right for a JVM, but there are good approximations. Have you looked at the 'jstack' tool which is part of the JDK? If you run it on a Java process, it will give you exact stack traces with full inlining information. However this only works at safepoints so it is probably not suitable for profiling with performance counters. But you can also use 'jstack -F -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most of the time even with inlined Java frames. This is probably the best you can get when interrupting a running JVM at an arbitrary point in time. As you mentioned in one of your blogs, the VM can be in the C-Library or even in the kernel at that time which don't preserve the frame pointer either. So it will be already hard to even walk up to the first Java frame. But nevertheless, if the output of 'jstack -F -m' is "good enough" for your purpose, you can implement something similar in 'perf' or a helper library of 'perf' and be happy (I don't actually know how perf takes stack traces but I suppose there may some kind of callback mechanism for walking unknown frames). This is actually not so hard. I've recently implemented a "print_native_stack()" function within hotspot itself (you can call it for example from gdb during debugging - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). Maye you could call this functions directly from 'perf' if perf attaches with ptrace to the process (I assume it does or how else could it walk the stack)? These were just some random thoughts with the hope that they may be helpful. Regards, Volker PS: by the way - the flame graphs look really impressive and it would be really nice to have something like this for Java. On Thu, Dec 4, 2014 at 11:55 PM, Brendan Gregg wrote: > G'Day, > > I've hacked hotspot to return the frame pointer, in part to see what this > involves, and also to have a working prototype for analysis. Along with an > agent to resolve symbols, this has allowed full stack profiling using Linux > perf_events. The following flame graphs show the resulting profiles. > > A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > Same thing, but this time disabling inlining, to show more frames: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg > > As expected, performance is worse without inlining. You can compare the > flame graphs side by side to see why. Less time spent doing work / I/O! > > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > is my patch, and currently only works for x86-64. It removes RBP from the > register pools, and inserts "mov(rbp, rsp)" into two function prologues. It > is also unsupported: use at your own risk. I'm not a veteran hotspot > engineer, so chances I messed something up are high. > > I'd love to be able to enable frame pointers in Oracle JDK, eg, with an > -XX:+NoOmitFramePointer option. It could be put under > -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long > as we had some way to turn it on. If someone wants to include (improve, > rewrite) my patch, please do. > > I don't have much perf data yet, but on the vert.x microbenchmark it looked > like returning the frame pointer cost 2.6% performance. I hope that's > somewhat worst-case for production workloads. (I was also able to recover > the 2.6% by fine tuning other options, so were this a production change, I'd > be hoping not to regress performance at all.) > > We've discussed this before > (http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). > The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) > should work very well. The JVM can run as-is, full stacks can be generated > on-demand, and symbols should always be correct. > > The frame pointer approach costs a little performance, and only shows > partial stacks after inlining (unless you disable inlining, but that can > cost >40% performance). There is the other issue Volker Simonis mentioned as > well, where some stacks may not be profiled correctly. And, if you are > unlucky, symbols can move during the profile, so any static perf-map-agent > map will translate some incorrectly (I've considered developing a way to > detect this, and highlight such frames as dubious.) > > At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this > feature is going to be a tough sell, especially when the value of full stack > profiling isn't widely understood. I personally think it might be a bit > easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try > the feature, then consider the better Solaris version after gaining solid > experience on why it is so important. > > We recently blogged about the value of stack profiling and flame graphs, > http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was > for Node.js, which already has frame pointer support. > > If anyone wants to try generating these mixed mode CPU flame graphs > themselves (in a test environment!), the first step is to compile OpenJDK 8 > b132 with the previous patch, and get that running. Also install the > packages for the "perf" command. The remaining steps would be something > like: > > # git clone --depth=1 https://github.com/brendangregg/FlameGraph > # git clone --depth=1 https://github.com/jrudolph/perf-map-agent > # cd perf-map-agent > # export JAVA_HOME=/... > # cmake . > # make > # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 > # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar > net.virtualvoid.perf.AttachOnce `pgrep -n java` > # perf script > ../FlameGraph/out.stacks > # cd ../FlameGraph > # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > > out.svg > > Finally, if you are new to CPU flame graphs, see > http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . > > Brendan From staffan.larsen at oracle.com Fri Dec 5 19:34:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 5 Dec 2014 20:34:43 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: Just to note that the implementation of ?jstack -F? is not at all suitable for profiling since has a very high overhead (it attaches a debugger to the process). /Staffan > On 5 dec 2014, at 20:22, Volker Simonis wrote: > > Hi Brendan, > > I'm still not understanding who is taking the actual stack traces (let > alone the symbols) in your examples. Is this done by 'perf' itself > based only on the frame pointer? > > As I wrote before, this is pretty hard to get right for a JVM, but > there are good approximations. Have you looked at the 'jstack' tool > which is part of the JDK? If you run it on a Java process, it will > give you exact stack traces with full inlining information. However > this only works at safepoints so it is probably not suitable for > profiling with performance counters. But you can also use 'jstack -F > -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most > of the time even with inlined Java frames. This is probably the best > you can get when interrupting a running JVM at an arbitrary point in > time. As you mentioned in one of your blogs, the VM can be in the > C-Library or even in the kernel at that time which don't preserve the > frame pointer either. So it will be already hard to even walk up to > the first Java frame. > > But nevertheless, if the output of 'jstack -F -m' is "good enough" for > your purpose, you can implement something similar in 'perf' or a > helper library of 'perf' and be happy (I don't actually know how perf > takes stack traces but I suppose there may some kind of callback > mechanism for walking unknown frames). This is actually not so hard. > I've recently implemented a "print_native_stack()" function within > hotspot itself (you can call it for example from gdb during debugging > - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). > Maye you could call this functions directly from 'perf' if perf > attaches with ptrace to the process (I assume it does or how else > could it walk the stack)? > > These were just some random thoughts with the hope that they may be helpful. > > Regards, > Volker > > PS: by the way - the flame graphs look really impressive and it would > be really nice to have something like this for Java. > > > On Thu, Dec 4, 2014 at 11:55 PM, Brendan Gregg > wrote: >> G'Day, >> >> I've hacked hotspot to return the frame pointer, in part to see what this >> involves, and also to have a working prototype for analysis. Along with an >> agent to resolve symbols, this has allowed full stack profiling using Linux >> perf_events. The following flame graphs show the resulting profiles. >> >> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> Same thing, but this time disabling inlining, to show more frames: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >> >> As expected, performance is worse without inlining. You can compare the >> flame graphs side by side to see why. Less time spent doing work / I/O! >> >> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >> is my patch, and currently only works for x86-64. It removes RBP from the >> register pools, and inserts "mov(rbp, rsp)" into two function prologues. It >> is also unsupported: use at your own risk. I'm not a veteran hotspot >> engineer, so chances I messed something up are high. >> >> I'd love to be able to enable frame pointers in Oracle JDK, eg, with an >> -XX:+NoOmitFramePointer option. It could be put under >> -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long >> as we had some way to turn it on. If someone wants to include (improve, >> rewrite) my patch, please do. >> >> I don't have much perf data yet, but on the vert.x microbenchmark it looked >> like returning the frame pointer cost 2.6% performance. I hope that's >> somewhat worst-case for production workloads. (I was also able to recover >> the 2.6% by fine tuning other options, so were this a production change, I'd >> be hoping not to regress performance at all.) >> >> We've discussed this before >> (http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). >> The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) >> should work very well. The JVM can run as-is, full stacks can be generated >> on-demand, and symbols should always be correct. >> >> The frame pointer approach costs a little performance, and only shows >> partial stacks after inlining (unless you disable inlining, but that can >> cost >40% performance). There is the other issue Volker Simonis mentioned as >> well, where some stacks may not be profiled correctly. And, if you are >> unlucky, symbols can move during the profile, so any static perf-map-agent >> map will translate some incorrectly (I've considered developing a way to >> detect this, and highlight such frames as dubious.) >> >> At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this >> feature is going to be a tough sell, especially when the value of full stack >> profiling isn't widely understood. I personally think it might be a bit >> easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try >> the feature, then consider the better Solaris version after gaining solid >> experience on why it is so important. >> >> We recently blogged about the value of stack profiling and flame graphs, >> http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was >> for Node.js, which already has frame pointer support. >> >> If anyone wants to try generating these mixed mode CPU flame graphs >> themselves (in a test environment!), the first step is to compile OpenJDK 8 >> b132 with the previous patch, and get that running. Also install the >> packages for the "perf" command. The remaining steps would be something >> like: >> >> # git clone --depth=1 https://github.com/brendangregg/FlameGraph >> # git clone --depth=1 https://github.com/jrudolph/perf-map-agent >> # cd perf-map-agent >> # export JAVA_HOME=/... >> # cmake . >> # make >> # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 >> # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar >> net.virtualvoid.perf.AttachOnce `pgrep -n java` >> # perf script > ../FlameGraph/out.stacks >> # cd ../FlameGraph >> # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > >> out.svg >> >> Finally, if you are new to CPU flame graphs, see >> http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . >> >> Brendan From staffan.larsen at oracle.com Fri Dec 5 19:47:57 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 5 Dec 2014 20:47:57 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5481E8F9.1080307@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> Message-ID: <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> Utils.ITERATION_COUNT does not look like something that is usable outside these specific tests? Should it really be part of the test library? > On 5 dec 2014, at 18:18, Dmitrij Pochepko wrote: > > Adding hotspot-dev for wider audience. >> Hi, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: JMX- tests >> and >> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in testlibrary for JDK-8059613 >> >> It introduce a number of tests for segmented code cache, mostly testing thresholds, usage, >> memory notifications using respective MemoryPoolMXBean(s). >> There is also a small modification for testlibrary(8066440) used in tests. >> >> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >> >> Testing: manually, using fastdebug nightly build from 2014-12-02 >> >> Additional note: this patch assumes "https://bugs.openjdk.java.net/browse/JDK-8065134 - >> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. >> >> Thanks, >> Dmitrij > From brendan.d.gregg at gmail.com Fri Dec 5 19:57:09 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Fri, 5 Dec 2014 11:57:09 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg wrote: > G'Day, > > I've hacked hotspot to return the frame pointer, in part to see what this > involves, and also to have a working prototype for analysis. Along with an > agent to resolve symbols, this has allowed full stack profiling using Linux > perf_events. The following flame graphs show the resulting profiles. > > A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > Same thing, but this time disabling inlining, to show more frames: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg > > As expected, performance is worse without inlining. You can compare the > flame graphs side by side to see why. Less time spent doing work / I/O! > > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > is my patch, > [...] > In case there's problems with the patch URL, the patch is: --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad 2014-03-04 02:52:11.000000000 +0000 +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad 2014-11-08 01:10:49.686044933 +0000 @@ -166,10 +166,9 @@ // 3) reg_class stack_slots( /* one chunk of stack-based "registers" */ ) // -// Class for all pointer registers (including RSP) +// Class for all pointer registers (including RSP, excluding RBP) reg_class any_reg(RAX, RAX_H, RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -184,10 +183,9 @@ R14, R14_H, R15, R15_H); -// Class for all pointer registers except RSP +// Class for all pointer registers except RSP and RBP reg_class ptr_reg(RAX, RAX_H, RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -199,9 +197,8 @@ R13, R13_H, R14, R14_H); -// Class for all pointer registers except RAX and RSP +// Class for all pointer registers except RAX, RSP and RBP reg_class ptr_no_rax_reg(RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -226,9 +223,8 @@ R13, R13_H, R14, R14_H); -// Class for all pointer registers except RAX, RBX and RSP +// Class for all pointer registers except RAX, RBX, RSP and RBP reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -260,10 +256,9 @@ // Singleton class for TLS pointer reg_class ptr_r15_reg(R15, R15_H); -// Class for all long registers (except RSP) +// Class for all long registers (except RSP and RBP) reg_class long_reg(RAX, RAX_H, RDX, RDX_H, - RBP, RBP_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -275,9 +270,8 @@ R13, R13_H, R14, R14_H); -// Class for all long registers except RAX, RDX (and RSP) -reg_class long_no_rax_rdx_reg(RBP, RBP_H, - RDI, RDI_H, +// Class for all long registers except RAX, RDX (and RSP, RBP) +reg_class long_no_rax_rdx_reg(RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, RBX, RBX_H, @@ -288,9 +282,8 @@ R13, R13_H, R14, R14_H); -// Class for all long registers except RCX (and RSP) -reg_class long_no_rcx_reg(RBP, RBP_H, - RDI, RDI_H, +// Class for all long registers except RCX (and RSP, RBP) +reg_class long_no_rcx_reg(RDI, RDI_H, RSI, RSI_H, RAX, RAX_H, RDX, RDX_H, @@ -302,9 +295,8 @@ R13, R13_H, R14, R14_H); -// Class for all long registers except RAX (and RSP) -reg_class long_no_rax_reg(RBP, RBP_H, - RDX, RDX_H, +// Class for all long registers except RAX (and RSP, RBP) +reg_class long_no_rax_reg(RDX, RDX_H, RDI, RDI_H, RSI, RSI_H, RCX, RCX_H, @@ -325,10 +317,9 @@ // Singleton class for RDX long register reg_class long_rdx_reg(RDX, RDX_H); -// Class for all int registers (except RSP) +// Class for all int registers (except RSP and RBP) reg_class int_reg(RAX, RDX, - RBP, RDI, RSI, RCX, @@ -340,10 +331,9 @@ R13, R14); -// Class for all int registers except RCX (and RSP) +// Class for all int registers except RCX (and RSP, RBP) reg_class int_no_rcx_reg(RAX, RDX, - RBP, RDI, RSI, RBX, @@ -355,8 +345,7 @@ R14); // Class for all int registers except RAX, RDX (and RSP) -reg_class int_no_rax_rdx_reg(RBP, - RDI, +reg_class int_no_rax_rdx_reg(RDI, RSI, RCX, RBX, @@ -718,6 +707,7 @@ st->print("# stack bang"); st->print("\n\t"); st->print("pushq rbp\t# Save rbp"); + // BDG consider: st->print("movq rbp, rsp\t# "); if (framesize) { st->print("\n\t"); st->print("subq rsp, #%d\t# Create frame",framesize); --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-03-04 02:52:11.000000000 +0000 +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-11-07 23:57:11.589593723 +0000 @@ -5236,6 +5236,7 @@ // We always push rbp, so that on return to interpreter rbp, will be // restored correctly and we can correct the stack. push(rbp); + mov(rbp, rsp); // Remove word for ebp framesize -= wordSize; --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp 2014-03-04 02:52:10.000000000 +0000 +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp 2014-11-07 23:57:21.933257882 +0000 @@ -358,6 +358,7 @@ generate_stack_overflow_check(frame_size_in_bytes); push(rbp); + mov(rbp, rsp); #ifdef TIERED // c2 leaves fpu stack dirty. Clean it on entry if (UseSSE < 2 ) { Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Fri Dec 5 20:13:35 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 05 Dec 2014 23:13:35 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> Message-ID: <548211EF.3050402@oracle.com> During internal team review, Igor.Igntatyev asked to move it to Utils, perhaps he has future plans for this. Igor? Thanks, Dmitrij > Utils.ITERATION_COUNT does not look like something that is usable outside these specific tests? Should it really be part of the test library? > >> On 5 dec 2014, at 18:18, Dmitrij Pochepko wrote: >> >> Adding hotspot-dev for wider audience. >>> Hi, >>> >>> Please review changes for >>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: JMX- tests >>> and >>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in testlibrary for JDK-8059613 >>> >>> It introduce a number of tests for segmented code cache, mostly testing thresholds, usage, >>> memory notifications using respective MemoryPoolMXBean(s). >>> There is also a small modification for testlibrary(8066440) used in tests. >>> >>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>> >>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>> >>> Additional note: this patch assumes "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. >>> >>> Thanks, >>> Dmitrij From pavel.punegov at oracle.com Fri Dec 5 20:17:02 2014 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Fri, 05 Dec 2014 23:17:02 +0300 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <547C2654.8030808@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> Message-ID: <548212BE.7010500@oracle.com> Hi Tobias, see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ I added TransitionsTestExecutor.java class that checks if TieredCompilation is available in the VM it was started with. Then it starts test for CompilatonPolicyChoice 2 and 3. On 01.12.2014 11:27, Tobias Hartmann wrote: > Hi Pavel, > > the tests fail with a client VM: > >> Error occurred during initialization of VM >> Incompatible compilation policy selected > Please execute them on JPRT to make sure they work on all platforms. > > Best, > Tobias > > On 28.11.2014 13:27, Pavel Punegov wrote: >> Hi all, >> >> please review new tests developed as a part of the test task: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >> >> Description: >> There are two tests to verify level transitions in Tiered Compilation: >> 1. LevelTransitionTest verifies that in case of no load on compiler queues test >> methods go through common transition patterns: >> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >> trivial methods, and 0 -> 4 after deoptimization. >> Test provokes compilations of the method and checks that all transitions are >> correct for CompilationPolicyChoice=2 and 3. >> >> 2. ConstantGettersTransitions is a test adapted from the test Tobias used for >> 8056071 (see [*] for details). It checks that all constant getters are always >> compiled with C1. >> >> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >> >> Testing: done locally >> -- Thanks, Pavel Punegov From cnewland at chrisnewland.com Fri Dec 5 21:09:01 2014 From: cnewland at chrisnewland.com (Chris Newland) Date: Fri, 5 Dec 2014 21:09:01 -0000 Subject: %ld instead of %d for LogCompilation counts? Message-ID: Hi, I've encountered some LogCompilation counters in 8u25 that are getting printed in exponential form in hotspot.log : This is harder to parse and loses accuracy because %d is used as a formatter in hotspot/src/share/vm/opto/parse2.cpp: if (C->log() != NULL) { C->log()->elem("branch target_bci='%d' taken='%d' not_taken='%d'", iter().get_dest(), taken, not_taken); } Would it be possible to modify some or all of the LogCompilation format strings to use %ld so that large integers can be printed without exponents? I don't mind going through the OpenJDK motions to submit this as a patch if it's a sensible idea. Thanks, Chris From igor.ignatyev at oracle.com Fri Dec 5 21:28:30 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 06 Dec 2014 00:28:30 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <548211EF.3050402@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> Message-ID: <5482237E.6010201@oracle.com> Hi Staffan, Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. Thanks Igor On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: > During internal team review, Igor.Igntatyev asked to move it to Utils, > perhaps he has future plans for this. > Igor? > > Thanks, > Dmitrij >> Utils.ITERATION_COUNT does not look like something that is usable >> outside these specific tests? Should it really be part of the test >> library? >> >>> On 5 dec 2014, at 18:18, Dmitrij >>> Pochepko wrote: >>> >>> Adding hotspot-dev for wider audience. >>>> Hi, >>>> >>>> Please review changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>> Test task: JMX- tests >>>> and >>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>> in testlibrary for JDK-8059613 >>>> >>>> It introduce a number of tests for segmented code cache, mostly >>>> testing thresholds, usage, >>>> memory notifications using respective MemoryPoolMXBean(s). >>>> There is also a small modification for testlibrary(8066440) used in >>>> tests. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>> >>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>> >>>> Additional note: this patch assumes >>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>> is fixed. >>>> >>>> Thanks, >>>> Dmitrij > From volker.simonis at gmail.com Fri Dec 5 22:50:52 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 5 Dec 2014 23:50:52 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: Yes, that's clear. I didn't wanted to propose using "jstack -F" directly. I just wanted to say that it's possible for an external tool to get a "reasonable good" stack trace out of a JVM process at any time and "jstack -F" can be taken as a boilerplate of how to do that. That said, I still don't know how perf creates stack traces. Does it attach to the process with ptrace or how else does it inspect the stacks after a performance counter event? On Fri, Dec 5, 2014 at 8:34 PM, Staffan Larsen wrote: > Just to note that the implementation of ?jstack -F? is not at all suitable for profiling since has a very high overhead (it attaches a debugger to the process). > > /Staffan > >> On 5 dec 2014, at 20:22, Volker Simonis wrote: >> >> Hi Brendan, >> >> I'm still not understanding who is taking the actual stack traces (let >> alone the symbols) in your examples. Is this done by 'perf' itself >> based only on the frame pointer? >> >> As I wrote before, this is pretty hard to get right for a JVM, but >> there are good approximations. Have you looked at the 'jstack' tool >> which is part of the JDK? If you run it on a Java process, it will >> give you exact stack traces with full inlining information. However >> this only works at safepoints so it is probably not suitable for >> profiling with performance counters. But you can also use 'jstack -F >> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >> of the time even with inlined Java frames. This is probably the best >> you can get when interrupting a running JVM at an arbitrary point in >> time. As you mentioned in one of your blogs, the VM can be in the >> C-Library or even in the kernel at that time which don't preserve the >> frame pointer either. So it will be already hard to even walk up to >> the first Java frame. >> >> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >> your purpose, you can implement something similar in 'perf' or a >> helper library of 'perf' and be happy (I don't actually know how perf >> takes stack traces but I suppose there may some kind of callback >> mechanism for walking unknown frames). This is actually not so hard. >> I've recently implemented a "print_native_stack()" function within >> hotspot itself (you can call it for example from gdb during debugging >> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >> Maye you could call this functions directly from 'perf' if perf >> attaches with ptrace to the process (I assume it does or how else >> could it walk the stack)? >> >> These were just some random thoughts with the hope that they may be helpful. >> >> Regards, >> Volker >> >> PS: by the way - the flame graphs look really impressive and it would >> be really nice to have something like this for Java. >> >> >> On Thu, Dec 4, 2014 at 11:55 PM, Brendan Gregg >> wrote: >>> G'Day, >>> >>> I've hacked hotspot to return the frame pointer, in part to see what this >>> involves, and also to have a working prototype for analysis. Along with an >>> agent to resolve symbols, this has allowed full stack profiling using Linux >>> perf_events. The following flame graphs show the resulting profiles. >>> >>> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >>> >>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >>> >>> Same thing, but this time disabling inlining, to show more frames: >>> >>> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >>> >>> As expected, performance is worse without inlining. You can compare the >>> flame graphs side by side to see why. Less time spent doing work / I/O! >>> >>> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >>> is my patch, and currently only works for x86-64. It removes RBP from the >>> register pools, and inserts "mov(rbp, rsp)" into two function prologues. It >>> is also unsupported: use at your own risk. I'm not a veteran hotspot >>> engineer, so chances I messed something up are high. >>> >>> I'd love to be able to enable frame pointers in Oracle JDK, eg, with an >>> -XX:+NoOmitFramePointer option. It could be put under >>> -XX:+UnlockDiagnosticVMOptions or XX:+UnlockExperimentalVMOptions. So long >>> as we had some way to turn it on. If someone wants to include (improve, >>> rewrite) my patch, please do. >>> >>> I don't have much perf data yet, but on the vert.x microbenchmark it looked >>> like returning the frame pointer cost 2.6% performance. I hope that's >>> somewhat worst-case for production workloads. (I was also able to recover >>> the 2.6% by fine tuning other options, so were this a production change, I'd >>> be hoping not to regress performance at all.) >>> >>> We've discussed this before >>> (http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-October/thread.html#15939). >>> The Solaris-assisted approach that Serguei Spitsyn described (JDK-6617153) >>> should work very well. The JVM can run as-is, full stacks can be generated >>> on-demand, and symbols should always be correct. >>> >>> The frame pointer approach costs a little performance, and only shows >>> partial stacks after inlining (unless you disable inlining, but that can >>> cost >40% performance). There is the other issue Volker Simonis mentioned as >>> well, where some stacks may not be profiled correctly. And, if you are >>> unlucky, symbols can move during the profile, so any static perf-map-agent >>> map will translate some incorrectly (I've considered developing a way to >>> detect this, and highlight such frames as dubious.) >>> >>> At Netflix we are mostly Java on Linux. Switching to Oracle Solaris for this >>> feature is going to be a tough sell, especially when the value of full stack >>> profiling isn't widely understood. I personally think it might be a bit >>> easier if a -XX:+NoOmitFramePointer option existed, so Linux users can try >>> the feature, then consider the better Solaris version after gaining solid >>> experience on why it is so important. >>> >>> We recently blogged about the value of stack profiling and flame graphs, >>> http://techblog.netflix.com/2014/11/nodejs-in-flames.html, although this was >>> for Node.js, which already has frame pointer support. >>> >>> If anyone wants to try generating these mixed mode CPU flame graphs >>> themselves (in a test environment!), the first step is to compile OpenJDK 8 >>> b132 with the previous patch, and get that running. Also install the >>> packages for the "perf" command. The remaining steps would be something >>> like: >>> >>> # git clone --depth=1 https://github.com/brendangregg/FlameGraph >>> # git clone --depth=1 https://github.com/jrudolph/perf-map-agent >>> # cd perf-map-agent >>> # export JAVA_HOME=/... >>> # cmake . >>> # make >>> # perf record -F 99 -p `pgrep -n java` -g -- sleep 30 >>> # java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar >>> net.virtualvoid.perf.AttachOnce `pgrep -n java` >>> # perf script > ../FlameGraph/out.stacks >>> # cd ../FlameGraph >>> # ./stackcollapse-perf.pl < out.stacks | ./flamegraph.pl --color=java > >>> out.svg >>> >>> Finally, if you are new to CPU flame graphs, see >>> http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html . >>> >>> Brendan > From brendan.d.gregg at gmail.com Fri Dec 5 23:09:46 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Fri, 5 Dec 2014 15:09:46 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: G'Day Volker, On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis wrote: > Hi Brendan, > > I'm still not understanding who is taking the actual stack traces (let > alone the symbols) in your examples. Is this done by 'perf' itself > based only on the frame pointer? perf is walking the frame pointers. A JVMTI agent, perf-map-agent, is providing a map file for symbol translation under /tmp/perf-PID.map. Linux perf already hunts for such a file when doing symbol translation. > > As I wrote before, this is pretty hard to get right for a JVM, but > there are good approximations. Have you looked at the 'jstack' tool > which is part of the JDK? If you run it on a Java process, it will > give you exact stack traces with full inlining information. However > this only works at safepoints so it is probably not suitable for > profiling with performance counters. Right, jstack works, and I get full correct stacks. I do really want to take stacks at any moment: not just CPU samples, but when tracing kernel TCP events, or PMC cache miss profiling, etc. perf can already do many advanced tracing and profiling activities. I just needed the Java stacks for context. > But you can also use 'jstack -F > -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most > of the time even with inlined Java frames. This is probably the best > you can get when interrupting a running JVM at an arbitrary point in > time. As you mentioned in one of your blogs, the VM can be in the > C-Library or even in the kernel at that time which don't preserve the > frame pointer either. So it will be already hard to even walk up to > the first Java frame. Well, the JVMs I'm looking at are already built with -fno-omit-frame-pointer (which is good). I edited hotspot to preserve it as well. Here's before I changed hotspot: http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg Yes, most stacks are clearly broken. After changing hotspot: http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg It's looking pretty good. If you look carefully on the far left and right, there are 0.8% stacks in read() and write() directly from java, which may well be broken (unless a java thread is calling these directly; there could also be some gcc inlining going on). Even if they are broken, I can see 98% of my profile. Plus, I'd be interested to know what exactly is reusing the frame pointer, so we could fix that too. The Java stacks themselves are also about a third as deep as they should be, due to inlining. > > But nevertheless, if the output of 'jstack -F -m' is "good enough" for > your purpose, you can implement something similar in 'perf' or a > helper library of 'perf' and be happy (I don't actually know how perf > takes stack traces but I suppose there may some kind of callback > mechanism for walking unknown frames). This is actually not so hard. > I've recently implemented a "print_native_stack()" function within > hotspot itself (you can call it for example from gdb during debugging > - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). > Maye you could call this functions directly from 'perf' if perf > attaches with ptrace to the process (I assume it does or how else > could it walk the stack)? An OS-cooperative stack walker would be great, and I think the hotspot team is already doing this for Oracle Solaris. Thanks for the code too, this is pretty interesting. jstack -F -m eats 0.5s of CPU for me, so it would need work to make this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary kernel functions or tracepoints and get Java context from them, too. Eg, TCP functions, memory allocation, disk I/O, etc. > > These were just some random thoughts with the hope that they may be helpful. Yes, thanks! Brendan From vladimir.kozlov at oracle.com Fri Dec 5 23:34:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Dec 2014 15:34:19 -0800 Subject: %ld instead of %d for LogCompilation counts? In-Reply-To: References: Message-ID: <548240FB.2030804@oracle.com> Hi, The output was produced by following lines: C->log()->elem("branch target_bci='%d' taken='%d' not_taken='%d' cnt='%g' prob='%s'", iter().get_dest(), taken, not_taken, cnt, prob_str); 'cnt' is declared as 'float' and defined as: cnt = (taken + not_taken) / FreqCountInvocations; I think it is artifact from long time ago when FreqCountInvocations was > 1. And to avoid integer overflow, so we want to keep variable as float. But I am fine to change log output to long by converting it to (jlong)cnt and using JLONG_FORMAT format. Do you know other places where we use %g for counters? Thanks, Vladimir On 12/5/14 1:09 PM, Chris Newland wrote: > Hi, > > I've encountered some LogCompilation counters in 8u25 that are getting > printed in exponential form in hotspot.log : > > cnt='2.38658e+06' prob='0.00990148'/> > > This is harder to parse and loses accuracy because %d is used as a > formatter in hotspot/src/share/vm/opto/parse2.cpp: > > if (C->log() != NULL) { > C->log()->elem("branch target_bci='%d' taken='%d' not_taken='%d'", > iter().get_dest(), taken, not_taken); > } > > Would it be possible to modify some or all of the LogCompilation format > strings to use %ld so that large integers can be printed without > exponents? > > I don't mind going through the OpenJDK motions to submit this as a patch > if it's a sensible idea. > > Thanks, > > Chris > From john.r.rose at oracle.com Fri Dec 5 23:54:55 2014 From: john.r.rose at oracle.com (John Rose) Date: Fri, 5 Dec 2014 15:54:55 -0800 Subject: %ld instead of %d for LogCompilation counts? In-Reply-To: <548240FB.2030804@oracle.com> References: <548240FB.2030804@oracle.com> Message-ID: <9DAF830D-6CBC-4BEC-AC78-CAD438800062@oracle.com> On Dec 5, 2014, at 3:34 PM, Vladimir Kozlov wrote: > > But I am fine to change log output to long by converting it to (jlong)cnt and using JLONG_FORMAT format. A problem with converting to jlong is that we don't have a good notation for the format string of a jlong; it differs across platforms (%lld vs. %I64d). If we want to avoid an exponent, %f should work better, because it doesn't require a possibly-lossy value conversion. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Sat Dec 6 00:18:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Dec 2014 16:18:54 -0800 Subject: %ld instead of %d for LogCompilation counts? In-Reply-To: <9DAF830D-6CBC-4BEC-AC78-CAD438800062@oracle.com> References: <548240FB.2030804@oracle.com> <9DAF830D-6CBC-4BEC-AC78-CAD438800062@oracle.com> Message-ID: <54824B6E.7050900@oracle.com> On 12/5/14 3:54 PM, John Rose wrote: > On Dec 5, 2014, at 3:34 PM, Vladimir Kozlov > wrote: >> >> But I am fine to change log output to long by converting it to >> (jlong)cnt and using JLONG_FORMAT format. > > A problem with converting to jlong is that we don't have a good notation > for the format string of a jlong; it differs across platforms (%lld vs. > %I64d). If we want to avoid an exponent, %f should work better, because > it doesn't require a possibly-lossy value conversion. Yes, %f works too. For jlong we have special JLONG_FORMAT format as I pointed and I assume it should work on all platforms. Vladimir > > ? John From david.holmes at oracle.com Mon Dec 8 02:09:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Dec 2014 12:09:51 +1000 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <5481A724.1070107@oracle.com> References: <5481A724.1070107@oracle.com> Message-ID: <5485086F.3090007@oracle.com> On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote: > Hi all, > > please review this new small patch > > bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 > webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ > > Problem: > Need WhiteBox::allocateCodeBlob(long, int), currently only > WhiteBox::allocateCodeBlob(int, int) exist. > > I change previous fix to this new patch because this conversation [*] > > Solution: > public long allocateCodeBlob(long size, int type) { > return allocateCodeBlob((int) size, type); > } I still think this is a bad idea. The callsite needs to know, and show, that the size it is passing will be truncated. And I still don't see a connection between MX bean memory sizes and allocateCodeBlob. David > Test: jprt > > [*] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html > > > Thanks, > Tatiana From igor.ignatyev at oracle.com Mon Dec 8 06:27:35 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 08 Dec 2014 09:27:35 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <5485086F.3090007@oracle.com> References: <5481A724.1070107@oracle.com> <5485086F.3090007@oracle.com> Message-ID: <548544D7.3030509@oracle.com> David, initially, we wanted to change WB::allocateCodeBlob to take jlong w/o truncating. for that we make CodeCache::allocate to take size_t instead of int, however it leads to too many changes in the product. And we were sure that all these changes are safe, so it was decided to make changes as smaller as possible. what do you think about the version w/ check? smth like: > public long allocateCodeBlob(long size, int type) { > int i = (int) size; > if ((long)i != size) { throw new IAE(); } > return allocateCodeBlob(i, type); > } 8065134 was filled by Dmitrij Pochepko, and it's needed for his tests JMX tests for SegmentedCodeCache[1]. so I think he can enlighten us about connection. Dima, could you please explain connection between beans and allocateCodeBlob? [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016336.html Thanks, Igor On 12/08/2014 05:09 AM, David Holmes wrote: > On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote: >> Hi all, >> >> please review this new small patch >> >> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >> webrev: >> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ >> >> Problem: >> Need WhiteBox::allocateCodeBlob(long, int), currently only >> WhiteBox::allocateCodeBlob(int, int) exist. >> >> I change previous fix to this new patch because this conversation [*] >> >> Solution: >> public long allocateCodeBlob(long size, int type) { >> return allocateCodeBlob((int) size, type); >> } > > I still think this is a bad idea. The callsite needs to know, and show, > that the size it is passing will be truncated. And I still don't see a > connection between MX bean memory sizes and allocateCodeBlob. > > David > > >> Test: jprt >> >> [*] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html >> >> >> >> Thanks, >> Tatiana From staffan.larsen at oracle.com Mon Dec 8 06:59:22 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Dec 2014 07:59:22 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5482237E.6010201@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> Message-ID: I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. /Staffan > On 5 dec 2014, at 22:28, Igor Ignatyev wrote: > > Hi Staffan, > > Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. > > Thanks > Igor > > On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >> During internal team review, Igor.Igntatyev asked to move it to Utils, >> perhaps he has future plans for this. >> Igor? >> >> Thanks, >> Dmitrij >>> Utils.ITERATION_COUNT does not look like something that is usable >>> outside these specific tests? Should it really be part of the test >>> library? >>> >>>> On 5 dec 2014, at 18:18, Dmitrij >>>> Pochepko wrote: >>>> >>>> Adding hotspot-dev for wider audience. >>>>> Hi, >>>>> >>>>> Please review changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>> Test task: JMX- tests >>>>> and >>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>> in testlibrary for JDK-8059613 >>>>> >>>>> It introduce a number of tests for segmented code cache, mostly >>>>> testing thresholds, usage, >>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>> There is also a small modification for testlibrary(8066440) used in >>>>> tests. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>> >>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>> >>>>> Additional note: this patch assumes >>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>> is fixed. >>>>> >>>>> Thanks, >>>>> Dmitrij >> From david.holmes at oracle.com Mon Dec 8 07:00:04 2014 From: david.holmes at oracle.com (David Holmes) Date: Mon, 08 Dec 2014 17:00:04 +1000 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <548544D7.3030509@oracle.com> References: <5481A724.1070107@oracle.com> <5485086F.3090007@oracle.com> <548544D7.3030509@oracle.com> Message-ID: <54854C74.8010308@oracle.com> Hi Igor, On 8/12/2014 4:27 PM, Igor Ignatyev wrote: > David, > > initially, we wanted to change WB::allocateCodeBlob to take jlong w/o > truncating. for that we make CodeCache::allocate to take size_t instead > of int, however it leads to too many changes in the product. And we were > sure that all these changes are safe, so it was decided to make changes > as smaller as possible. > > what do you think about the version w/ check? smth like: >> public long allocateCodeBlob(long size, int type) { >> int i = (int) size; >> if ((long)i != size) { throw new IAE(); } >> return allocateCodeBlob(i, type); >> } Yes that would be more acceptable. I've looked at the other tests and see how the use of uint/x forces us to use Java longs. But still seems to me that the tests are where we should be concerned that we haven't overflowed the int. But I can live with the above safety check. Thanks, David > 8065134 was filled by Dmitrij Pochepko, and it's needed for his tests > JMX tests for SegmentedCodeCache[1]. so I think he can enlighten us > about connection. > > Dima, > could you please explain connection between beans and allocateCodeBlob? > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016336.html > > > Thanks, > Igor > > On 12/08/2014 05:09 AM, David Holmes wrote: >> On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote: >>> Hi all, >>> >>> please review this new small patch >>> >>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >>> webrev: >>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ >>> >>> Problem: >>> Need WhiteBox::allocateCodeBlob(long, int), currently only >>> WhiteBox::allocateCodeBlob(int, int) exist. >>> >>> I change previous fix to this new patch because this conversation [*] >>> >>> Solution: >>> public long allocateCodeBlob(long size, int type) { >>> return allocateCodeBlob((int) size, type); >>> } >> >> I still think this is a bad idea. The callsite needs to know, and show, >> that the size it is passing will be truncated. And I still don't see a >> connection between MX bean memory sizes and allocateCodeBlob. >> >> David >> >> >>> Test: jprt >>> >>> [*] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html >>> >>> >>> >>> >>> Thanks, >>> Tatiana From tobias.hartmann at oracle.com Mon Dec 8 07:30:09 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 08 Dec 2014 08:30:09 +0100 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <548212BE.7010500@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> <548212BE.7010500@oracle.com> Message-ID: <54855381.8030002@oracle.com> Hi Pavel, looks good (not a reviewer). Best, Tobias On 05.12.2014 21:17, Pavel Punegov wrote: > Hi Tobias, > > see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ > > I added TransitionsTestExecutor.java class that checks if TieredCompilation is > available in the VM it was started with. Then it starts test for > CompilatonPolicyChoice 2 and 3. > > On 01.12.2014 11:27, Tobias Hartmann wrote: >> Hi Pavel, >> >> the tests fail with a client VM: >> >>> Error occurred during initialization of VM >>> Incompatible compilation policy selected >> Please execute them on JPRT to make sure they work on all platforms. >> >> Best, >> Tobias >> >> On 28.11.2014 13:27, Pavel Punegov wrote: >>> Hi all, >>> >>> please review new tests developed as a part of the test task: >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >>> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >>> >>> Description: >>> There are two tests to verify level transitions in Tiered Compilation: >>> 1. LevelTransitionTest verifies that in case of no load on compiler queues test >>> methods go through common transition patterns: >>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >>> trivial methods, and 0 -> 4 after deoptimization. >>> Test provokes compilations of the method and checks that all transitions are >>> correct for CompilationPolicyChoice=2 and 3. >>> >>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used for >>> 8056071 (see [*] for details). It checks that all constant getters are always >>> compiled with C1. >>> >>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >>> >>> Testing: done locally >>> > From tobias.hartmann at oracle.com Mon Dec 8 08:37:48 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 08 Dec 2014 09:37:48 +0100 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <5481E60D.9020309@oracle.com> References: <5481E60D.9020309@oracle.com> Message-ID: <5485635C.6020501@oracle.com> Hi Filipp, the actual size of a code heap is affected by alignment and therefore may be different to the size set via the command line. For example, on Sparc we have to make sure that the code heaps are large page (4MB) aligned to reduce the number of ITLB misses (will be introduced with [1]). Maybe we should check if the actual size of the code heap is within boundaries, i.e., within the specified size +- (large) page size. Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8064940 On 05.12.2014 18:06, Filipp Zhinkin wrote: > Hi, > > please take a look at CLI tests for segmented code cache (JDK-8059623). > > There are three new tests: > compiler/codecache/cli/ > codeheapsize/TestCodeHeapSizeOptions > printcodecache/TestPrintCodeCacheOption > TestSegmentedCodeCacheOption > > All tests consist of several test cases aimed to verify different aspects > of options' processing. > > These tests partially overlapped with c/c/CheckSegmentedCodeCache test, > but add additional value - these tests actually check final values > of tested options and verifies PrintCodeCache output. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ > Testing: manual & automated > > This change depends on: > https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI tests > error reporting > https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in testlibrary > for JDK-8059613 > > Thanks > Filipp. From roland.westrelin at oracle.com Mon Dec 8 11:45:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 8 Dec 2014 12:45:59 +0100 Subject: RFR(XS): 8066775 opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 Message-ID: <8BE309E3-98B6-4ADC-B225-99E372C46BD6@oracle.com> http://cr.openjdk.java.net/~roland/8066775/webrev.00/ Another follow up from "8054478 C2: Incorrectly compiled char[] array access crashes JVM? The part of the graph where the CastII becomes dead and the CastII's control is an IfTrue projection with input top. Roland. From cnewland at chrisnewland.com Mon Dec 8 11:56:06 2014 From: cnewland at chrisnewland.com (Chris Newland) Date: Mon, 8 Dec 2014 11:56:06 -0000 Subject: %ld instead of %d for LogCompilation counts? In-Reply-To: <548240FB.2030804@oracle.com> References: <548240FB.2030804@oracle.com> Message-ID: Hi Vladimir, The believe the only other LogCompilation output where %g is used for a cardinal number is this one? share/vm/opto/parse1.cpp:443: log->begin_head("parse method='%d' uses='%g'", log->identify(parse_method), expected_uses); Kind regards, Chris On Fri, December 5, 2014 23:34, Vladimir Kozlov wrote: > Hi, > > > The output was produced by following lines: > > > C->log()->elem("branch target_bci='%d' taken='%d' not_taken='%d' > cnt='%g' prob='%s'", iter().get_dest(), taken, not_taken, cnt, prob_str); > > 'cnt' is declared as 'float' and defined as: > > > cnt = (taken + not_taken) / FreqCountInvocations; > > I think it is artifact from long time ago when FreqCountInvocations was > >> 1. And to avoid integer overflow, so we want to keep variable as float. >> > > But I am fine to change log output to long by converting it to > (jlong)cnt and using JLONG_FORMAT format. > > > Do you know other places where we use %g for counters? > > > Thanks, > Vladimir > > > On 12/5/14 1:09 PM, Chris Newland wrote: > >> Hi, >> >> >> I've encountered some LogCompilation counters in 8u25 that are getting >> printed in exponential form in hotspot.log : >> >> > cnt='2.38658e+06' prob='0.00990148'/> >> >> This is harder to parse and loses accuracy because %d is used as a >> formatter in hotspot/src/share/vm/opto/parse2.cpp: >> >> if (C->log() != NULL) { C->log()->elem("branch target_bci='%d' >> taken='%d' not_taken='%d'", iter().get_dest(), taken, not_taken); } >> >> >> Would it be possible to modify some or all of the LogCompilation format >> strings to use %ld so that large integers can be printed without >> exponents? >> >> I don't mind going through the OpenJDK motions to submit this as a >> patch if it's a sensible idea. >> >> Thanks, >> >> >> Chris >> >> > From filipp.zhinkin at oracle.com Mon Dec 8 12:25:38 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 08 Dec 2014 16:25:38 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <5485635C.6020501@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> Message-ID: <548598C2.30808@oracle.com> Hi Tobias, thank you for suggestion. Yes, I think we should take code heap size alignment into account. What alignment policy you're going to implement for 8064940? Maybe instead of checking that values are in (value - page_size, value + page_size) interval we should just check that all values were aligned up to page_size? Thanks, Filipp. On 12/08/2014 12:37 PM, Tobias Hartmann wrote: > Hi Filipp, > > the actual size of a code heap is affected by alignment and therefore may be > different to the size set via the command line. For example, on Sparc we have to > make sure that the code heaps are large page (4MB) aligned to reduce the number > of ITLB misses (will be introduced with [1]). > > Maybe we should check if the actual size of the code heap is within boundaries, > i.e., within the specified size +- (large) page size. > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8064940 > > On 05.12.2014 18:06, Filipp Zhinkin wrote: >> Hi, >> >> please take a look at CLI tests for segmented code cache (JDK-8059623). >> >> There are three new tests: >> compiler/codecache/cli/ >> codeheapsize/TestCodeHeapSizeOptions >> printcodecache/TestPrintCodeCacheOption >> TestSegmentedCodeCacheOption >> >> All tests consist of several test cases aimed to verify different aspects >> of options' processing. >> >> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >> but add additional value - these tests actually check final values >> of tested options and verifies PrintCodeCache output. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >> Testing: manual & automated >> >> This change depends on: >> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI tests >> error reporting >> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in testlibrary >> for JDK-8059613 >> >> Thanks >> Filipp. From dmitrij.pochepko at oracle.com Mon Dec 8 13:02:22 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 08 Dec 2014 16:02:22 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <548544D7.3030509@oracle.com> References: <5481A724.1070107@oracle.com> <5485086F.3090007@oracle.com> <548544D7.3030509@oracle.com> Message-ID: <5485A15E.7030801@oracle.com> Hi, connection is simple: MemoryPoolMXBean::getUsage()::getUsed() returns long. Also, -XX:CodeCacheSegmentSize and -XX:CodeCacheMinBlockLength returned as long, so, most operation uses long, and basically the only call using int is WB::allocateCodeBlob. So, that's more logical to have long parameter in allocateCodeBlob. An alternative is to make some surrogate with basically the same code in tests, while it might be needed in another tests, so, it seems like moving it to WhiteBox would be more logical. Thanks, Dmitrij > David, > > initially, we wanted to change WB::allocateCodeBlob to take jlong w/o > truncating. for that we make CodeCache::allocate to take size_t > instead of int, however it leads to too many changes in the product. > And we were sure that all these changes are safe, so it was decided to > make changes as smaller as possible. > > what do you think about the version w/ check? smth like: >> public long allocateCodeBlob(long size, int type) { >> int i = (int) size; >> if ((long)i != size) { throw new IAE(); } >> return allocateCodeBlob(i, type); >> } > > 8065134 was filled by Dmitrij Pochepko, and it's needed for his tests > JMX tests for SegmentedCodeCache[1]. so I think he can enlighten us > about connection. > > Dima, > could you please explain connection between beans and allocateCodeBlob? > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016336.html > > Thanks, > Igor > > On 12/08/2014 05:09 AM, David Holmes wrote: >> On 5/12/2014 10:37 PM, Tatiana Pivovarova wrote: >>> Hi all, >>> >>> please review this new small patch >>> >>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >>> webrev: >>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ >>> >>> Problem: >>> Need WhiteBox::allocateCodeBlob(long, int), currently only >>> WhiteBox::allocateCodeBlob(int, int) exist. >>> >>> I change previous fix to this new patch because this conversation [*] >>> >>> Solution: >>> public long allocateCodeBlob(long size, int type) { >>> return allocateCodeBlob((int) size, type); >>> } >> >> I still think this is a bad idea. The callsite needs to know, and show, >> that the size it is passing will be truncated. And I still don't see a >> connection between MX bean memory sizes and allocateCodeBlob. >> >> David >> >> >>> Test: jprt >>> >>> [*] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016316.html >>> >>> >>> >>> >>> Thanks, >>> Tatiana From roland.westrelin at oracle.com Mon Dec 8 13:30:52 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 8 Dec 2014 14:30:52 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> Message-ID: <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> Hi John, Thanks for the suggestions. They sound very reasonable to me. Here is a new webrev: http://cr.openjdk.java.net/~roland/8066103/webrev.03/ In the patch below: > Or better yet a purely local cutout. (This sketch has a bad goto; the value of 'prev_dom' carried by the goto is what I called 'most_recent_prev_check' above.) > > diff --git a/src/share/vm/opto/ifnode.cpp b/src/share/vm/opto/ifnode.cpp > --- a/src/share/vm/opto/ifnode.cpp > +++ b/src/share/vm/opto/ifnode.cpp > @@ -876,6 +876,7 @@ > // Low and high offsets seen so far > jint off_lo = offset1; > jint off_hi = offset1; > + int nb_checks = 0; > > // Scan for the top 2 checks and collect range of offsets > for( int dist = 0; dist < 999; dist++ ) { // Range-Check scan limit > @@ -890,6 +891,15 @@ > // the same array bounds. > if( flip2 == flip1 && range2 == range1 && index2 == index1 && > dom->outcnt() == 2 ) { > + if (nb_checks == 0 && dom->in(1) == in(1)) { > + // Found an immediately dominating test at the same offset. > + // This kind of back-to-back test can be eliminated locally, > + // and there is no need to search further for dominating tests. > + assert(offset2 == offset1, ""); > + prev_dom = dom; > + goto got_prev_dom; // FIXME: unstructured control flow > + } > + nb_checks++; > // Gather expanded bounds > off_lo = MIN2(off_lo,offset2); > off_hi = MAX2(off_hi,offset2); > @@ -985,6 +995,7 @@ > > } // End of Else scan for an equivalent test > > + got_prev_dom: // FIXME: unstructured control flow > // Hit! Remove this IF > #ifndef PRODUCT > if( TraceIterativeGVN ) { I don?t think you need prev_dom. prev_dom is the projection, dom is the If node. IfNode::dominated_by needs the projection as input. Roland. From tatiana.pivovarova at oracle.com Mon Dec 8 13:43:51 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 08 Dec 2014 16:43:51 +0300 Subject: RFR(XXS): 8066250: compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java fails product In-Reply-To: <54817443.60901@oracle.com> References: <54808E04.9090305@oracle.com> <54817443.60901@oracle.com> Message-ID: <5485AB17.7050709@oracle.com> Hi Tobias, Thanks for review! Tatiana On 12/05/2014 12:00 PM, Tobias Hartmann wrote: > Hi, > > looks good. Thanks for fixing this! > > Best, > Tobias > > On 04.12.2014 17:38, Tatiana Pivovarova wrote: >> Hi all, >> >> please review this small patch >> >> bugid: https://bugs.openjdk.java.net/browse/JDK-8066250 >> webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/webrev.00/ >> >> Problem: >> compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java uses >> develop flag -XX:-VerifyDependencies which is unavailable in product build >> >> Solution: >> add -XX:+IgnoreUnrecognizedVMOptions option >> >> Test: jprt >> >> Thanks, >> Tatiana From tobias.hartmann at oracle.com Mon Dec 8 14:12:27 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 08 Dec 2014 15:12:27 +0100 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <548598C2.30808@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> Message-ID: <5485B1CB.5050300@oracle.com> On 08.12.2014 13:25, Filipp Zhinkin wrote: > Hi Tobias, > > thank you for suggestion. > > Yes, I think we should take code heap size alignment into account. > > What alignment policy you're going to implement for 8064940? My current fix just large-page-aligns the code heap sizes. > Maybe instead of checking that values are in > (value - page_size, value + page_size) interval we should just check > that all values were aligned up to page_size? Yes, that's a better solution. However, I don't know how to figure out the available page sizes from Java code. Best, Tobias > > Thanks, > Filipp. > > On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >> Hi Filipp, >> >> the actual size of a code heap is affected by alignment and therefore may be >> different to the size set via the command line. For example, on Sparc we have to >> make sure that the code heaps are large page (4MB) aligned to reduce the number >> of ITLB misses (will be introduced with [1]). >> >> Maybe we should check if the actual size of the code heap is within boundaries, >> i.e., within the specified size +- (large) page size. >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >> >> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>> Hi, >>> >>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>> >>> There are three new tests: >>> compiler/codecache/cli/ >>> codeheapsize/TestCodeHeapSizeOptions >>> printcodecache/TestPrintCodeCacheOption >>> TestSegmentedCodeCacheOption >>> >>> All tests consist of several test cases aimed to verify different aspects >>> of options' processing. >>> >>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>> but add additional value - these tests actually check final values >>> of tested options and verifies PrintCodeCache output. >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>> Testing: manual & automated >>> >>> This change depends on: >>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI tests >>> error reporting >>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in testlibrary >>> for JDK-8059613 >>> >>> Thanks >>> Filipp. > From filipp.zhinkin at oracle.com Mon Dec 8 14:18:04 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 08 Dec 2014 18:18:04 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <5485B1CB.5050300@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> Message-ID: <5485B31C.6070001@oracle.com> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: > On 08.12.2014 13:25, Filipp Zhinkin wrote: >> Hi Tobias, >> >> thank you for suggestion. >> >> Yes, I think we should take code heap size alignment into account. >> >> What alignment policy you're going to implement for 8064940? > My current fix just large-page-aligns the code heap sizes. > >> Maybe instead of checking that values are in >> (value - page_size, value + page_size) interval we should just check >> that all values were aligned up to page_size? > Yes, that's a better solution. However, I don't know how to figure out the > available page sizes from Java code. There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list about to add such method to WB API, but it need to check how well it is going to work with large pages. Thanks, Filipp. > > Best, > Tobias > >> Thanks, >> Filipp. >> >> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>> Hi Filipp, >>> >>> the actual size of a code heap is affected by alignment and therefore may be >>> different to the size set via the command line. For example, on Sparc we have to >>> make sure that the code heaps are large page (4MB) aligned to reduce the number >>> of ITLB misses (will be introduced with [1]). >>> >>> Maybe we should check if the actual size of the code heap is within boundaries, >>> i.e., within the specified size +- (large) page size. >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>> >>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>> Hi, >>>> >>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>> >>>> There are three new tests: >>>> compiler/codecache/cli/ >>>> codeheapsize/TestCodeHeapSizeOptions >>>> printcodecache/TestPrintCodeCacheOption >>>> TestSegmentedCodeCacheOption >>>> >>>> All tests consist of several test cases aimed to verify different aspects >>>> of options' processing. >>>> >>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>> but add additional value - these tests actually check final values >>>> of tested options and verifies PrintCodeCache output. >>>> >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>> Testing: manual & automated >>>> >>>> This change depends on: >>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI tests >>>> error reporting >>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in testlibrary >>>> for JDK-8059613 >>>> >>>> Thanks >>>> Filipp. From david.r.chase at oracle.com Mon Dec 8 15:09:55 2014 From: david.r.chase at oracle.com (David Chase) Date: Mon, 8 Dec 2014 10:09:55 -0500 Subject: RFR(XS): 8066775 opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <8BE309E3-98B6-4ADC-B225-99E372C46BD6@oracle.com> References: <8BE309E3-98B6-4ADC-B225-99E372C46BD6@oracle.com> Message-ID: <60448E44-308D-4A77-BAAB-59664874C7D5@oracle.com> On 2014-12-08, at 6:45 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8066775/webrev.00/ > > Another follow up from "8054478 C2: Incorrectly compiled char[] array access crashes JVM? > > The part of the graph where the CastII becomes dead and the CastII's control is an IfTrue projection with input top. It looks plausible to me, but I was surprised that it was not immediately evident from the (other) source code that the clause in the "if" would make the assertion necessarily be true. (could it be something other than IfFalse or IfTrue? I'm a bit more suspicious of "obvious" assumptions after a recent other bug.) if (in(0) != NULL && in(0)->in(0) != NULL && in(0)->in(0)->is_If()) { assert(in(0)->is_IfFalse() || in(0)->is_IfTrue(), "should be If proj"); 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: From roland.westrelin at oracle.com Mon Dec 8 15:29:57 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 8 Dec 2014 16:29:57 +0100 Subject: RFR(XS): 8066775 opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <60448E44-308D-4A77-BAAB-59664874C7D5@oracle.com> References: <8BE309E3-98B6-4ADC-B225-99E372C46BD6@oracle.com> <60448E44-308D-4A77-BAAB-59664874C7D5@oracle.com> Message-ID: Hi David, Thanks for taking a look at this. >> http://cr.openjdk.java.net/~roland/8066775/webrev.00/ >> >> Another follow up from "8054478 C2: Incorrectly compiled char[] array access crashes JVM? >> >> The part of the graph where the CastII becomes dead and the CastII's control is an IfTrue projection with input top. > > It looks plausible to me, but I was surprised that it was not immediately evident from the > (other) source code that the clause in the "if" would make the assertion necessarily be true. > (could it be something other than IfFalse or IfTrue? I'm a bit more suspicious of "obvious" > assumptions after a recent other bug.) > > if (in(0) != NULL && in(0)->in(0) != NULL && in(0)->in(0)->is_If()) { > assert(in(0)->is_IfFalse() || in(0)->is_IfTrue(), "should be If proj?); FWIW, I reproduced the bug, observed that we indeed have CastII->IfTrue->top and that the bug goes away with the change. As I understand, you?re puzzled that we didn?t notice that that code was a problem before? For that problem to happen, nodes need to be processed by the IGVN in a specific order: the IfNode must become dead first then CastII is processed and finally the If projection is processed and goes dead. I assume, most of the time, the nodes are processed in the obvious order IfNode first, then If projection then CastII. Roland. From tatiana.pivovarova at oracle.com Mon Dec 8 16:49:16 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 08 Dec 2014 19:49:16 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented Message-ID: <5485D68C.7040106@oracle.com> Hi all, please review this new patch bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ Problem: Need WhiteBox::allocateCodeBlob(long, int), currently only WhiteBox::allocateCodeBlob(int, int) exist. Solution: Add new function with check: 156 public long allocateCodeBlob(long size, int type) { 157 int intSize = (int) size; 158 if ((long) intSize != size || size < 0) { 159 throw new IllegalArgumentException( 160 "size argument has illegal value " + size); 161 } 162 return allocateCodeBlob( intSize, type); 163 } Test: jprt Thanks, Tatiana From vladimir.kozlov at oracle.com Mon Dec 8 16:55:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Dec 2014 08:55:02 -0800 Subject: RFR(XS): 8066775 opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 In-Reply-To: <8BE309E3-98B6-4ADC-B225-99E372C46BD6@oracle.com> References: <8BE309E3-98B6-4ADC-B225-99E372C46BD6@oracle.com> Message-ID: <5485D7E6.3010405@oracle.com> Good. Thanks, Vladimir On 12/8/14 3:45 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8066775/webrev.00/ > > Another follow up from "8054478 C2: Incorrectly compiled char[] array access crashes JVM? > > The part of the graph where the CastII becomes dead and the CastII's control is an IfTrue projection with input top. > > Roland. > > From volker.simonis at gmail.com Mon Dec 8 16:58:10 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Dec 2014 17:58:10 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485BE52.9000500@us.ibm.com> References: <5485BE52.9000500@us.ibm.com> Message-ID: On Mon, Dec 8, 2014 at 4:05 PM, Maynard Johnson wrote: > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symbols) in your examples. Is this done by 'perf' itself >>> based only on the frame pointer? >> >> perf is walking the frame pointers. > Volker, to be specific, the perf profiling tool has a user space part and a > kernel space part. The collection of stack traces is done by the kernel. Hi Maynard, thanks for the explanation. So how does the kernel kernel collects stack traces - simply by looking at the frame pointers? Is there any way of extension mechanism to support the kernel with this task (i.e. a callback mechanism where the kernel provides a pc/sp/p touple and gets back the previous frame or a kind of plugin/module which will be called for the stack trace generation). I suppose such extensibility will be hard to achieve because it would have to be executed in the kernel context but I just wanted to ask. Regards, Volker > When a user-specified event (or series of events) occur, the process > being profiled is interrupted and the sampled information (which can > optionally include a full stack trace) is made available to the user space > perf tool to be saved to a file for future post-profiling processing. > > During the profiling phase, the perf tool collects information about the > profiled process's memory mappings, which allows for this address-to-symbol. > resolution, It's in the post-profiling phase where the sampled instruction, > along with its associated stack trace, are resolved to the appropriate symbol > (i.e., function/method) in a specific binary file (e.g., library, exectuable). > > And if the VM creates a /tmp/perf-.map file to save information about > JITed methods, the perf's post-profiling tool will find it and use it to > correlate sampled addresses it collected from the VM's executable anonymous > memory mappings to the method names. > > -Maynard >> >> A JVMTI agent, perf-map-agent, is providing a map file for symbol >> translation under /tmp/perf-PID.map. Linux perf already hunts for such >> a file when doing symbol translation. >> >>> >>> As I wrote before, this is pretty hard to get right for a JVM, but >>> there are good approximations. Have you looked at the 'jstack' tool >>> which is part of the JDK? If you run it on a Java process, it will >>> give you exact stack traces with full inlining information. However >>> this only works at safepoints so it is probably not suitable for >>> profiling with performance counters. >> >> Right, jstack works, and I get full correct stacks. I do really want >> to take stacks at any moment: not just CPU samples, but when tracing >> kernel TCP events, or PMC cache miss profiling, etc. perf can already >> do many advanced tracing and profiling activities. I just needed the >> Java stacks for context. >> >>> But you can also use 'jstack -F >>> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >>> of the time even with inlined Java frames. This is probably the best >>> you can get when interrupting a running JVM at an arbitrary point in >>> time. As you mentioned in one of your blogs, the VM can be in the >>> C-Library or even in the kernel at that time which don't preserve the >>> frame pointer either. So it will be already hard to even walk up to >>> the first Java frame. >> >> Well, the JVMs I'm looking at are already built with >> -fno-omit-frame-pointer (which is good). I edited hotspot to preserve >> it as well. >> >> Here's before I changed hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg >> >> Yes, most stacks are clearly broken. >> >> After changing hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> It's looking pretty good. If you look carefully on the far left and >> right, there are 0.8% stacks in read() and write() directly from java, >> which may well be broken (unless a java thread is calling these >> directly; there could also be some gcc inlining going on). Even if >> they are broken, I can see 98% of my profile. Plus, I'd be interested >> to know what exactly is reusing the frame pointer, so we could fix >> that too. >> >> The Java stacks themselves are also about a third as deep as they >> should be, due to inlining. >> >>> >>> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >>> your purpose, you can implement something similar in 'perf' or a >>> helper library of 'perf' and be happy (I don't actually know how perf >>> takes stack traces but I suppose there may some kind of callback >>> mechanism for walking unknown frames). This is actually not so hard. >>> I've recently implemented a "print_native_stack()" function within >>> hotspot itself (you can call it for example from gdb during debugging >>> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >>> Maye you could call this functions directly from 'perf' if perf >>> attaches with ptrace to the process (I assume it does or how else >>> could it walk the stack)? >> >> An OS-cooperative stack walker would be great, and I think the hotspot >> team is already doing this for Oracle Solaris. Thanks for the code >> too, this is pretty interesting. >> >> jstack -F -m eats 0.5s of CPU for me, so it would need work to make >> this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary >> kernel functions or tracepoints and get Java context from them, too. >> Eg, TCP functions, memory allocation, disk I/O, etc. >> >>> >>> These were just some random thoughts with the hope that they may be helpful. >> >> Yes, thanks! >> >> Brendan >> > From john.r.rose at oracle.com Mon Dec 8 16:58:55 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 8 Dec 2014 08:58:55 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> Message-ID: That's good; let's do it that way! Final suggestion (really): Add some more test cases, containing duplicate array indexes, to exercise the "local" logic. ? John > On Dec 8, 2014, at 5:30 AM, Roland Westrelin wrote: > > Hi John, > > Thanks for the suggestions. They sound very reasonable to me. Here is a new webrev: > > http://cr.openjdk.java.net/~roland/8066103/webrev.03/ > > In the patch below: > >> Or better yet a purely local cutout. (This sketch has a bad goto; the value of 'prev_dom' carried by the goto is what I called 'most_recent_prev_check' above.) >> >> diff --git a/src/share/vm/opto/ifnode.cpp b/src/share/vm/opto/ifnode.cpp >> --- a/src/share/vm/opto/ifnode.cpp >> +++ b/src/share/vm/opto/ifnode.cpp >> @@ -876,6 +876,7 @@ >> // Low and high offsets seen so far >> jint off_lo = offset1; >> jint off_hi = offset1; >> + int nb_checks = 0; >> >> // Scan for the top 2 checks and collect range of offsets >> for( int dist = 0; dist < 999; dist++ ) { // Range-Check scan limit >> @@ -890,6 +891,15 @@ >> // the same array bounds. >> if( flip2 == flip1 && range2 == range1 && index2 == index1 && >> dom->outcnt() == 2 ) { >> + if (nb_checks == 0 && dom->in(1) == in(1)) { >> + // Found an immediately dominating test at the same offset. >> + // This kind of back-to-back test can be eliminated locally, >> + // and there is no need to search further for dominating tests. >> + assert(offset2 == offset1, ""); >> + prev_dom = dom; >> + goto got_prev_dom; // FIXME: unstructured control flow >> + } >> + nb_checks++; >> // Gather expanded bounds >> off_lo = MIN2(off_lo,offset2); >> off_hi = MAX2(off_hi,offset2); >> @@ -985,6 +995,7 @@ >> >> } // End of Else scan for an equivalent test >> >> + got_prev_dom: // FIXME: unstructured control flow >> // Hit! Remove this IF >> #ifndef PRODUCT >> if( TraceIterativeGVN ) { > > I don?t think you need prev_dom. prev_dom is the projection, dom is the If node. IfNode::dominated_by needs the projection as input. > > Roland. > From vladimir.kozlov at oracle.com Mon Dec 8 17:06:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Dec 2014 09:06:06 -0800 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <5485D68C.7040106@oracle.com> References: <5485D68C.7040106@oracle.com> Message-ID: <5485DA7E.5000906@oracle.com> The webrev is wrong, should be http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.03/ which looks good. Thanks, Vladimir On 12/8/14 8:49 AM, Tatiana Pivovarova wrote: > Hi all, > > please review this new patch > > bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 > webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ > > Problem: > Need WhiteBox::allocateCodeBlob(long, int), currently only WhiteBox::allocateCodeBlob(int, int) exist. > > Solution: > Add new function with check: > > 156 public long allocateCodeBlob(long size, int type) { > 157 int intSize = (int) size; > 158 if ((long) intSize != size || size < 0) { > 159 throw new IllegalArgumentException( > 160 "size argument has illegal value " + size); > 161 } > 162 return allocateCodeBlob( intSize, type); > 163 } > > > Test: jprt > > > Thanks, > Tatiana From mikael.gerdin at oracle.com Mon Dec 8 17:15:35 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Mon, 08 Dec 2014 18:15:35 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485BE52.9000500@us.ibm.com> References: <5485BE52.9000500@us.ibm.com> Message-ID: <5485DCB7.4010901@oracle.com> Maynard, On 2014-12-08 16:05, Maynard Johnson wrote: > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symbols) in your examples. Is this done by 'perf' itself >>> based only on the frame pointer? >> >> perf is walking the frame pointers. > Volker, to be specific, the perf profiling tool has a user space part and a > kernel space part. The collection of stack traces is done by the kernel. > When a user-specified event (or series of events) occur, the process > being profiled is interrupted and the sampled information (which can > optionally include a full stack trace) is made available to the user space > perf tool to be saved to a file for future post-profiling processing. > > During the profiling phase, the perf tool collects information about the > profiled process's memory mappings, which allows for this address-to-symbol. > resolution, It's in the post-profiling phase where the sampled instruction, > along with its associated stack trace, are resolved to the appropriate symbol > (i.e., function/method) in a specific binary file (e.g., library, exectuable). > > And if the VM creates a /tmp/perf-.map file to save information about > JITed methods, the perf's post-profiling tool will find it and use it to > correlate sampled addresses it collected from the VM's executable anonymous > memory mappings to the method names. I seem to recall reading about perf having support for DWARF debug info. If the VM (or a JVM/TI agent) could create DWARF debug symbols, could that be used to convey information about inlined functions and stack unwinding without frame pointers? I realize that emitting DWARF debug symbols for generated code is not a trivial undertaking but since perf is running sampling in the kernel and we can't disable inlining that seems to be one of the few ways we can get complete stack traces. There would be several other advantages to having DWARF symbols for generated code, GDB can use them when debugging the JVM for example. An alternate approach could be to extend the information in perf-.map to have more detailed PC ranges with information about which functions are inlined. A lot of that information is available in the VM but not necessarily exposed via the tool APIs /Mikael > > -Maynard >> >> A JVMTI agent, perf-map-agent, is providing a map file for symbol >> translation under /tmp/perf-PID.map. Linux perf already hunts for such >> a file when doing symbol translation. >> >>> >>> As I wrote before, this is pretty hard to get right for a JVM, but >>> there are good approximations. Have you looked at the 'jstack' tool >>> which is part of the JDK? If you run it on a Java process, it will >>> give you exact stack traces with full inlining information. However >>> this only works at safepoints so it is probably not suitable for >>> profiling with performance counters. >> >> Right, jstack works, and I get full correct stacks. I do really want >> to take stacks at any moment: not just CPU samples, but when tracing >> kernel TCP events, or PMC cache miss profiling, etc. perf can already >> do many advanced tracing and profiling activities. I just needed the >> Java stacks for context. >> >>> But you can also use 'jstack -F >>> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >>> of the time even with inlined Java frames. This is probably the best >>> you can get when interrupting a running JVM at an arbitrary point in >>> time. As you mentioned in one of your blogs, the VM can be in the >>> C-Library or even in the kernel at that time which don't preserve the >>> frame pointer either. So it will be already hard to even walk up to >>> the first Java frame. >> >> Well, the JVMs I'm looking at are already built with >> -fno-omit-frame-pointer (which is good). I edited hotspot to preserve >> it as well. >> >> Here's before I changed hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg >> >> Yes, most stacks are clearly broken. >> >> After changing hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> It's looking pretty good. If you look carefully on the far left and >> right, there are 0.8% stacks in read() and write() directly from java, >> which may well be broken (unless a java thread is calling these >> directly; there could also be some gcc inlining going on). Even if >> they are broken, I can see 98% of my profile. Plus, I'd be interested >> to know what exactly is reusing the frame pointer, so we could fix >> that too. >> >> The Java stacks themselves are also about a third as deep as they >> should be, due to inlining. >> >>> >>> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >>> your purpose, you can implement something similar in 'perf' or a >>> helper library of 'perf' and be happy (I don't actually know how perf >>> takes stack traces but I suppose there may some kind of callback >>> mechanism for walking unknown frames). This is actually not so hard. >>> I've recently implemented a "print_native_stack()" function within >>> hotspot itself (you can call it for example from gdb during debugging >>> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >>> Maye you could call this functions directly from 'perf' if perf >>> attaches with ptrace to the process (I assume it does or how else >>> could it walk the stack)? >> >> An OS-cooperative stack walker would be great, and I think the hotspot >> team is already doing this for Oracle Solaris. Thanks for the code >> too, this is pretty interesting. >> >> jstack -F -m eats 0.5s of CPU for me, so it would need work to make >> this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary >> kernel functions or tracepoints and get Java context from them, too. >> Eg, TCP functions, memory allocation, disk I/O, etc. >> >>> >>> These were just some random thoughts with the hope that they may be helpful. >> >> Yes, thanks! >> >> Brendan >> > From roland.westrelin at oracle.com Mon Dec 8 17:58:04 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 8 Dec 2014 18:58:04 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> Message-ID: > That's good; let's do it that way! > > Final suggestion (really): Add some more test cases, containing duplicate array indexes, to exercise the "local" logic. Thanks John. I?ll add some test cases. Do you want to see another webrev with test cases? Roland. > > ? John > >> On Dec 8, 2014, at 5:30 AM, Roland Westrelin wrote: >> >> Hi John, >> >> Thanks for the suggestions. They sound very reasonable to me. Here is a new webrev: >> >> http://cr.openjdk.java.net/~roland/8066103/webrev.03/ >> >> In the patch below: >> >>> Or better yet a purely local cutout. (This sketch has a bad goto; the value of 'prev_dom' carried by the goto is what I called 'most_recent_prev_check' above.) >>> >>> diff --git a/src/share/vm/opto/ifnode.cpp b/src/share/vm/opto/ifnode.cpp >>> --- a/src/share/vm/opto/ifnode.cpp >>> +++ b/src/share/vm/opto/ifnode.cpp >>> @@ -876,6 +876,7 @@ >>> // Low and high offsets seen so far >>> jint off_lo = offset1; >>> jint off_hi = offset1; >>> + int nb_checks = 0; >>> >>> // Scan for the top 2 checks and collect range of offsets >>> for( int dist = 0; dist < 999; dist++ ) { // Range-Check scan limit >>> @@ -890,6 +891,15 @@ >>> // the same array bounds. >>> if( flip2 == flip1 && range2 == range1 && index2 == index1 && >>> dom->outcnt() == 2 ) { >>> + if (nb_checks == 0 && dom->in(1) == in(1)) { >>> + // Found an immediately dominating test at the same offset. >>> + // This kind of back-to-back test can be eliminated locally, >>> + // and there is no need to search further for dominating tests. >>> + assert(offset2 == offset1, ""); >>> + prev_dom = dom; >>> + goto got_prev_dom; // FIXME: unstructured control flow >>> + } >>> + nb_checks++; >>> // Gather expanded bounds >>> off_lo = MIN2(off_lo,offset2); >>> off_hi = MAX2(off_hi,offset2); >>> @@ -985,6 +995,7 @@ >>> >>> } // End of Else scan for an equivalent test >>> >>> + got_prev_dom: // FIXME: unstructured control flow >>> // Hit! Remove this IF >>> #ifndef PRODUCT >>> if( TraceIterativeGVN ) { >> >> I don?t think you need prev_dom. prev_dom is the projection, dom is the If node. IfNode::dominated_by needs the projection as input. >> >> Roland. >> From christian.thalinger at oracle.com Mon Dec 8 18:12:20 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 8 Dec 2014 10:12:20 -0800 Subject: Assertion failed: int pressure is incorrect In-Reply-To: <5485A05F.9020701@redhat.com> References: <5485A05F.9020701@redhat.com> Message-ID: [Sending to hotspot-compiler-dev; bcc?ing hotspot-dev.] > On Dec 8, 2014, at 4:58 AM, Andrew Haley wrote: > > I'm occasionally seeing this: > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/scratch1/large-codecache/hotspot/src/share/vm/opto/ifg.cpp:693), pid=9212, tid=4395909313024 > # assert(int_pressure.current_pressure() == count_int_pressure(liveout)) failed: the int pressure is incorrect > # > > Does anyone know what might cause this? Perhaps a bug in my back > end? If not, can I please have some advice about how to debug it? > > I'm only seeing this with a fairly recent cut of JDK9. > > Thanks, > Andrew, From christian.thalinger at oracle.com Mon Dec 8 18:15:18 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 8 Dec 2014 10:15:18 -0800 Subject: Locating call sites of methods in C2 In-Reply-To: <64E2023B-8362-4ED2-B755-366FAA5B615D@gmail.com> References: <64E2023B-8362-4ED2-B755-366FAA5B615D@gmail.com> Message-ID: <3BC4BB0F-E901-4D59-95A5-BDC8B56D5B89@oracle.com> > On Dec 5, 2014, at 2:49 AM, Manas Thakur wrote: > > Hi > > Is there a way to access the call-site (possibly in terms of the bytecode offset) of a method being compiled by C2? Doesn?t the current compile task store it in some variable? I?m not sure I understand. Are you asking for the BCI (bytecode index) of the invoke instruction to method bar if you compile a method foo which calls bar: void foo() { bar(); } > > Regards, > Manas > From johannes.rudolph at googlemail.com Mon Dec 8 18:32:46 2014 From: johannes.rudolph at googlemail.com (Johannes Rudolph) Date: Mon, 8 Dec 2014 19:32:46 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <5485DCB7.4010901@oracle.com> Message-ID: Hi there, I'm the one who started the perf-map-agent project. Thanks, Brendan and all others for having this discussion here. On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis wrote: > That said, I still don't know how perf creates stack traces. Does it > attach to the process with ptrace or how else does it inspect the > stacks after a performance counter event? `perf` is part of the Linux kernel. It supports different kind of trace events like hardware performance counter in the CPU. IIUC it creates a counter that is incremented on certain events (like CPU cycles, cache misses, etc.) and if the counter overflows the currently running program is interrupted and the kernel's event processing is allowed to record the event. No debugger is needed as the event is generated directly in the context of the monitored process (IIUC, right?). You can instruct the perf infrastructure (and thus the kernel) to capture a stacktrace when the event triggers and the (very simple) capturing logic is then run inside the kernel. [2] I guess adapting the kernel stacktrace collection logic would be possible but probably hard with all the constraints kernel code has to run under. As I just found out (and as Mikael confirms), there's an alternative stacktrace collection mode enabled by the `-g dwarf` setting of `perf record` which instructs the kernel to capture the complete X bytes at the top of the stack [3] and actually walks the stack in user mode. It would be probably much easier to adapt this user-mode code to figure out stacktraces for JIT'd methods if we can recover their frame pointers. Would that work? Maybe it's enough to get the stackframe size of the nmethod, because if `rsp` never changes during a JIT'd method (i.e. if nmethods have a constant frame size) you may be able to walk the stack by calculating the frame from `rsp` and the frame size (it seems that's basically also how hotspot does it). How could you get at the frame size information? -- Johannes [1] https://github.com/jrudolph/perf-map-agent [2] https://github.com/torvalds/linux/blob/master/arch/x86/kernel/cpu/perf_event.c#L2051 [3] https://github.com/torvalds/linux/blob/master/tools/perf/util/evsel.c#L547 ----------------------------------------------- Johannes Rudolph http://virtual-void.net From vladimir.kozlov at oracle.com Mon Dec 8 18:53:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Dec 2014 10:53:37 -0800 Subject: %ld instead of %d for LogCompilation counts? In-Reply-To: References: <548240FB.2030804@oracle.com> Message-ID: <5485F3B1.4070405@oracle.com> Thank you, Chris What do you think about using %f as John suggested? Will it solve your problem? Both cases may have a fractional part and with 'long' it will be lost. Thanks, Vladimir On 12/8/14 3:56 AM, Chris Newland wrote: > Hi Vladimir, > > The believe the only other LogCompilation output where %g is used for a > cardinal number is this one? > > share/vm/opto/parse1.cpp:443: > > log->begin_head("parse method='%d' uses='%g'", > log->identify(parse_method), expected_uses); > > > Kind regards, > > Chris > > On Fri, December 5, 2014 23:34, Vladimir Kozlov wrote: >> Hi, >> >> >> The output was produced by following lines: >> >> >> C->log()->elem("branch target_bci='%d' taken='%d' not_taken='%d' >> cnt='%g' prob='%s'", iter().get_dest(), taken, not_taken, cnt, prob_str); >> >> 'cnt' is declared as 'float' and defined as: >> >> >> cnt = (taken + not_taken) / FreqCountInvocations; >> >> I think it is artifact from long time ago when FreqCountInvocations was >> >>> 1. And to avoid integer overflow, so we want to keep variable as float. >>> >> >> But I am fine to change log output to long by converting it to >> (jlong)cnt and using JLONG_FORMAT format. >> >> >> Do you know other places where we use %g for counters? >> >> >> Thanks, >> Vladimir >> >> >> On 12/5/14 1:09 PM, Chris Newland wrote: >> >>> Hi, >>> >>> >>> I've encountered some LogCompilation counters in 8u25 that are getting >>> printed in exponential form in hotspot.log : >>> >>> >> cnt='2.38658e+06' prob='0.00990148'/> >>> >>> This is harder to parse and loses accuracy because %d is used as a >>> formatter in hotspot/src/share/vm/opto/parse2.cpp: >>> >>> if (C->log() != NULL) { C->log()->elem("branch target_bci='%d' >>> taken='%d' not_taken='%d'", iter().get_dest(), taken, not_taken); } >>> >>> >>> Would it be possible to modify some or all of the LogCompilation format >>> strings to use %ld so that large integers can be printed without >>> exponents? >>> >>> I don't mind going through the OpenJDK motions to submit this as a >>> patch if it's a sensible idea. >>> >>> Thanks, >>> >>> >>> Chris >>> >>> >> > > From vladimir.kozlov at oracle.com Mon Dec 8 19:04:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Dec 2014 11:04:01 -0800 Subject: Assertion failed: int pressure is incorrect In-Reply-To: References: <5485A05F.9020701@redhat.com> Message-ID: <5485F621.6080102@oracle.com> count_int_pressure() was added almost year ago during ifg.cpp code refactoring 8031498. Our bugs system does not show this problem. I assume it could your changes created code path we did not hit before. There is no magic for debugging this code. It is usual: get a reproducer (you can try compilation replay), add print statements or use debugger. Regards, Vladimir On 12/8/14 10:12 AM, Christian Thalinger wrote: > [Sending to hotspot-compiler-dev; bcc?ing hotspot-dev.] > >> On Dec 8, 2014, at 4:58 AM, Andrew Haley wrote: >> >> I'm occasionally seeing this: >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/scratch1/large-codecache/hotspot/src/share/vm/opto/ifg.cpp:693), pid=9212, tid=4395909313024 >> # assert(int_pressure.current_pressure() == count_int_pressure(liveout)) failed: the int pressure is incorrect >> # >> >> Does anyone know what might cause this? Perhaps a bug in my back >> end? If not, can I please have some advice about how to debug it? >> >> I'm only seeing this with a fairly recent cut of JDK9. >> >> Thanks, >> Andrew, > From staffan.larsen at oracle.com Mon Dec 8 19:17:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Dec 2014 20:17:42 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485BE52.9000500@us.ibm.com> References: <5485BE52.9000500@us.ibm.com> Message-ID: <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> > On 8 dec 2014, at 16:05, Maynard Johnson wrote: > > On 12/05/2014 05:09 PM, Brendan Gregg wrote: >> G'Day Volker, >> >> On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis >> wrote: >>> Hi Brendan, >>> >>> I'm still not understanding who is taking the actual stack traces (let >>> alone the symbols) in your examples. Is this done by 'perf' itself >>> based only on the frame pointer? >> >> perf is walking the frame pointers. > Volker, to be specific, the perf profiling tool has a user space part and a > kernel space part. The collection of stack traces is done by the kernel. > When a user-specified event (or series of events) occur, the process > being profiled is interrupted and the sampled information (which can > optionally include a full stack trace) is made available to the user space > perf tool to be saved to a file for future post-profiling processing. > > During the profiling phase, the perf tool collects information about the > profiled process's memory mappings, which allows for this address-to-symbol. > resolution, It's in the post-profiling phase where the sampled instruction, > along with its associated stack trace, are resolved to the appropriate symbol > (i.e., function/method) in a specific binary file (e.g., library, exectuable). > > And if the VM creates a /tmp/perf-.map file to save information about > JITed methods, the perf's post-profiling tool will find it and use it to > correlate sampled addresses it collected from the VM's executable anonymous > memory mappings to the method names. Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. /Staffan > > -Maynard >> >> A JVMTI agent, perf-map-agent, is providing a map file for symbol >> translation under /tmp/perf-PID.map. Linux perf already hunts for such >> a file when doing symbol translation. >> >>> >>> As I wrote before, this is pretty hard to get right for a JVM, but >>> there are good approximations. Have you looked at the 'jstack' tool >>> which is part of the JDK? If you run it on a Java process, it will >>> give you exact stack traces with full inlining information. However >>> this only works at safepoints so it is probably not suitable for >>> profiling with performance counters. >> >> Right, jstack works, and I get full correct stacks. I do really want >> to take stacks at any moment: not just CPU samples, but when tracing >> kernel TCP events, or PMC cache miss profiling, etc. perf can already >> do many advanced tracing and profiling activities. I just needed the >> Java stacks for context. >> >>> But you can also use 'jstack -F >>> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >>> of the time even with inlined Java frames. This is probably the best >>> you can get when interrupting a running JVM at an arbitrary point in >>> time. As you mentioned in one of your blogs, the VM can be in the >>> C-Library or even in the kernel at that time which don't preserve the >>> frame pointer either. So it will be already hard to even walk up to >>> the first Java frame. >> >> Well, the JVMs I'm looking at are already built with >> -fno-omit-frame-pointer (which is good). I edited hotspot to preserve >> it as well. >> >> Here's before I changed hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg >> >> Yes, most stacks are clearly broken. >> >> After changing hotspot: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> It's looking pretty good. If you look carefully on the far left and >> right, there are 0.8% stacks in read() and write() directly from java, >> which may well be broken (unless a java thread is calling these >> directly; there could also be some gcc inlining going on). Even if >> they are broken, I can see 98% of my profile. Plus, I'd be interested >> to know what exactly is reusing the frame pointer, so we could fix >> that too. >> >> The Java stacks themselves are also about a third as deep as they >> should be, due to inlining. >> >>> >>> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >>> your purpose, you can implement something similar in 'perf' or a >>> helper library of 'perf' and be happy (I don't actually know how perf >>> takes stack traces but I suppose there may some kind of callback >>> mechanism for walking unknown frames). This is actually not so hard. >>> I've recently implemented a "print_native_stack()" function within >>> hotspot itself (you can call it for example from gdb during debugging >>> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >>> Maye you could call this functions directly from 'perf' if perf >>> attaches with ptrace to the process (I assume it does or how else >>> could it walk the stack)? >> >> An OS-cooperative stack walker would be great, and I think the hotspot >> team is already doing this for Oracle Solaris. Thanks for the code >> too, this is pretty interesting. >> >> jstack -F -m eats 0.5s of CPU for me, so it would need work to make >> this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary >> kernel functions or tracepoints and get Java context from them, too. >> Eg, TCP functions, memory allocation, disk I/O, etc. >> >>> >>> These were just some random thoughts with the hope that they may be helpful. >> >> Yes, thanks! >> >> Brendan >> > From john.r.rose at oracle.com Mon Dec 8 19:41:17 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 8 Dec 2014 11:41:17 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> Message-ID: On Dec 8, 2014, at 9:58 AM, Roland Westrelin wrote: > >> That's good; let's do it that way! >> >> Final suggestion (really): Add some more test cases, containing duplicate array indexes, to exercise the "local" logic. > > Thanks John. I?ll add some test cases. Do you want to see another webrev with test cases? I'd like to look at it, so please update the webrev, but you can proceed with a thumbs up from me as a reviewer no matter what. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Mon Dec 8 19:58:05 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 08 Dec 2014 22:58:05 +0300 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <547E352A.5040806@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> <547E352A.5040806@oracle.com> Message-ID: <548602CD.805@oracle.com> Vladimir, http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/ On 12/03/2014 12:54 AM, Vladimir Kozlov wrote: > On 12/2/14 1:32 AM, Igor Ignatyev wrote: >> Vladimir, >> >> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in >> 'non-makeNotEntrant' case, there's no way to determine if the method was >> deoptimized. > > I don't understand how you check that in the test. getCompiler returns 0 if method isn't compiled or (in my case) was deoptimized. TestCaseImpl::method uses 'getCompiler' method as a multiplier for result value. if TestCaseImpl::method returns 0, for-loop (lines 75--80) quits. > > If you only want to check if method was deoptimized you can check > MethodData::decompile_count(). MethodData::decompile_count is incremented only if nmethod is compiled by c2. so it can't be used. > > I don't like extending Unsafe API for just this test. well, I can move it to whitebox, if you don't mind to have intrinsics for it. > > Thanks, > Vladimir > >> >> Thanks, >> Igor >> >> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >>> Why you need new Unsafe.getCompiler()? >>> >>> thanks, >>> Vladimir >>> >>> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>>> 220 lines changed: 212 ins; 8 del; 0 mod; >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>>> 4 lines changed: 4 ins; 0 del; 0 mod; >>>> >>>> Hi all, >>>> >>>> please review the patch which adds >>>> - a new whitebox method 'deoptimizeFrames' which deoptimizes methods >>>> which are currently on stack >>>> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net >>>> which >>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 accordingly. >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>>> testing: jprt + new added test >>>> -- Igor From brendan.d.gregg at gmail.com Mon Dec 8 20:31:47 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Mon, 8 Dec 2014 12:31:47 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> References: <5485BE52.9000500@us.ibm.com> <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> Message-ID: G'Day Staffan, On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen wrote: > >> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >> [...] >> >> And if the VM creates a /tmp/perf-.map file to save information about >> JITed methods, the perf's post-profiling tool will find it and use it to >> correlate sampled addresses it collected from the VM's executable anonymous >> memory mappings to the method names. > > Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. In the .map file, no, at least not currently. However, consider the following perf sampled stack trace (this is from my patched OpenJDK 8, with frame pointers): # perf record -F 99 -a -g -- sleep 10 # perf script [...] java 10532 [008] 3444046.716431: cpu-clock: 7fe919301c30 (/tmp/perf-10490.map) 7fe91934d50c (/tmp/perf-10490.map) 7fe9193a43d0 (/tmp/perf-10490.map) 7fe9194ffcf0 (/tmp/perf-10490.map) 7fe9195026d0 (/tmp/perf-10490.map) 7fe9194ffc4c (/tmp/perf-10490.map) 7fe91b6c440c (/tmp/perf-10490.map) 7fe91afa9c00 (/tmp/perf-10490.map) 7fe91ab739f4 (/tmp/perf-10490.map) 7fe91df23630 (/tmp/perf-10490.map) 7fe91ab739f4 (/tmp/perf-10490.map) 7fe91acc7ea8 (/tmp/perf-10490.map) 7fe91c4fa014 (/tmp/perf-10490.map) 7fe9190072e0 (/tmp/perf-10490.map) 7fe9190072e0 (/tmp/perf-10490.map) 7fe919007325 (/tmp/perf-10490.map) 7fe9190004e7 (/tmp/perf-10490.map) 7fe92f70670e JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/am 7fe92f707a3f JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-r 7fe92f707edf JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/l 7fe92f741668 thread_entry(JavaThread*, Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92fa555c8 JavaThread::thread_main_inner() (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92fa5581c JavaThread::run() (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92f916ba2 java_start(Thread*) (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) 7fe92ff95e9a start_thread (/lib/x86_64-linux-gnu/libpthread-2.15.so) perf script emits every sampled stack trace, which I normally do for flame graph generation. If I had Johannes's perf-map-agent loaded, then those hex addresses become Java method symbols. Note the timestamp on the cpu-clock line. So... It should be easy to change perf-map-agent to write a timestamped map file, to a different location (so perf doesn't find it). Use the same timestamp type as perf. Then, a little Perl wrapper can take "perf script" output and translate the addresses based on the timestamped map file. (perf itself can be enhanced to do this, although the time frame for a perf change propagating to Linux users may be years, so the Perl wrapper could be used in the meantime.) I haven't needed to do this yet. map file churn in production has been small (depends on workload). The real pain for us is switching apps from Oracle JDK to my patched OpenJDK, so we get the frame pointer. Brendan From brendan.d.gregg at gmail.com Mon Dec 8 22:19:58 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Mon, 8 Dec 2014 14:19:58 -0800 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5485DCB7.4010901@oracle.com> References: <5485BE52.9000500@us.ibm.com> <5485DCB7.4010901@oracle.com> Message-ID: G'Day Mikael, On Mon, Dec 8, 2014 at 9:15 AM, Mikael Gerdin wrote: > Maynard, > > > On 2014-12-08 16:05, Maynard Johnson wrote: >> [...] >> >> And if the VM creates a /tmp/perf-.map file to save information about >> JITed methods, the perf's post-profiling tool will find it and use it to >> correlate sampled addresses it collected from the VM's executable >> anonymous >> memory mappings to the method names. > > > I seem to recall reading about perf having support for DWARF debug info. > > If the VM (or a JVM/TI agent) could create DWARF debug symbols, could that > be used to convey information about inlined functions and stack unwinding > without frame pointers? > I realize that emitting DWARF debug symbols for generated code is not a > trivial undertaking but since perf is running sampling in the kernel and we > can't disable inlining that seems to be one of the few ways we can get > complete stack traces. It's a good idea, but I'm not sure the DWARF unwind approach is suitable for dynamic JIT. I'm usually sampling at 99 Hertz. With inlined symbols, just the perf.map file can become 10s of Mbytes, and I assume the DWARF info would be similar. So the file would need to be in a consistent state so that perf can begin reading it anytime, and do stack walking based on what it reads, while at the same time symbols may be compiled anytime and the map file would need to change. With the frame pointer approach, perf always knows how to walk the stack, at any time. If symbols move during the profile, it breaks translation but not walking. And there's different ways to deal with the translation issue (collect before and after maps and note differences, or do timestamped maps). I assume the reliable option is having kernel support for Java unwinding (like the Solaris approach mentioned previously). Frame pointer support can be an option for situations when the kernel support isn't available, while noting its caveats. > > There would be several other advantages to having DWARF symbols for > generated code, GDB can use them when debugging the JVM for example. > > An alternate approach could be to extend the information in perf-.map > to have more detailed PC ranges with information about which functions are > inlined. A lot of that information is available in the VM but not > necessarily exposed via the tool APIs Johannes has done some of this with the perf-map-agent "unfold" option (https://github.com/jrudolph/perf-map-agent), which includes inlined information. I've tried adding an extra filter step to resuscitate frames that were inlined, which sort-of worked (needs more work). However, having inlined stacks hasn't been that much of a problem. I've shown my flame graphs to developers, noting that inlined frames can't be seen, and so far they can still follow what's going on (the use case here is performance profiling, to figure out where the bulk of CPU time is spent). jstack(1) output can be used for clues, to see how the inlined code maps to the full stacks. And, there's JVM tunables that can be used to reduce inlining. Brendan From vladimir.kozlov at oracle.com Mon Dec 8 22:55:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Dec 2014 14:55:44 -0800 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <548602CD.805@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> <547E352A.5040806@oracle.com> <548602CD.805@oracle.com> Message-ID: <54862C70.5020006@oracle.com> On 12/8/14 11:58 AM, Igor Ignatyev wrote: > Vladimir, > > http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/ > > On 12/03/2014 12:54 AM, Vladimir Kozlov wrote: >> On 12/2/14 1:32 AM, Igor Ignatyev wrote: >>> Vladimir, >>> >>> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in >>> 'non-makeNotEntrant' case, there's no way to determine if the method was >>> deoptimized. >> >> I don't understand how you check that in the test. > getCompiler returns 0 if method isn't compiled or (in my case) was > deoptimized. TestCaseImpl::method uses 'getCompiler' method as a > multiplier for result value. if TestCaseImpl::method returns 0, for-loop > (lines 75--80) quits. Okay. I missed that compile() calls method() and returns sum of its results. > >> >> If you only want to check if method was deoptimized you can check >> MethodData::decompile_count(). > > MethodData::decompile_count is incremented only if nmethod is compiled > by c2. so it can't be used. >> >> I don't like extending Unsafe API for just this test. > well, I can move it to whitebox, if you don't mind to have intrinsics > for it. I would rather see changes in nmethod and new WB accessors to it. And sorry, I don't like the test. The test does not have comments/description. It is difficult to judge, is it doing what it is suppose to do or not. nm->make_not_entrant() will call method()->clear_code(). So how you expect that checkCompiled() will not throw Error after deoptimization?: 69 WHITE_BOX.deoptimizeFrames(makeNotEntrant); 70 checkCompiled(); Your loop (lines 75--80) is in a race of compilations vs deoptimizations. The test on machines with different numbers of threads will behave differently. Where is guarantee that you will get your result == 0 case? Why do you even need these *concurrent* deoptimization, compilation loops? Can you do it synchronously? Execute method in separate thread and stop it when you get compilation of requested level or other condition (recursion level). Do deoptimization in main thread and see if methods are deoptimized. Regards, Vladimir > >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> Igor >>> >>> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >>>> Why you need new Unsafe.getCompiler()? >>>> >>>> thanks, >>>> Vladimir >>>> >>>> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>>>> 220 lines changed: 212 ins; 8 del; 0 mod; >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>>>> 4 lines changed: 4 ins; 0 del; 0 mod; >>>>> >>>>> Hi all, >>>>> >>>>> please review the patch which adds >>>>> - a new whitebox method 'deoptimizeFrames' which deoptimizes methods >>>>> which are currently on stack >>>>> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net >>>>> which >>>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 accordingly. >>>>> >>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>>>> testing: jprt + new added test >>>>> > From igor.ignatyev at oracle.com Mon Dec 8 23:05:53 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 09 Dec 2014 02:05:53 +0300 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <54862C70.5020006@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> <547E352A.5040806@oracle.com> <548602CD.805@oracle.com> <54862C70.5020006@oracle.com> Message-ID: <54862ED1.5010305@oracle.com> On 12/09/2014 01:55 AM, Vladimir Kozlov wrote: > On 12/8/14 11:58 AM, Igor Ignatyev wrote: >> Vladimir, >> >> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/ >> >> On 12/03/2014 12:54 AM, Vladimir Kozlov wrote: >>> On 12/2/14 1:32 AM, Igor Ignatyev wrote: >>>> Vladimir, >>>> >>>> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in >>>> 'non-makeNotEntrant' case, there's no way to determine if the method >>>> was >>>> deoptimized. >>> >>> I don't understand how you check that in the test. >> getCompiler returns 0 if method isn't compiled or (in my case) was >> deoptimized. TestCaseImpl::method uses 'getCompiler' method as a >> multiplier for result value. if TestCaseImpl::method returns 0, for-loop >> (lines 75--80) quits. > > Okay. I missed that compile() calls method() and returns sum of its > results. > >> >>> >>> If you only want to check if method was deoptimized you can check >>> MethodData::decompile_count(). >> >> MethodData::decompile_count is incremented only if nmethod is compiled >> by c2. so it can't be used. >>> >>> I don't like extending Unsafe API for just this test. >> well, I can move it to whitebox, if you don't mind to have intrinsics >> for it. > > I would rather see changes in nmethod and new WB accessors to it. > > And sorry, I don't like the test. The test does not have > comments/description. It is difficult to judge, is it doing what it is > suppose to do or not. yeap, sorry. I'll add the comments. > > nm->make_not_entrant() will call method()->clear_code(). So how you > expect that checkCompiled() will not throw Error after deoptimization?: > > 69 WHITE_BOX.deoptimizeFrames(makeNotEntrant); > 70 checkCompiled(); > > Your loop (lines 75--80) is in a race of compilations vs > deoptimizations. The test on machines with different numbers of threads > will behave differently. Where is guarantee that you will get your > result == 0 case? > Why do you even need these *concurrent* deoptimization, compilation loops? > Can you do it synchronously? Execute method in separate thread and stop > it when you get compilation of requested level or other condition > (recursion level). Do deoptimization in main thread and see if methods > are deoptimized. WB::deoptimizeFrames has to deoptimize methods which are currently on stack, that's why I expect that checkCompiled on line 70 won't throw an exception and that's why I do need these concurrent deoptimization/compilation. > > Regards, > Vladimir > >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> Igor >>>> >>>> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >>>>> Why you need new Unsafe.getCompiler()? >>>>> >>>>> thanks, >>>>> Vladimir >>>>> >>>>> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>>>>> 220 lines changed: 212 ins; 8 del; 0 mod; >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>>>>> 4 lines changed: 4 ins; 0 del; 0 mod; >>>>>> >>>>>> Hi all, >>>>>> >>>>>> please review the patch which adds >>>>>> - a new whitebox method 'deoptimizeFrames' which deoptimizes >>>>>> methods >>>>>> which are currently on stack >>>>>> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net >>>>>> which >>>>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 accordingly. >>>>>> >>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>>>>> testing: jprt + new added test >>>>>> >> -- Igor From vladimir.kozlov at oracle.com Mon Dec 8 23:44:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 08 Dec 2014 15:44:37 -0800 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <54862ED1.5010305@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> <547E352A.5040806@oracle.com> <548602CD.805@oracle.com> <54862C70.5020006@oracle.com> <54862ED1.5010305@oracle.com> Message-ID: <548637E5.5060807@oracle.com> On 12/8/14 3:05 PM, Igor Ignatyev wrote: > On 12/09/2014 01:55 AM, Vladimir Kozlov wrote: >> On 12/8/14 11:58 AM, Igor Ignatyev wrote: >>> Vladimir, >>> >>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/ >>> >>> On 12/03/2014 12:54 AM, Vladimir Kozlov wrote: >>>> On 12/2/14 1:32 AM, Igor Ignatyev wrote: >>>>> Vladimir, >>>>> >>>>> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in >>>>> 'non-makeNotEntrant' case, there's no way to determine if the method >>>>> was >>>>> deoptimized. >>>> >>>> I don't understand how you check that in the test. >>> getCompiler returns 0 if method isn't compiled or (in my case) was >>> deoptimized. TestCaseImpl::method uses 'getCompiler' method as a >>> multiplier for result value. if TestCaseImpl::method returns 0, for-loop >>> (lines 75--80) quits. >> >> Okay. I missed that compile() calls method() and returns sum of its >> results. >> >>> >>>> >>>> If you only want to check if method was deoptimized you can check >>>> MethodData::decompile_count(). >>> >>> MethodData::decompile_count is incremented only if nmethod is compiled >>> by c2. so it can't be used. >>>> >>>> I don't like extending Unsafe API for just this test. >>> well, I can move it to whitebox, if you don't mind to have intrinsics >>> for it. >> >> I would rather see changes in nmethod and new WB accessors to it. >> >> And sorry, I don't like the test. The test does not have >> comments/description. It is difficult to judge, is it doing what it is >> suppose to do or not. > yeap, sorry. I'll add the comments. > >> >> nm->make_not_entrant() will call method()->clear_code(). So how you >> expect that checkCompiled() will not throw Error after deoptimization?: >> >> 69 WHITE_BOX.deoptimizeFrames(makeNotEntrant); >> 70 checkCompiled(); >> >> Your loop (lines 75--80) is in a race of compilations vs >> deoptimizations. The test on machines with different numbers of threads >> will behave differently. Where is guarantee that you will get your >> result == 0 case? >> Why do you even need these *concurrent* deoptimization, compilation >> loops? >> Can you do it synchronously? Execute method in separate thread and stop >> it when you get compilation of requested level or other condition >> (recursion level). Do deoptimization in main thread and see if methods >> are deoptimized. > > WB::deoptimizeFrames has to deoptimize methods which are currently on > stack, that's why I expect that checkCompiled on line 70 won't throw an > exception and that's why I do need these concurrent > deoptimization/compilation. So you are testing in first lines that if the compiled method does not have the frame on stack it will not be deoptimized - *comment* please. Again. I think the test will be simpler if you execute compiled method in a separate thread instead of main where you do all checks. Vladimir > >> >> Regards, >> Vladimir >> >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> Igor >>>>> >>>>> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >>>>>> Why you need new Unsafe.getCompiler()? >>>>>> >>>>>> thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>>>>>> 220 lines changed: 212 ins; 8 del; 0 mod; >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>>>>>> 4 lines changed: 4 ins; 0 del; 0 mod; >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> please review the patch which adds >>>>>>> - a new whitebox method 'deoptimizeFrames' which deoptimizes >>>>>>> methods >>>>>>> which are currently on stack >>>>>>> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net >>>>>>> which >>>>>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 >>>>>>> accordingly. >>>>>>> >>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>>>>>> testing: jprt + new added test >>>>>>> >>> > From david.holmes at oracle.com Tue Dec 9 01:10:12 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 09 Dec 2014 11:10:12 +1000 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <5485DA7E.5000906@oracle.com> References: <5485D68C.7040106@oracle.com> <5485DA7E.5000906@oracle.com> Message-ID: <54864BF4.3020302@oracle.com> On 9/12/2014 3:06 AM, Vladimir Kozlov wrote: > The webrev is wrong, should be > > http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.03/ > > which looks good. Agreed. Thanks for your patience everyone. David > Thanks, > Vladimir > > On 12/8/14 8:49 AM, Tatiana Pivovarova wrote: >> Hi all, >> >> please review this new patch >> >> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >> webrev: >> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ >> >> Problem: >> Need WhiteBox::allocateCodeBlob(long, int), currently only >> WhiteBox::allocateCodeBlob(int, int) exist. >> >> Solution: >> Add new function with check: >> >> 156 public long allocateCodeBlob(long size, int type) { >> 157 int intSize = (int) size; >> 158 if ((long) intSize != size || size < 0) { >> 159 throw new IllegalArgumentException( >> 160 "size argument has illegal value " + size); >> 161 } >> 162 return allocateCodeBlob( intSize, type); >> 163 } >> >> >> Test: jprt >> >> >> Thanks, >> Tatiana From manasthakur17 at gmail.com Tue Dec 9 03:46:17 2014 From: manasthakur17 at gmail.com (Manas Thakur) Date: Tue, 9 Dec 2014 09:16:17 +0530 Subject: Locating call sites of methods in C2 In-Reply-To: <3BC4BB0F-E901-4D59-95A5-BDC8B56D5B89@oracle.com> References: <64E2023B-8362-4ED2-B755-366FAA5B615D@gmail.com> <3BC4BB0F-E901-4D59-95A5-BDC8B56D5B89@oracle.com> Message-ID: <20931467-4789-48E0-8851-CF775AE34882@gmail.com> Hi Christian Yes, I am looking for something similar: at the time I am compiling bar(), I want to know the BCI of the invoke instruction, as well as the caller method, because of which bar() was added to the compile queue. Regards, Manas > On 08-Dec-2014, at 11:45 pm, Christian Thalinger wrote: > > >> On Dec 5, 2014, at 2:49 AM, Manas Thakur wrote: >> >> Hi >> >> Is there a way to access the call-site (possibly in terms of the bytecode offset) of a method being compiled by C2? Doesn?t the current compile task store it in some variable? > > I?m not sure I understand. Are you asking for the BCI (bytecode index) of the invoke instruction to method bar if you compile a method foo which calls bar: > > void foo() { > bar(); > } > >> >> Regards, >> Manas >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Tue Dec 9 09:34:13 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 09 Dec 2014 12:34:13 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> Message-ID: <5486C215.2090206@oracle.com> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. On 12/08/2014 09:59 AM, Staffan Larsen wrote: > I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. > > /Staffan > >> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >> >> Hi Staffan, >> >> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >> >> Thanks >> Igor >> >> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>> perhaps he has future plans for this. >>> Igor? >>> >>> Thanks, >>> Dmitrij >>>> Utils.ITERATION_COUNT does not look like something that is usable >>>> outside these specific tests? Should it really be part of the test >>>> library? >>>> >>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>> Pochepko wrote: >>>>> >>>>> Adding hotspot-dev for wider audience. >>>>>> Hi, >>>>>> >>>>>> Please review changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>> Test task: JMX- tests >>>>>> and >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>> in testlibrary for JDK-8059613 >>>>>> >>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>> testing thresholds, usage, >>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>> tests. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>> >>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>> >>>>>> Additional note: this patch assumes >>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>> is fixed. >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>> > -- Igor From aph at redhat.com Tue Dec 9 09:39:53 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 09 Dec 2014 09:39:53 +0000 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <5485DCB7.4010901@oracle.com> Message-ID: <5486C369.1050807@redhat.com> On 08/12/14 22:19, Brendan Gregg wrote: > It's a good idea, but I'm not sure the DWARF unwind approach is > suitable for dynamic JIT. I'm usually sampling at 99 Hertz. With > inlined symbols, just the perf.map file can become 10s of Mbytes, and > I assume the DWARF info would be similar. So the file would need to be > in a consistent state so that perf can begin reading it anytime, and > do stack walking based on what it reads, while at the same time > symbols may be compiled anytime and the map file would need to change. Valgrind has a nice solution to this: a high-speed DWARF unwinder cache which converts the unwind info into an internal form. Andrew. From erik.helin at oracle.com Tue Dec 9 09:51:20 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Dec 2014 10:51:20 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> Message-ID: <5486C618.6000105@oracle.com> On 2014-12-08 21:31, Brendan Gregg wrote: > G'Day Staffan, > > On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen > wrote: >> >>> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >>> > [...] >>> >>> And if the VM creates a /tmp/perf-.map file to save information about >>> JITed methods, the perf's post-profiling tool will find it and use it to >>> correlate sampled addresses it collected from the VM's executable anonymous >>> memory mappings to the method names. >> >> Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. > > In the .map file, no, at least not currently. > > However, consider the following perf sampled stack trace (this is from > my patched OpenJDK 8, with frame pointers): > > # perf record -F 99 -a -g -- sleep 10 > # perf script > [...] > java 10532 [008] 3444046.716431: cpu-clock: > 7fe919301c30 (/tmp/perf-10490.map) > 7fe91934d50c (/tmp/perf-10490.map) > 7fe9193a43d0 (/tmp/perf-10490.map) > 7fe9194ffcf0 (/tmp/perf-10490.map) > 7fe9195026d0 (/tmp/perf-10490.map) > 7fe9194ffc4c (/tmp/perf-10490.map) > 7fe91b6c440c (/tmp/perf-10490.map) > 7fe91afa9c00 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91df23630 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91acc7ea8 (/tmp/perf-10490.map) > 7fe91c4fa014 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe919007325 (/tmp/perf-10490.map) > 7fe9190004e7 (/tmp/perf-10490.map) > 7fe92f70670e JavaCalls::call_helper(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/am > 7fe92f707a3f JavaCalls::call_virtual(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-r > 7fe92f707edf JavaCalls::call_virtual(JavaValue*, Handle, > KlassHandle, Symbol*, Symbol*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/l > 7fe92f741668 thread_entry(JavaThread*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa555c8 JavaThread::thread_main_inner() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa5581c JavaThread::run() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92f916ba2 java_start(Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92ff95e9a start_thread (/lib/x86_64-linux-gnu/libpthread-2.15.so) > > perf script emits every sampled stack trace, which I normally do for > flame graph generation. If I had Johannes's perf-map-agent loaded, > then those hex addresses become Java method symbols. > > Note the timestamp on the cpu-clock line. > > So... It should be easy to change perf-map-agent to write a > timestamped map file, to a different location (so perf doesn't find > it). Use the same timestamp type as perf. Then, a little Perl wrapper > can take "perf script" output and translate the addresses based on the > timestamped map file. (perf itself can be enhanced to do this, > although the time frame for a perf change propagating to Linux users > may be years, so the Perl wrapper could be used in the meantime.) > > I haven't needed to do this yet. map file churn in production has been > small (depends on workload). The real pain for us is switching apps > from Oracle JDK to my patched OpenJDK, so we get the frame pointer. Another approach is outlined in the paper "Fast Java profiling with scheduling-aware stack fragment sampling and asynchronous analysis" [0]: use the perf system call to get 16kB of stack, then translate that asynchronously using JVMTI and then finally save the "decoded" stack trace to disk. This technique has the advantage of reusing all the knowledge already in the JVM about the stack and frame layout while still use perf for sampling. The drawback of this approach is that you would not be using the perf tool to set the probes, since the perf kernel utility is now started with the perf system call from a JVMTI agent. You would also have to translate an eventual native part and the kernel part of the stack trace yourself (probably by using some DWARF library). Thanks, Erik [0]: http://dl.acm.org/citation.cfm?doid=2647508.2647509 > Brendan > From erik.helin at oracle.com Tue Dec 9 09:53:00 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Dec 2014 10:53:00 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: <5486C67C.2030302@oracle.com> I applied the patch on top of jdk9/hs-comp and created a webrev: http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ I also successfully run the patch through JPRT. Thanks, Erik On 2014-12-05 20:57, Brendan Gregg wrote: > > > On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg > wrote: > > G'Day, > > I've hacked hotspot to return the frame pointer, in part to see what > this involves, and also to have a working prototype for analysis. > Along with an agent to resolve symbols, this has allowed full stack > profiling using Linux perf_events. The following flame graphs show > the resulting profiles. > > A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > Same thing, but this time disabling inlining, to show more frames: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg > > As expected, performance is worse without inlining. You can compare > the flame graphs side by side to see why. Less time spent doing work > / I/O! > > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > is my patch, > > [...] > > > In case there's problems with the patch URL, the patch is: > > --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad > 2014-03-04 02:52:11.000000000 +0000 > +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad > 2014-11-08 01:10:49.686044933 +0000 > @@ -166,10 +166,9 @@ > // 3) reg_class stack_slots( /* one chunk of stack-based "registers" */ ) > // > > -// Class for all pointer registers (including RSP) > +// Class for all pointer registers (including RSP, excluding RBP) > reg_class any_reg(RAX, RAX_H, > RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -184,10 +183,9 @@ > R14, R14_H, > R15, R15_H); > > -// Class for all pointer registers except RSP > +// Class for all pointer registers except RSP and RBP > reg_class ptr_reg(RAX, RAX_H, > RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -199,9 +197,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all pointer registers except RAX and RSP > +// Class for all pointer registers except RAX, RSP and RBP > reg_class ptr_no_rax_reg(RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -226,9 +223,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all pointer registers except RAX, RBX and RSP > +// Class for all pointer registers except RAX, RBX, RSP and RBP > reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -260,10 +256,9 @@ > // Singleton class for TLS pointer > reg_class ptr_r15_reg(R15, R15_H); > > -// Class for all long registers (except RSP) > +// Class for all long registers (except RSP and RBP) > reg_class long_reg(RAX, RAX_H, > RDX, RDX_H, > - RBP, RBP_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -275,9 +270,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all long registers except RAX, RDX (and RSP) > -reg_class long_no_rax_rdx_reg(RBP, RBP_H, > - RDI, RDI_H, > +// Class for all long registers except RAX, RDX (and RSP, RBP) > +reg_class long_no_rax_rdx_reg(RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > RBX, RBX_H, > @@ -288,9 +282,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all long registers except RCX (and RSP) > -reg_class long_no_rcx_reg(RBP, RBP_H, > - RDI, RDI_H, > +// Class for all long registers except RCX (and RSP, RBP) > +reg_class long_no_rcx_reg(RDI, RDI_H, > RSI, RSI_H, > RAX, RAX_H, > RDX, RDX_H, > @@ -302,9 +295,8 @@ > R13, R13_H, > R14, R14_H); > > -// Class for all long registers except RAX (and RSP) > -reg_class long_no_rax_reg(RBP, RBP_H, > - RDX, RDX_H, > +// Class for all long registers except RAX (and RSP, RBP) > +reg_class long_no_rax_reg(RDX, RDX_H, > RDI, RDI_H, > RSI, RSI_H, > RCX, RCX_H, > @@ -325,10 +317,9 @@ > // Singleton class for RDX long register > reg_class long_rdx_reg(RDX, RDX_H); > > -// Class for all int registers (except RSP) > +// Class for all int registers (except RSP and RBP) > reg_class int_reg(RAX, > RDX, > - RBP, > RDI, > RSI, > RCX, > @@ -340,10 +331,9 @@ > R13, > R14); > > -// Class for all int registers except RCX (and RSP) > +// Class for all int registers except RCX (and RSP, RBP) > reg_class int_no_rcx_reg(RAX, > RDX, > - RBP, > RDI, > RSI, > RBX, > @@ -355,8 +345,7 @@ > R14); > > // Class for all int registers except RAX, RDX (and RSP) > -reg_class int_no_rax_rdx_reg(RBP, > - RDI, > +reg_class int_no_rax_rdx_reg(RDI, > RSI, > RCX, > RBX, > @@ -718,6 +707,7 @@ > st->print("# stack bang"); > st->print("\n\t"); > st->print("pushq rbp\t# Save rbp"); > + // BDG consider: st->print("movq rbp, rsp\t# "); > if (framesize) { > st->print("\n\t"); > st->print("subq rsp, #%d\t# Create frame",framesize); > --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp > 2014-03-04 02:52:11.000000000 +0000 > +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-11-07 > 23:57:11.589593723 +0000 > @@ -5236,6 +5236,7 @@ > // We always push rbp, so that on return to interpreter rbp, will be > // restored correctly and we can correct the stack. > push(rbp); > + mov(rbp, rsp); > // Remove word for ebp > framesize -= wordSize; > > --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp > 2014-03-04 02:52:10.000000000 +0000 > +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp > 2014-11-07 23:57:21.933257882 +0000 > @@ -358,6 +358,7 @@ > generate_stack_overflow_check(frame_size_in_bytes); > > push(rbp); > + mov(rbp, rsp); > #ifdef TIERED > // c2 leaves fpu stack dirty. Clean it on entry > if (UseSSE < 2 ) { > > > Brendan From staffan.larsen at oracle.com Tue Dec 9 09:59:30 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 9 Dec 2014 10:59:30 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5486C215.2090206@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> Message-ID: But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? /Staffan > On 9 dec 2014, at 10:34, Igor Ignatyev wrote: > > Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. > > On 12/08/2014 09:59 AM, Staffan Larsen wrote: >> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >> >> /Staffan >> >>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>> >>> Hi Staffan, >>> >>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>> >>> Thanks >>> Igor >>> >>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>> perhaps he has future plans for this. >>>> Igor? >>>> >>>> Thanks, >>>> Dmitrij >>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>> outside these specific tests? Should it really be part of the test >>>>> library? >>>>> >>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>> Pochepko wrote: >>>>>> >>>>>> Adding hotspot-dev for wider audience. >>>>>>> Hi, >>>>>>> >>>>>>> Please review changes for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>> Test task: JMX- tests >>>>>>> and >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>> in testlibrary for JDK-8059613 >>>>>>> >>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>> testing thresholds, usage, >>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>> tests. >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>> >>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>> >>>>>>> Additional note: this patch assumes >>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>> is fixed. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>> >> > > -- > Igor From staffan.larsen at oracle.com Tue Dec 9 10:09:46 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 9 Dec 2014 11:09:46 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: <5485BE52.9000500@us.ibm.com> <03E1392A-CEDE-42D7-835F-3F67B1FF8B7F@oracle.com> Message-ID: > On 8 dec 2014, at 21:31, Brendan Gregg wrote: > > G'Day Staffan, > > On Mon, Dec 8, 2014 at 11:17 AM, Staffan Larsen > wrote: >> >>> On 8 dec 2014, at 16:05, Maynard Johnson wrote: >>> > [...] >>> >>> And if the VM creates a /tmp/perf-.map file to save information about >>> JITed methods, the perf's post-profiling tool will find it and use it to >>> correlate sampled addresses it collected from the VM's executable anonymous >>> memory mappings to the method names. >> >> Is there a way in this .map file to express that different JITed methods are located at the same address at different times? This typically happens a lot when classes and their JITed methods are being unloaded from the VM. That space will be reused by a different method. I?m guessing this would confuse perf. > > In the .map file, no, at least not currently. > > However, consider the following perf sampled stack trace (this is from > my patched OpenJDK 8, with frame pointers): > > # perf record -F 99 -a -g -- sleep 10 > # perf script > [...] > java 10532 [008] 3444046.716431: cpu-clock: > 7fe919301c30 (/tmp/perf-10490.map) > 7fe91934d50c (/tmp/perf-10490.map) > 7fe9193a43d0 (/tmp/perf-10490.map) > 7fe9194ffcf0 (/tmp/perf-10490.map) > 7fe9195026d0 (/tmp/perf-10490.map) > 7fe9194ffc4c (/tmp/perf-10490.map) > 7fe91b6c440c (/tmp/perf-10490.map) > 7fe91afa9c00 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91df23630 (/tmp/perf-10490.map) > 7fe91ab739f4 (/tmp/perf-10490.map) > 7fe91acc7ea8 (/tmp/perf-10490.map) > 7fe91c4fa014 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe9190072e0 (/tmp/perf-10490.map) > 7fe919007325 (/tmp/perf-10490.map) > 7fe9190004e7 (/tmp/perf-10490.map) > 7fe92f70670e JavaCalls::call_helper(JavaValue*, > methodHandle*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/am > 7fe92f707a3f JavaCalls::call_virtual(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-r > 7fe92f707edf JavaCalls::call_virtual(JavaValue*, Handle, > KlassHandle, Symbol*, Symbol*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/l > 7fe92f741668 thread_entry(JavaThread*, Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa555c8 JavaThread::thread_main_inner() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92fa5581c JavaThread::run() > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92f916ba2 java_start(Thread*) > (/mnt/openjdk8/build/linux-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so) > 7fe92ff95e9a start_thread (/lib/x86_64-linux-gnu/libpthread-2.15.so) > > perf script emits every sampled stack trace, which I normally do for > flame graph generation. If I had Johannes's perf-map-agent loaded, > then those hex addresses become Java method symbols. > > Note the timestamp on the cpu-clock line. > > So... It should be easy to change perf-map-agent to write a > timestamped map file, to a different location (so perf doesn't find > it). Use the same timestamp type as perf. Then, a little Perl wrapper > can take "perf script" output and translate the addresses based on the > timestamped map file. (perf itself can be enhanced to do this, > although the time frame for a perf change propagating to Linux users > may be years, so the Perl wrapper could be used in the meantime.) I see. Thanks for explaining! /Staffan > > I haven't needed to do this yet. map file churn in production has been > small (depends on workload). The real pain for us is switching apps > from Oracle JDK to my patched OpenJDK, so we get the frame pointer. > > Brendan From igor.ignatyev at oracle.com Tue Dec 9 10:11:08 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 09 Dec 2014 13:11:08 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> Message-ID: <5486CABC.9090107@oracle.com> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) for all of these cases, I'd like to use one variable. Thanks, Igor On 12/09/2014 12:59 PM, Staffan Larsen wrote: > But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? > > /Staffan > > >> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >> >> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >> >> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>> >>> /Staffan >>> >>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>> >>>> Hi Staffan, >>>> >>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>> >>>> Thanks >>>> Igor >>>> >>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>> perhaps he has future plans for this. >>>>> Igor? >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>> outside these specific tests? Should it really be part of the test >>>>>> library? >>>>>> >>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>> Pochepko wrote: >>>>>>> >>>>>>> Adding hotspot-dev for wider audience. >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review changes for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>> Test task: JMX- tests >>>>>>>> and >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>> in testlibrary for JDK-8059613 >>>>>>>> >>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>> testing thresholds, usage, >>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>> tests. >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>> >>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>> >>>>>>>> Additional note: this patch assumes >>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>> is fixed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>> >>> >> >> -- >> Igor > -- Igor From erik.helin at oracle.com Tue Dec 9 10:14:54 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 09 Dec 2014 11:14:54 +0100 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: <5486C67C.2030302@oracle.com> References: <5486C67C.2030302@oracle.com> Message-ID: <5486CB9E.2090505@oracle.com> I should also add that I don't have enough knowledge of the compiler internals to review this patch, sorry. Thanks, Erik On 2014-12-09 10:53, Erik Helin wrote: > I applied the patch on top of jdk9/hs-comp and created a webrev: > http://cr.openjdk.java.net/~ehelin/brendan/frame-pointer/webrev/ > > I also successfully run the patch through JPRT. > > Thanks, > Erik > > On 2014-12-05 20:57, Brendan Gregg wrote: >> >> >> On Thu, Dec 4, 2014 at 2:55 PM, Brendan Gregg > > wrote: >> >> G'Day, >> >> I've hacked hotspot to return the frame pointer, in part to see what >> this involves, and also to have a working prototype for analysis. >> Along with an agent to resolve symbols, this has allowed full stack >> profiling using Linux perf_events. The following flame graphs show >> the resulting profiles. >> >> A mixed mode CPU flame graph of a vert.x benchmark (click to zoom): >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg >> >> Same thing, but this time disabling inlining, to show more frames: >> >> http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-flamegraph.svg >> >> As expected, performance is worse without inlining. You can compare >> the flame graphs side by side to see why. Less time spent doing work >> / I/O! >> >> >> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >> >> is my patch, >> >> [...] >> >> >> In case there's problems with the patch URL, the patch is: >> >> --- openjdk8clean/hotspot/src/cpu/x86/vm/x86_64.ad >> 2014-03-04 02:52:11.000000000 +0000 >> +++ openjdk8/hotspot/src/cpu/x86/vm/x86_64.ad >> 2014-11-08 01:10:49.686044933 +0000 >> @@ -166,10 +166,9 @@ >> // 3) reg_class stack_slots( /* one chunk of stack-based "registers" >> */ ) >> // >> >> -// Class for all pointer registers (including RSP) >> +// Class for all pointer registers (including RSP, excluding RBP) >> reg_class any_reg(RAX, RAX_H, >> RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -184,10 +183,9 @@ >> R14, R14_H, >> R15, R15_H); >> >> -// Class for all pointer registers except RSP >> +// Class for all pointer registers except RSP and RBP >> reg_class ptr_reg(RAX, RAX_H, >> RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -199,9 +197,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all pointer registers except RAX and RSP >> +// Class for all pointer registers except RAX, RSP and RBP >> reg_class ptr_no_rax_reg(RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -226,9 +223,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all pointer registers except RAX, RBX and RSP >> +// Class for all pointer registers except RAX, RBX, RSP and RBP >> reg_class ptr_no_rax_rbx_reg(RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -260,10 +256,9 @@ >> // Singleton class for TLS pointer >> reg_class ptr_r15_reg(R15, R15_H); >> >> -// Class for all long registers (except RSP) >> +// Class for all long registers (except RSP and RBP) >> reg_class long_reg(RAX, RAX_H, >> RDX, RDX_H, >> - RBP, RBP_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -275,9 +270,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all long registers except RAX, RDX (and RSP) >> -reg_class long_no_rax_rdx_reg(RBP, RBP_H, >> - RDI, RDI_H, >> +// Class for all long registers except RAX, RDX (and RSP, RBP) >> +reg_class long_no_rax_rdx_reg(RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> RBX, RBX_H, >> @@ -288,9 +282,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all long registers except RCX (and RSP) >> -reg_class long_no_rcx_reg(RBP, RBP_H, >> - RDI, RDI_H, >> +// Class for all long registers except RCX (and RSP, RBP) >> +reg_class long_no_rcx_reg(RDI, RDI_H, >> RSI, RSI_H, >> RAX, RAX_H, >> RDX, RDX_H, >> @@ -302,9 +295,8 @@ >> R13, R13_H, >> R14, R14_H); >> >> -// Class for all long registers except RAX (and RSP) >> -reg_class long_no_rax_reg(RBP, RBP_H, >> - RDX, RDX_H, >> +// Class for all long registers except RAX (and RSP, RBP) >> +reg_class long_no_rax_reg(RDX, RDX_H, >> RDI, RDI_H, >> RSI, RSI_H, >> RCX, RCX_H, >> @@ -325,10 +317,9 @@ >> // Singleton class for RDX long register >> reg_class long_rdx_reg(RDX, RDX_H); >> >> -// Class for all int registers (except RSP) >> +// Class for all int registers (except RSP and RBP) >> reg_class int_reg(RAX, >> RDX, >> - RBP, >> RDI, >> RSI, >> RCX, >> @@ -340,10 +331,9 @@ >> R13, >> R14); >> >> -// Class for all int registers except RCX (and RSP) >> +// Class for all int registers except RCX (and RSP, RBP) >> reg_class int_no_rcx_reg(RAX, >> RDX, >> - RBP, >> RDI, >> RSI, >> RBX, >> @@ -355,8 +345,7 @@ >> R14); >> >> // Class for all int registers except RAX, RDX (and RSP) >> -reg_class int_no_rax_rdx_reg(RBP, >> - RDI, >> +reg_class int_no_rax_rdx_reg(RDI, >> RSI, >> RCX, >> RBX, >> @@ -718,6 +707,7 @@ >> st->print("# stack bang"); >> st->print("\n\t"); >> st->print("pushq rbp\t# Save rbp"); >> + // BDG consider: st->print("movq rbp, rsp\t# "); >> if (framesize) { >> st->print("\n\t"); >> st->print("subq rsp, #%d\t# Create frame",framesize); >> --- openjdk8clean/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp >> 2014-03-04 02:52:11.000000000 +0000 >> +++ openjdk8/hotspot/src/cpu/x86/vm/macroAssembler_x86.cpp 2014-11-07 >> 23:57:11.589593723 +0000 >> @@ -5236,6 +5236,7 @@ >> // We always push rbp, so that on return to interpreter rbp, >> will be >> // restored correctly and we can correct the stack. >> push(rbp); >> + mov(rbp, rsp); >> // Remove word for ebp >> framesize -= wordSize; >> >> --- openjdk8clean/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >> 2014-03-04 02:52:10.000000000 +0000 >> +++ openjdk8/hotspot/src/cpu/x86/vm/c1_MacroAssembler_x86.cpp >> 2014-11-07 23:57:21.933257882 +0000 >> @@ -358,6 +358,7 @@ >> generate_stack_overflow_check(frame_size_in_bytes); >> >> push(rbp); >> + mov(rbp, rsp); >> #ifdef TIERED >> // c2 leaves fpu stack dirty. Clean it on entry >> if (UseSSE < 2 ) { >> >> >> Brendan From staffan.larsen at oracle.com Tue Dec 9 10:20:45 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 9 Dec 2014 11:20:45 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5486CABC.9090107@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> Message-ID: > On 9 dec 2014, at 11:11, Igor Ignatyev wrote: > > I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. > > another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. > > also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) > > for all of these cases, I'd like to use one variable. But these look like three different counters to me? And for some tests all three counter could possibly be needed. I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. /Staffan > > Thanks, > Igor > > On 12/09/2014 12:59 PM, Staffan Larsen wrote: >> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >> >> /Staffan >> >> >>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>> >>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>> >>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>> >>>> /Staffan >>>> >>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>> >>>>> Hi Staffan, >>>>> >>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>> >>>>> Thanks >>>>> Igor >>>>> >>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>> perhaps he has future plans for this. >>>>>> Igor? >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>> outside these specific tests? Should it really be part of the test >>>>>>> library? >>>>>>> >>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>> Pochepko wrote: >>>>>>>> >>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review changes for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>> Test task: JMX- tests >>>>>>>>> and >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>> >>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>> testing thresholds, usage, >>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>> tests. >>>>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>> >>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>> >>>>>>>>> Additional note: this patch assumes >>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>> is fixed. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>> >>>> >>> >>> -- >>> Igor >> > > -- > Igor From igor.ignatyev at oracle.com Tue Dec 9 10:36:35 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 09 Dec 2014 13:36:35 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> Message-ID: <5486D0B3.5060209@oracle.com> On 12/09/2014 01:20 PM, Staffan Larsen wrote: > >> On 9 dec 2014, at 11:11, Igor Ignatyev wrote: >> >> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. >> >> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. >> >> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) >> >> for all of these cases, I'd like to use one variable. > > But these look like three different counters to me? And for some tests all three counter could possibly be needed. > > I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib? // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one. -- Igor > > /Staffan > >> >> Thanks, >> Igor >> >> On 12/09/2014 12:59 PM, Staffan Larsen wrote: >>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >>> >>> /Staffan >>> >>> >>>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>>> >>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>>> >>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>>> >>>>> /Staffan >>>>> >>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>>> >>>>>> Thanks >>>>>> Igor >>>>>> >>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>>> perhaps he has future plans for this. >>>>>>> Igor? >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>>> outside these specific tests? Should it really be part of the test >>>>>>>> library? >>>>>>>> >>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>>> Pochepko wrote: >>>>>>>>> >>>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review changes for >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>>> Test task: JMX- tests >>>>>>>>>> and >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>>> >>>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>>> testing thresholds, usage, >>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>>> tests. >>>>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>>> >>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>>> >>>>>>>>>> Additional note: this patch assumes >>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>>> is fixed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>> >>>>> >>>> >>>> -- >>>> Igor >>> >> >> -- >> Igor > From tatiana.pivovarova at oracle.com Tue Dec 9 11:15:31 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Tue, 09 Dec 2014 14:15:31 +0300 Subject: RFR (XS): 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented In-Reply-To: <54864BF4.3020302@oracle.com> References: <5485D68C.7040106@oracle.com> <5485DA7E.5000906@oracle.com> <54864BF4.3020302@oracle.com> Message-ID: <5486D9D3.8070103@oracle.com> Hi Vladimir, David Thank you very much for your careful review and valuable notes! Tatiana On 12/09/2014 04:10 AM, David Holmes wrote: > On 9/12/2014 3:06 AM, Vladimir Kozlov wrote: >> The webrev is wrong, should be >> >> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.03/ >> >> which looks good. > > Agreed. > > Thanks for your patience everyone. > > David > >> Thanks, >> Vladimir >> >> On 12/8/14 8:49 AM, Tatiana Pivovarova wrote: >>> Hi all, >>> >>> please review this new patch >>> >>> bugid: https://bugs.openjdk.java.net/browse/JDK-8065134 >>> webrev: >>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8065134/webrev.02/ >>> >>> Problem: >>> Need WhiteBox::allocateCodeBlob(long, int), currently only >>> WhiteBox::allocateCodeBlob(int, int) exist. >>> >>> Solution: >>> Add new function with check: >>> >>> 156 public long allocateCodeBlob(long size, int type) { >>> 157 int intSize = (int) size; >>> 158 if ((long) intSize != size || size < 0) { >>> 159 throw new IllegalArgumentException( >>> 160 "size argument has illegal value " + size); >>> 161 } >>> 162 return allocateCodeBlob( intSize, type); >>> 163 } >>> >>> >>> Test: jprt >>> >>> >>> Thanks, >>> Tatiana From staffan.larsen at oracle.com Tue Dec 9 12:22:07 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 9 Dec 2014 13:22:07 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5486D0B3.5060209@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> <5486D0B3.5060209@oracle.com> Message-ID: <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com> I would favor a solution where the iteration count is an argument to the test instead of being a global variable. /Staffan > On 9 dec 2014, at 11:36, Igor Ignatyev wrote: > > On 12/09/2014 01:20 PM, Staffan Larsen wrote: >> >>> On 9 dec 2014, at 11:11, Igor Ignatyev wrote: >>> >>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. >>> >>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. >>> >>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) >>> >>> for all of these cases, I'd like to use one variable. >> >> But these look like three different counters to me? And for some tests all three counter could possibly be needed. >> >> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. > well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib? > > // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one. > > -- Igor >> >> /Staffan >> >>> >>> Thanks, >>> Igor >>> >>> On 12/09/2014 12:59 PM, Staffan Larsen wrote: >>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >>>> >>>> /Staffan >>>> >>>> >>>>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>>>> >>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>>>> >>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>>>> >>>>>> /Staffan >>>>>> >>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>>>> >>>>>>> Hi Staffan, >>>>>>> >>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>>>> >>>>>>> Thanks >>>>>>> Igor >>>>>>> >>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>>>> perhaps he has future plans for this. >>>>>>>> Igor? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>>>> outside these specific tests? Should it really be part of the test >>>>>>>>> library? >>>>>>>>> >>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>>>> Pochepko wrote: >>>>>>>>>> >>>>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please review changes for >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>>>> Test task: JMX- tests >>>>>>>>>>> and >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>>>> >>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>>>> testing thresholds, usage, >>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>>>> tests. >>>>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>>>> >>>>>>>>>>> Additional note: this patch assumes >>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>>>> is fixed. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Igor >>>> >>> >>> -- >>> Igor >> From igor.ignatyev at oracle.com Tue Dec 9 12:51:09 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 09 Dec 2014 15:51:09 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> <5486D0B3.5060209@oracle.com> <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com> Message-ID: <5486F03D.6060608@oracle.com> this solution doesn't allow us to change iteration count for all tests. Igor On 12/09/2014 03:22 PM, Staffan Larsen wrote: > I would favor a solution where the iteration count is an argument to the test instead of being a global variable. > > /Staffan > >> On 9 dec 2014, at 11:36, Igor Ignatyev wrote: >> >> On 12/09/2014 01:20 PM, Staffan Larsen wrote: >>> >>>> On 9 dec 2014, at 11:11, Igor Ignatyev wrote: >>>> >>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. >>>> >>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. >>>> >>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) >>>> >>>> for all of these cases, I'd like to use one variable. >>> >>> But these look like three different counters to me? And for some tests all three counter could possibly be needed. >>> >>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. >> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib? >> >> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one. >> >> -- Igor >>> >>> /Staffan >>> >>>> >>>> Thanks, >>>> Igor >>>> >>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote: >>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >>>>> >>>>> /Staffan >>>>> >>>>> >>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>>>>> >>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>>>>> >>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>>>>> >>>>>>>> Hi Staffan, >>>>>>>> >>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Igor >>>>>>>> >>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>>>>> perhaps he has future plans for this. >>>>>>>>> Igor? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>>>>> outside these specific tests? Should it really be part of the test >>>>>>>>>> library? >>>>>>>>>> >>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>>>>> Pochepko wrote: >>>>>>>>>>> >>>>>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Please review changes for >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>>>>> Test task: JMX- tests >>>>>>>>>>>> and >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>>>>> >>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>>>>> testing thresholds, usage, >>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>>>>> tests. >>>>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>>>>> >>>>>>>>>>>> Additional note: this patch assumes >>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>>>>> is fixed. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dmitrij >>>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Igor >>>>> >>>> >>>> -- >>>> Igor >>> > From maynardj at us.ibm.com Mon Dec 8 15:05:54 2014 From: maynardj at us.ibm.com (Maynard Johnson) Date: Mon, 08 Dec 2014 09:05:54 -0600 Subject: A hotspot patch for stack profiling (frame pointer) In-Reply-To: References: Message-ID: <5485BE52.9000500@us.ibm.com> On 12/05/2014 05:09 PM, Brendan Gregg wrote: > G'Day Volker, > > On Fri, Dec 5, 2014 at 11:22 AM, Volker Simonis > wrote: >> Hi Brendan, >> >> I'm still not understanding who is taking the actual stack traces (let >> alone the symbols) in your examples. Is this done by 'perf' itself >> based only on the frame pointer? > > perf is walking the frame pointers. Volker, to be specific, the perf profiling tool has a user space part and a kernel space part. The collection of stack traces is done by the kernel. When a user-specified event (or series of events) occur, the process being profiled is interrupted and the sampled information (which can optionally include a full stack trace) is made available to the user space perf tool to be saved to a file for future post-profiling processing. During the profiling phase, the perf tool collects information about the profiled process's memory mappings, which allows for this address-to-symbol. resolution, It's in the post-profiling phase where the sampled instruction, along with its associated stack trace, are resolved to the appropriate symbol (i.e., function/method) in a specific binary file (e.g., library, exectuable). And if the VM creates a /tmp/perf-.map file to save information about JITed methods, the perf's post-profiling tool will find it and use it to correlate sampled addresses it collected from the VM's executable anonymous memory mappings to the method names. -Maynard > > A JVMTI agent, perf-map-agent, is providing a map file for symbol > translation under /tmp/perf-PID.map. Linux perf already hunts for such > a file when doing symbol translation. > >> >> As I wrote before, this is pretty hard to get right for a JVM, but >> there are good approximations. Have you looked at the 'jstack' tool >> which is part of the JDK? If you run it on a Java process, it will >> give you exact stack traces with full inlining information. However >> this only works at safepoints so it is probably not suitable for >> profiling with performance counters. > > Right, jstack works, and I get full correct stacks. I do really want > to take stacks at any moment: not just CPU samples, but when tracing > kernel TCP events, or PMC cache miss profiling, etc. perf can already > do many advanced tracing and profiling activities. I just needed the > Java stacks for context. > >> But you can also use 'jstack -F >> -m' which gives you a 'best effort' mixed Java/C++ stacaktrace (most >> of the time even with inlined Java frames. This is probably the best >> you can get when interrupting a running JVM at an arbitrary point in >> time. As you mentioned in one of your blogs, the VM can be in the >> C-Library or even in the kernel at that time which don't preserve the >> frame pointer either. So it will be already hard to even walk up to >> the first Java frame. > > Well, the JVMs I'm looking at are already built with > -fno-omit-frame-pointer (which is good). I edited hotspot to preserve > it as well. > > Here's before I changed hotspot: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-nofp.svg > > Yes, most stacks are clearly broken. > > After changing hotspot: > > http://www.brendangregg.com/FlameGraphs/cpu-mixedmode-vertx.svg > > It's looking pretty good. If you look carefully on the far left and > right, there are 0.8% stacks in read() and write() directly from java, > which may well be broken (unless a java thread is calling these > directly; there could also be some gcc inlining going on). Even if > they are broken, I can see 98% of my profile. Plus, I'd be interested > to know what exactly is reusing the frame pointer, so we could fix > that too. > > The Java stacks themselves are also about a third as deep as they > should be, due to inlining. > >> >> But nevertheless, if the output of 'jstack -F -m' is "good enough" for >> your purpose, you can implement something similar in 'perf' or a >> helper library of 'perf' and be happy (I don't actually know how perf >> takes stack traces but I suppose there may some kind of callback >> mechanism for walking unknown frames). This is actually not so hard. >> I've recently implemented a "print_native_stack()" function within >> hotspot itself (you can call it for example from gdb during debugging >> - see http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86183a940db4). >> Maye you could call this functions directly from 'perf' if perf >> attaches with ptrace to the process (I assume it does or how else >> could it walk the stack)? > > An OS-cooperative stack walker would be great, and I think the hotspot > team is already doing this for Oracle Solaris. Thanks for the code > too, this is pretty interesting. > > jstack -F -m eats 0.5s of CPU for me, so it would need work to make > this into a 99 Hertz-capable profiler. Plus I'd like to pick arbitrary > kernel functions or tracepoints and get Java context from them, too. > Eg, TCP functions, memory allocation, disk I/O, etc. > >> >> These were just some random thoughts with the hope that they may be helpful. > > Yes, thanks! > > Brendan > From pavel.chistyakov at oracle.com Tue Dec 9 16:50:16 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Tue, 09 Dec 2014 19:50:16 +0300 Subject: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout Message-ID: <54872848.2050002@oracle.com> Hi all, please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066896 webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066896/webrev.00/ Problem: InfiniteLoop allows zero value as timeout and waste time for Thread.sleep(0) call that is not needed in this case. Solution: Add a condition for skipping 0 (zero) timeout when calling Thread.sleep Testing: manual ------------------- Thanks, Pavel From pavel.chistyakov at oracle.com Tue Dec 9 16:50:24 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Tue, 09 Dec 2014 19:50:24 +0300 Subject: RFR (XXS): 8066473: Port timeout utils from jdk test library into hotspot Message-ID: <54872850.1060508@oracle.com> Hi all, please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066473 webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066473/webrev.00/ We need some timeout staff that exists in jdk testlibrary in hotspot tests. This fix ports DEFAULT_TEST_TIMEOUT constant and adjustTimeout method. Testing: manual ------------------- Thanks, Pavel From pavel.chistyakov at oracle.com Tue Dec 9 16:50:28 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Tue, 09 Dec 2014 19:50:28 +0300 Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class Message-ID: <54872854.90806@oracle.com> Hi all, please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066497 webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ Problem: ByteCodeLoader allows one to load class with given name from existing bytecode. But if this class is already loaded by e.g. system classloader it cannot be redefined using another bytecode array because of delegation of loadClass call to parent classloader. Solution: override loadClass to break delegation for given className. Testing: manual ------------------- Thanks, Pavel From pavel.chistyakov at oracle.com Tue Dec 9 16:50:34 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Tue, 09 Dec 2014 19:50:34 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests Message-ID: <5487285A.8000402@oracle.com> Hi all, please review changes for: https://bugs.openjdk.java.net/browse/JDK-8059551 webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.00/ It introduces several stress tests for segmented code cache. There are main thread that calls given method and checks its return value and several testing threads: * OverloadCompileQueueTest - locks compilation for random time periods trying to full compile queues and to break tested method compilation; * RandomAllocationTest - randomly allocates and removes "dummy" code blobs in different code cache heaps tries to corrupt tested method code in code cache; * UnexpectedDeoptimizationTest - deoptimizes on stack frames in random times tries to break tested method execution/return value Testing: manual ------------------- Thanks, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.westrelin at oracle.com Tue Dec 9 18:04:49 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 9 Dec 2014 19:04:49 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> Message-ID: >>> That's good; let's do it that way! >>> >>> Final suggestion (really): Add some more test cases, containing duplicate array indexes, to exercise the "local" logic. >> >> Thanks John. I?ll add some test cases. Do you want to see another webrev with test cases? > > I'd like to look at it, so please update the webrev, but you can proceed with a thumbs up from me as a reviewer no matter what. Here is a new webrev for the change I intend to push today: http://cr.openjdk.java.net/~roland/8066103/webrev.04/ It has more test cases and the previous change had some leftover code: 939 if (rc0.ctl->in(0)->in(1) == in(1)) { 940 // If we match the test exactly, then the top test covers 941 // both our lower and upper bounds. Valid only if there's no 942 // other range check between us and the top test: for all we 943 // know this range check was widened and accesses that 944 // depend on it also depend on the previous range checks to 945 // be correct. 946 prev_dom = rc0.ctl; 947 } else { Roland. From igor.veresov at oracle.com Tue Dec 9 18:05:10 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 9 Dec 2014 10:05:10 -0800 Subject: RFR(XXS) 8066900: Array Out Of Bounds Exception causes variable corruption Message-ID: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> C1 does the opposite of the right thing when saving the registers during exception handling on x86. Other platforms seem fine. Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Dec 9 18:47:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Dec 2014 10:47:29 -0800 Subject: RFR(XXS) 8066900: Array Out Of Bounds Exception causes variable corruption In-Reply-To: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> References: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> Message-ID: <548743C1.2050504@oracle.com> Looks good. Thanks, Vladimir On 12/9/14 10:05 AM, Igor Veresov wrote: > C1 does the opposite of the right thing when saving the registers during > exception handling on x86. Other platforms seem fine. > > Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ > > Thanks, > igor From vladimir.x.ivanov at oracle.com Tue Dec 9 18:54:06 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 09 Dec 2014 21:54:06 +0300 Subject: RFR(XXS) 8066900: Array Out Of Bounds Exception causes variable corruption In-Reply-To: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> References: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> Message-ID: <5487454E.1050705@oracle.com> Looks good. Can you use 4 space indentation in the test? Best regards, Vladimir Ivanov On 12/9/14, 9:05 PM, Igor Veresov wrote: > C1 does the opposite of the right thing when saving the registers during > exception handling on x86. Other platforms seem fine. > > Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ > > Thanks, > igor From john.r.rose at oracle.com Tue Dec 9 18:59:02 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 9 Dec 2014 10:59:02 -0800 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> Message-ID: <54FE848F-42DF-4EE4-8117-61065068EEE1@oracle.com> Thumbs up. ? John > On Dec 9, 2014, at 10:04 AM, Roland Westrelin wrote: > >>>> That's good; let's do it that way! >>>> >>>> Final suggestion (really): Add some more test cases, containing duplicate array indexes, to exercise the "local" logic. >>> >>> Thanks John. I?ll add some test cases. Do you want to see another webrev with test cases? >> >> I'd like to look at it, so please update the webrev, but you can proceed with a thumbs up from me as a reviewer no matter what. > > Here is a new webrev for the change I intend to push today: > > http://cr.openjdk.java.net/~roland/8066103/webrev.04/ > > It has more test cases and the previous change had some leftover code: > > 939 if (rc0.ctl->in(0)->in(1) == in(1)) { > 940 // If we match the test exactly, then the top test covers > > 941 // both our lower and upper bounds. Valid only if there's no > 942 // other range check between us and the top test: for all we > 943 // know this range check was widened and accesses that > 944 // depend on it also depend on the previous range checks to > 945 // be correct. > > 946 prev_dom = rc0.ctl; > 947 } else { > > Roland. From igor.veresov at oracle.com Tue Dec 9 19:07:19 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 9 Dec 2014 11:07:19 -0800 Subject: RFR(XXS) 8066900: Array Out Of Bounds Exception causes variable corruption In-Reply-To: <5487454E.1050705@oracle.com> References: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> <5487454E.1050705@oracle.com> Message-ID: <28FDF3DC-FA2E-48E4-93B8-6CFC3D3C0219@oracle.com> > On Dec 9, 2014, at 10:54 AM, Vladimir Ivanov wrote: > > Looks good. > Thanks! > Can you use 4 space indentation in the test? > Sure, I?ll fix that. > Best regards, > Vladimir Ivanov > > On 12/9/14, 9:05 PM, Igor Veresov wrote: >> C1 does the opposite of the right thing when saving the registers during >> exception handling on x86. Other platforms seem fine. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ >> >> Thanks, >> igor From igor.veresov at oracle.com Tue Dec 9 19:07:46 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 9 Dec 2014 11:07:46 -0800 Subject: RFR(XXS) 8066900: Array Out Of Bounds Exception causes variable corruption In-Reply-To: <548743C1.2050504@oracle.com> References: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> <548743C1.2050504@oracle.com> Message-ID: Thanks! igor > On Dec 9, 2014, at 10:47 AM, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 12/9/14 10:05 AM, Igor Veresov wrote: >> C1 does the opposite of the right thing when saving the registers during >> exception handling on x86. Other platforms seem fine. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ >> >> Thanks, >> igor From roland.westrelin at oracle.com Tue Dec 9 19:58:25 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 9 Dec 2014 20:58:25 +0100 Subject: 8066103: C2's range check smearing allows out of bound array accesses In-Reply-To: <54FE848F-42DF-4EE4-8117-61065068EEE1@oracle.com> References: <94EB1591-8E63-43AC-B754-9712B78C2D58@oracle.com> <547CB882.8040500@oracle.com> <6E161E36-2729-4A88-9DBE-06FA81AC53DD@oracle.com> <799C073C-24FC-40A6-996F-DE9D8766B4F0@oracle.com> <4E964FB9-36A1-42F0-916E-47D5F590D0D3@oracle.com> <56AA8155-FDBF-4450-A097-9CC8D6393F86@oracle.com> <02BC2D03-11AA-407B-8927-24484EF590D1@oracle.com> <4C1F6E0A-75FE-444F-9451-0B629865816A@oracle.com> <52439D82-C0D4-4304-BEA2-13E25E4A56A9@oracle.com> <54FE848F-42DF-4EE4-8117-61065068EEE1@oracle.com> Message-ID: Thanks. Roland. > On Dec 9, 2014, at 7:59 PM, John Rose wrote: > > Thumbs up. ? John > >> On Dec 9, 2014, at 10:04 AM, Roland Westrelin wrote: >> >>>>> That's good; let's do it that way! >>>>> >>>>> Final suggestion (really): Add some more test cases, containing duplicate array indexes, to exercise the "local" logic. >>>> >>>> Thanks John. I?ll add some test cases. Do you want to see another webrev with test cases? >>> >>> I'd like to look at it, so please update the webrev, but you can proceed with a thumbs up from me as a reviewer no matter what. >> >> Here is a new webrev for the change I intend to push today: >> >> http://cr.openjdk.java.net/~roland/8066103/webrev.04/ >> >> It has more test cases and the previous change had some leftover code: >> >> 939 if (rc0.ctl->in(0)->in(1) == in(1)) { >> 940 // If we match the test exactly, then the top test covers >> >> 941 // both our lower and upper bounds. Valid only if there's no >> 942 // other range check between us and the top test: for all we >> 943 // know this range check was widened and accesses that >> 944 // depend on it also depend on the previous range checks to >> 945 // be correct. >> >> 946 prev_dom = rc0.ctl; >> 947 } else { >> >> Roland. > From david.r.chase at oracle.com Tue Dec 9 20:49:13 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 9 Dec 2014 15:49:13 -0500 Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class In-Reply-To: <54872854.90806@oracle.com> References: <54872854.90806@oracle.com> Message-ID: <628BCC0A-43FF-4469-BC0D-FC38BBE53A58@oracle.com> I agree with your changes to loadClass, but I am not sure that this will allow you to redefine an existing class. My understanding of how this would work is that it will allow you re-obtain the class that was already loaded (but not to fail at this). Actually redefining a class requires use of JVMTI (or so I think). Was that your intent? David On 2014-12-09, at 11:50 AM, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066497 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ > > Problem: > ByteCodeLoader allows one to load class with given name from existing bytecode. But if this class is already loaded by e.g. system classloader it cannot be redefined using another bytecode array because of delegation of loadClass call to parent classloader. > > Solution: > override loadClass to break delegation for given className. > > Testing: manual > > ------------------- > Thanks, > Pavel -------------- 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: From vladimir.kozlov at oracle.com Tue Dec 9 21:37:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 09 Dec 2014 13:37:47 -0800 Subject: RFR(S): 8027829: CompileCommand does not accept all JLS-conformant class/method names In-Reply-To: <5474804A.4040208@oracle.com> References: <546F6201.6070000@oracle.com> <546F5AA6.3020805@oracle.com> <547331A5.40609@oracle.com> <54733A50.5030705@oracle.com> <5474804A.4040208@oracle.com> Message-ID: <54876BAB.6070502@oracle.com> Missing "method" at the end: ! tty->print_cr(" exclude, - don't compile or inline this "); Also add that these commands can be listed in .hotspot_compiler file instead of command line. Otherwise looks good. Thanks, Vladimir On 11/25/14 5:12 AM, Nils Eliasson wrote: > Hi, > > I added an improved help text and included a format description that is > printed on parse error. > > webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.04/ > > Thanks! > Nils > > On 2014-11-24 15:01, Vladimir Ivanov wrote: >> Looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 11/24/14, 5:24 PM, Nils Eliasson wrote: >>> Hi Vladimir, >>> >>> You are absolutely correct. Of course it is the JVMS that should be >>> targeted. >>> >>> I have updated the change adding all characters that do not create >>> problem with the >>> command line parser or pattern matcher, and are allowed by the JVMS. >>> >>> Also fixed so that we can match the signature without requiring a >>> whitespace before. >>> >>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.02 >>> >>> Thanks, >>> //Nils >>> >>> On 2014-11-21 16:30, Vladimir Ivanov wrote: >>>> Nils, >>>> >>>> 2 typos: Charachter.isJavaIdentiferPart >>>> >>>> Are there any plans to extend this further past JLS? >>>> JVMS allows arbitrary UTF8 string to be used as a class/method/field >>>> name and some JVM languages use that. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/21/14, 8:02 PM, Nils Eliasson wrote: >>>>> Hi, >>>>> >>>>> Please review this patch. >>>>> >>>>> It includes two fixes: >>>>> >>>>> 1) Improve CompileCommand so that it now accepts all JLS conformant >>>>> class and method names. (With one exception - \u0000 can not be used >>>>> since the commandline parsing uses null terminated strings.) For >>>>> parsing >>>>> simplicity it is possible in some case to specify a pattern that is >>>>> not >>>>> JLS-conformant. That is however not a problem - the pattern will be >>>>> saved as a symbol and will simply never match any allowed name. >>>>> >>>>> 2) Fixed some output to make it more understandable. The user is >>>>> specifying the flag "CompileCommand" and any output should be >>>>> annotated >>>>> with the flag name, and not "CompilerOracle". Also added more >>>>> describing >>>>> error messages. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027829 >>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.01/ >>>>> >>>>> Regards, >>>>> Nils Eliasson >>> > From dean.long at oracle.com Wed Dec 10 00:25:50 2014 From: dean.long at oracle.com (Dean Long) Date: Tue, 09 Dec 2014 16:25:50 -0800 Subject: RFR(XXS) 8066900: Array Out Of Bounds Exception causes variable corruption In-Reply-To: <28FDF3DC-FA2E-48E4-93B8-6CFC3D3C0219@oracle.com> References: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> <5487454E.1050705@oracle.com> <28FDF3DC-FA2E-48E4-93B8-6CFC3D3C0219@oracle.com> Message-ID: <5487930E.1000800@oracle.com> One small comment: can you use something like this to make it even more clear: bool save_fpu_registers =(id != handle_exception_nofpu_id); oop_map = save_live_registers(sasm, 1 /*thread*/,save_fpu_registers); restore_live_registers(sasm,save_fpu_registers); otherwise it looks good. dl On 12/9/2014 11:07 AM, Igor Veresov wrote: >> On Dec 9, 2014, at 10:54 AM, Vladimir Ivanov wrote: >> >> Looks good. >> > Thanks! > >> Can you use 4 space indentation in the test? >> > Sure, I?ll fix that. > >> Best regards, >> Vladimir Ivanov >> >> On 12/9/14, 9:05 PM, Igor Veresov wrote: >>> C1 does the opposite of the right thing when saving the registers during >>> exception handling on x86. Other platforms seem fine. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ >>> >>> Thanks, >>> igor From igor.veresov at oracle.com Wed Dec 10 03:46:09 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 9 Dec 2014 19:46:09 -0800 Subject: RFR(XXS) 8066900: Array Out Of Bounds Exception causes variable corruption In-Reply-To: <5487930E.1000800@oracle.com> References: <81CA688D-D875-446C-8550-9C2119165670@oracle.com> <5487454E.1050705@oracle.com> <28FDF3DC-FA2E-48E4-93B8-6CFC3D3C0219@oracle.com> <5487930E.1000800@oracle.com> Message-ID: <1C20796B-2C80-4B83-A9B9-58D4F52F21B3@oracle.com> Sorry, Dean, I already pushed it before I saw your email. igor > On Dec 9, 2014, at 4:25 PM, Dean Long wrote: > > One small comment: can you use something like this to make it even more clear: > > bool save_fpu_registers =(id != handle_exception_nofpu_id); > > oop_map = save_live_registers(sasm, 1 /*thread*/,save_fpu_registers); > > restore_live_registers(sasm,save_fpu_registers); > > otherwise it looks good. > > dl > > On 12/9/2014 11:07 AM, Igor Veresov wrote: >>> On Dec 9, 2014, at 10:54 AM, Vladimir Ivanov wrote: >>> >>> Looks good. >>> >> Thanks! >> >>> Can you use 4 space indentation in the test? >>> >> Sure, I?ll fix that. >> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 12/9/14, 9:05 PM, Igor Veresov wrote: >>>> C1 does the opposite of the right thing when saving the registers during >>>> exception handling on x86. Other platforms seem fine. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8066900/webrev.00/ >>>> >>>> Thanks, >>>> igor > From fuyou001 at gmail.com Wed Dec 10 05:20:59 2014 From: fuyou001 at gmail.com (fuyou) Date: Wed, 10 Dec 2014 13:20:59 +0800 Subject: How to build openJDK8 (build 32) Message-ID: I want to try https://mail.google.com/mail/u/0/#label/java%2Fjdk%2Fcompiler-dev/14a178591a7c71f6 ,but how build it by myself? step1: download source from http://download.java.net/openjdk/jdk8/ step2 :git clone https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff step3 :unzip dk-8-src-b132-03_mar_2014.zip and go to the openjdk and patch -p1 openjdk8_b132-fp.diff it is right ? -- ============================================= fuyou001 Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuyou001 at gmail.com Wed Dec 10 07:06:11 2014 From: fuyou001 at gmail.com (fuyou) Date: Wed, 10 Dec 2014 15:06:11 +0800 Subject: How to build openJDK8 (build 32) In-Reply-To: References: Message-ID: *update :* I want to try A hotspot patch for stack profiling (frame pointer) ,but how build it by myself? step1: download source from http://download.java.net/openjdk/jdk8/ step2 :git clone https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff step3 :unzip dk-8-src-b132-03_mar_2014.zip and go to the openjdk and patch -p1 openjdk8_b132-fp.diff it is right ? 2014-12-10 13:20 GMT+08:00 fuyou : > I want to try > https://mail.google.com/mail/u/0/#label/java%2Fjdk%2Fcompiler-dev/14a178591a7c71f6 > > ,but how build it by myself? > > step1: download source from http://download.java.net/openjdk/jdk8/ > step2 :git clone > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > > step3 :unzip dk-8-src-b132-03_mar_2014.zip > and go to the openjdk > and patch -p1 openjdk8_b132-fp.diff > > it is right ? > -- > ============================================= > > fuyou001 > Best Regards > > -- ============================================= fuyou001 Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuyou001 at gmail.com Wed Dec 10 07:09:53 2014 From: fuyou001 at gmail.com (fuyou) Date: Wed, 10 Dec 2014 15:09:53 +0800 Subject: How to build openJDK8 (build 32) In-Reply-To: References: Message-ID: *update :* I want to try A hotspot patch for stack profiling (frame pointer) ,but how build it by myself? I try to install from source code : step1: download source from http://download.java.net/openjdk/jdk8/ step2 :git clone https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff step3 :unzip dk-8-src-b132-03_mar_2014.zip and go to the openjdk and patch -p1 openjdk8_b132-fp.diff step4 :bash configure; unset CLASSPATH ; unset JAVA_HOME; make all it is right ? 2014-12-10 13:20 GMT+08:00 fuyou : > I want to try > https://mail.google.com/mail/u/0/#label/java%2Fjdk%2Fcompiler-dev/14a178591a7c71f6 > > ,but how build it by myself? > > step1: download source from http://download.java.net/openjdk/jdk8/ > step2 :git clone > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > > step3 :unzip dk-8-src-b132-03_mar_2014.zip > and go to the openjdk > and patch -p1 openjdk8_b132-fp.diff > > it is right ? > -- > ============================================= > > fuyou001 > Best Regards > > -- ============================================= fuyou001 2014-12-10 15:06 GMT+08:00 fuyou : > *update :* > > I want to try A hotspot patch for stack profiling (frame pointer) > > > ,but how build it by myself? > > step1: download source from http://download.java.net/openjdk/jdk8/ > step2 :git clone > https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > > step3 :unzip dk-8-src-b132-03_mar_2014.zip > and go to the openjdk > and patch -p1 openjdk8_b132-fp.diff > > it is right ? > > 2014-12-10 13:20 GMT+08:00 fuyou : > >> I want to try >> https://mail.google.com/mail/u/0/#label/java%2Fjdk%2Fcompiler-dev/14a178591a7c71f6 >> >> ,but how build it by myself? >> >> step1: download source from http://download.java.net/openjdk/jdk8/ >> step2 :git clone >> https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff >> >> step3 :unzip dk-8-src-b132-03_mar_2014.zip >> and go to the openjdk >> and patch -p1 openjdk8_b132-fp.diff >> >> it is right ? >> -- >> ============================================= >> >> fuyou001 >> Best Regards >> >> > > > > -- > ============================================= > > fuyou001 > Best Regards > > -- ============================================= fuyou001 Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.chistyakov at oracle.com Wed Dec 10 12:03:13 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Wed, 10 Dec 2014 15:03:13 +0300 Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class In-Reply-To: <628BCC0A-43FF-4469-BC0D-FC38BBE53A58@oracle.com> References: <54872854.90806@oracle.com> <628BCC0A-43FF-4469-BC0D-FC38BBE53A58@oracle.com> Message-ID: <54883681.3030307@oracle.com> Hi David, Thanks for review. The intent was: * be able to get */new/* instance of Class w/ given name and given bytecode for every /*new*/ instance of ByteCodeLoader even if this class was already loaded by parent loader. For this reason, I overrided loadClass to break delegation to parent loader for given className; * make single class definition for ByteCodeLoader instance. Here holder field appears and DCL for it's thread safe initialization. ------------- Pavel On 09.12.2014 23:49, David Chase wrote: > I agree with your changes to loadClass, but I am not sure that this will allow you to redefine an existing class. My understanding of how this would work is that it will allow you re-obtain the class that was already loaded (but not to fail at this). Actually redefining a class requires use of JVMTI (or so I think). > > Was that your intent? > > David > > > On 2014-12-09, at 11:50 AM, Pavel Chistyakov wrote: > >> Hi all, >> >> please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066497 >> webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ >> >> Problem: >> ByteCodeLoader allows one to load class with given name from existing bytecode. But if this class is already loaded by e.g. system classloader it cannot be redefined using another bytecode array because of delegation of loadClass call to parent classloader. >> >> Solution: >> override loadClass to break delegation for given className. >> >> Testing: manual >> >> ------------------- >> Thanks, >> Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Wed Dec 10 12:21:03 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 10 Dec 2014 16:21:03 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <5485B31C.6070001@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> Message-ID: <54883AAF.2060603@oracle.com> Tobias, as I wrote you in a private message, until a fix for 8064940 doesn't affect the way options are processed there is no need to update proposed tests. I've filed 8067135 for new tests that will verify actual alignment of code heaps. Regards, Filipp. On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: > On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>> Hi Tobias, >>> >>> thank you for suggestion. >>> >>> Yes, I think we should take code heap size alignment into account. >>> >>> What alignment policy you're going to implement for 8064940? >> My current fix just large-page-aligns the code heap sizes. >> >>> Maybe instead of checking that values are in >>> (value - page_size, value + page_size) interval we should just check >>> that all values were aligned up to page_size? >> Yes, that's a better solution. However, I don't know how to figure out the >> available page sizes from Java code. > There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list > about to add such method to WB API, but it need to check how well > it is going to work with large pages. > > Thanks, > Filipp. >> >> Best, >> Tobias >> >>> Thanks, >>> Filipp. >>> >>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>> Hi Filipp, >>>> >>>> the actual size of a code heap is affected by alignment and therefore may be >>>> different to the size set via the command line. For example, on Sparc we >>>> have to >>>> make sure that the code heaps are large page (4MB) aligned to reduce the >>>> number >>>> of ITLB misses (will be introduced with [1]). >>>> >>>> Maybe we should check if the actual size of the code heap is within >>>> boundaries, >>>> i.e., within the specified size +- (large) page size. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>> >>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>> Hi, >>>>> >>>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>>> >>>>> There are three new tests: >>>>> compiler/codecache/cli/ >>>>> codeheapsize/TestCodeHeapSizeOptions >>>>> printcodecache/TestPrintCodeCacheOption >>>>> TestSegmentedCodeCacheOption >>>>> >>>>> All tests consist of several test cases aimed to verify different aspects >>>>> of options' processing. >>>>> >>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>>> but add additional value - these tests actually check final values >>>>> of tested options and verifies PrintCodeCache output. >>>>> >>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>> Testing: manual & automated >>>>> >>>>> This change depends on: >>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI >>>>> tests >>>>> error reporting >>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>> testlibrary >>>>> for JDK-8059613 >>>>> >>>>> Thanks >>>>> Filipp. > From tobias.hartmann at oracle.com Wed Dec 10 12:39:51 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Dec 2014 13:39:51 +0100 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <54883AAF.2060603@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> Message-ID: <54883F17.4060904@oracle.com> Hi Filipp, On 10.12.2014 13:21, Filipp Zhinkin wrote: > Tobias, > > as I wrote you in a private message, until a fix for 8064940 doesn't affect > the way options are processed there is no need to update proposed tests. > > I've filed 8067135 for new tests that will verify actual alignment of code heaps. Okay, sounds good. Thanks, Tobias > > Regards, > Filipp. > > On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>> Hi Tobias, >>>> >>>> thank you for suggestion. >>>> >>>> Yes, I think we should take code heap size alignment into account. >>>> >>>> What alignment policy you're going to implement for 8064940? >>> My current fix just large-page-aligns the code heap sizes. >>> >>>> Maybe instead of checking that values are in >>>> (value - page_size, value + page_size) interval we should just check >>>> that all values were aligned up to page_size? >>> Yes, that's a better solution. However, I don't know how to figure out the >>> available page sizes from Java code. >> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >> about to add such method to WB API, but it need to check how well >> it is going to work with large pages. >> >> Thanks, >> Filipp. >>> >>> Best, >>> Tobias >>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>> Hi Filipp, >>>>> >>>>> the actual size of a code heap is affected by alignment and therefore may be >>>>> different to the size set via the command line. For example, on Sparc we >>>>> have to >>>>> make sure that the code heaps are large page (4MB) aligned to reduce the >>>>> number >>>>> of ITLB misses (will be introduced with [1]). >>>>> >>>>> Maybe we should check if the actual size of the code heap is within >>>>> boundaries, >>>>> i.e., within the specified size +- (large) page size. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>> >>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>> Hi, >>>>>> >>>>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>>>> >>>>>> There are three new tests: >>>>>> compiler/codecache/cli/ >>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>> printcodecache/TestPrintCodeCacheOption >>>>>> TestSegmentedCodeCacheOption >>>>>> >>>>>> All tests consist of several test cases aimed to verify different aspects >>>>>> of options' processing. >>>>>> >>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>>>> but add additional value - these tests actually check final values >>>>>> of tested options and verifies PrintCodeCache output. >>>>>> >>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>> Testing: manual & automated >>>>>> >>>>>> This change depends on: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI >>>>>> tests >>>>>> error reporting >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>> testlibrary >>>>>> for JDK-8059613 >>>>>> >>>>>> Thanks >>>>>> Filipp. >> > From filipp.zhinkin at oracle.com Wed Dec 10 13:48:23 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 10 Dec 2014 17:48:23 +0400 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms Message-ID: <54884F27.2020206@oracle.com> Hi all, please review a fix for 8066862. Issue: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with RuntimeException: All Platform's methods with signature '():Z' should be tested Root cause: In order to prevent issues caused by the fact that some mutually exclusive predicates may return "true" on on the same platform (for example if isARM and isPPC will return true simultaneously) I decided to check in test if all Platform's methods with '():Z' signature were tested. Fix for 8039995 added new methods with "():Z" signature, but these methods were not marked in TestMutuallyExclusivePlatformPredicates as methods that should be ignored. Proposed fix: Mark newly added methods as ignored in TestMutuallyExclusivePlatformPredicates.java, add this test to sanity test group in order to run it in JPRT Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ Testing: manual & automated From igor.ignatyev at oracle.com Wed Dec 10 14:26:00 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 10 Dec 2014 17:26:00 +0300 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <54884F27.2020206@oracle.com> References: <54884F27.2020206@oracle.com> Message-ID: <548857F8.70107@oracle.com> Hi Filipp, looks good to me. thanks for fixing this. Igor On 12/10/2014 04:48 PM, Filipp Zhinkin wrote: > Hi all, > > please review a fix for 8066862. > > Issue: > testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with > RuntimeException: All Platform's methods with signature '():Z' should be > tested > > Root cause: > In order to prevent issues caused by the fact that some mutually exclusive > predicates may return "true" on on the same platform (for example if > isARM and > isPPC will return true simultaneously) I decided to check in test if all > Platform's methods with '():Z' signature were tested. > > Fix for 8039995 added new methods with "():Z" signature, but these > methods were > not marked in TestMutuallyExclusivePlatformPredicates as methods that > should be ignored. > > Proposed fix: > Mark newly added methods as ignored in > TestMutuallyExclusivePlatformPredicates.java, > add this test to sanity test group in order to run it in JPRT > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ > Testing: manual & automated From filipp.zhinkin at oracle.com Wed Dec 10 14:20:40 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 10 Dec 2014 18:20:40 +0400 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <548857F8.70107@oracle.com> References: <54884F27.2020206@oracle.com> <548857F8.70107@oracle.com> Message-ID: <548856B8.8020107@oracle.com> Hi Igor, thank you for review! Regards, Filipp. On 12/10/2014 06:26 PM, Igor Ignatyev wrote: > Hi Filipp, > > looks good to me. > thanks for fixing this. > > Igor > > On 12/10/2014 04:48 PM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a fix for 8066862. >> >> Issue: >> testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with >> RuntimeException: All Platform's methods with signature '():Z' should be >> tested >> >> Root cause: >> In order to prevent issues caused by the fact that some mutually exclusive >> predicates may return "true" on on the same platform (for example if >> isARM and >> isPPC will return true simultaneously) I decided to check in test if all >> Platform's methods with '():Z' signature were tested. >> >> Fix for 8039995 added new methods with "():Z" signature, but these >> methods were >> not marked in TestMutuallyExclusivePlatformPredicates as methods that >> should be ignored. >> >> Proposed fix: >> Mark newly added methods as ignored in >> TestMutuallyExclusivePlatformPredicates.java, >> add this test to sanity test group in order to run it in JPRT >> >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ >> Testing: manual & automated From roland.westrelin at oracle.com Wed Dec 10 15:56:35 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 10 Dec 2014 16:56:35 +0100 Subject: RFR(XS): 8067144: SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects Message-ID: -XX:+TraceDeoptimization tries to print realloc'ed objects even when there are none (following the recent deoptimization changes): http://cr.openjdk.java.net/~roland/8067144/webrev.00/ Roland. From vladimir.kempik at oracle.com Wed Dec 10 16:19:43 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 10 Dec 2014 19:19:43 +0300 Subject: [7u] RFR: 8054478: C2: Incorrectly compiled char[] array access crashes JVM Message-ID: <5488729F.8080402@oracle.com> Hello Please review this backport of 8054478 to jdk7. Few changes was needed to make it compatible with jdk7u: - in connode.cpp use res->filter() instead of res->filter_speculative() - enable TiredCompilation in testcase - few other small changes. JBS: https://bugs.openjdk.java.net/browse/JDK-8054478 Webrev: http://cr.openjdk.java.net/~vkempik/8054478/webrev.00/ Testing: jprt Original fix: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/49dd956bc8c0 Thanks, Vladimir. From roland.westrelin at oracle.com Wed Dec 10 16:23:58 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 10 Dec 2014 17:23:58 +0100 Subject: [7u] RFR: 8054478: C2: Incorrectly compiled char[] array access crashes JVM In-Reply-To: <5488729F.8080402@oracle.com> References: <5488729F.8080402@oracle.com> Message-ID: <1A402B51-7671-410D-8783-DDB9BFB33938@oracle.com> > Webrev: http://cr.openjdk.java.net/~vkempik/8054478/webrev.00/ That looks good to me. Roland. From vladimir.kozlov at oracle.com Wed Dec 10 17:39:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Dec 2014 09:39:11 -0800 Subject: RFR(XS): 8067144: SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects In-Reply-To: References: Message-ID: <5488853F.2030409@oracle.com> Good. thanks, Vladimir On 12/10/14 7:56 AM, Roland Westrelin wrote: > -XX:+TraceDeoptimization tries to print realloc'ed objects even when there are none (following the recent deoptimization changes): > > http://cr.openjdk.java.net/~roland/8067144/webrev.00/ > > Roland. > From vladimir.kozlov at oracle.com Wed Dec 10 17:54:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Dec 2014 09:54:24 -0800 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <54884F27.2020206@oracle.com> References: <54884F27.2020206@oracle.com> Message-ID: <548888D0.3030103@oracle.com> Filipp, Your changes are in conflict with 8067115 changes in hs-gc repo: http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ Please, use gc repo instead of hs-comp and coordinate the push with Bengt. Otherwise looks good. Thanks, Vladimir On 12/10/14 5:48 AM, Filipp Zhinkin wrote: > Hi all, > > please review a fix for 8066862. > > Issue: > testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with > RuntimeException: All Platform's methods with signature '():Z' should be > tested > > Root cause: > In order to prevent issues caused by the fact that some mutually exclusive > predicates may return "true" on on the same platform (for example if > isARM and > isPPC will return true simultaneously) I decided to check in test if all > Platform's methods with '():Z' signature were tested. > > Fix for 8039995 added new methods with "():Z" signature, but these > methods were > not marked in TestMutuallyExclusivePlatformPredicates as methods that > should be ignored. > > Proposed fix: > Mark newly added methods as ignored in > TestMutuallyExclusivePlatformPredicates.java, > add this test to sanity test group in order to run it in JPRT > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ > Testing: manual & automated From pavel.punegov at oracle.com Wed Dec 10 17:59:44 2014 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Wed, 10 Dec 2014 20:59:44 +0300 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <54855381.8030002@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> <548212BE.7010500@oracle.com> <54855381.8030002@oracle.com> Message-ID: <54888A10.90800@oracle.com> Hi Tobias and Igor, could you please review this: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.05/ I replaced the check for OSR-methods to skip transitions after deoptimization as they may make intermittent failures. See 67-70 lines at LevelTransitionTest.java I will file a separate RFE to improve this test to be able to check transitions after deopt too. Testing: jprt, locally On 08.12.2014 10:30, Tobias Hartmann wrote: > Hi Pavel, > > looks good (not a reviewer). > > Best, > Tobias > > On 05.12.2014 21:17, Pavel Punegov wrote: >> Hi Tobias, >> >> see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ >> >> I added TransitionsTestExecutor.java class that checks if TieredCompilation is >> available in the VM it was started with. Then it starts test for >> CompilatonPolicyChoice 2 and 3. >> >> On 01.12.2014 11:27, Tobias Hartmann wrote: >>> Hi Pavel, >>> >>> the tests fail with a client VM: >>> >>>> Error occurred during initialization of VM >>>> Incompatible compilation policy selected >>> Please execute them on JPRT to make sure they work on all platforms. >>> >>> Best, >>> Tobias >>> >>> On 28.11.2014 13:27, Pavel Punegov wrote: >>>> Hi all, >>>> >>>> please review new tests developed as a part of the test task: >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >>>> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >>>> >>>> Description: >>>> There are two tests to verify level transitions in Tiered Compilation: >>>> 1. LevelTransitionTest verifies that in case of no load on compiler queues test >>>> methods go through common transition patterns: >>>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >>>> trivial methods, and 0 -> 4 after deoptimization. >>>> Test provokes compilations of the method and checks that all transitions are >>>> correct for CompilationPolicyChoice=2 and 3. >>>> >>>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used for >>>> 8056071 (see [*] for details). It checks that all constant getters are always >>>> compiled with C1. >>>> >>>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >>>> >>>> Testing: done locally >>>> -- Thanks, Pavel Punegov From roland.westrelin at oracle.com Wed Dec 10 21:16:08 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 10 Dec 2014 22:16:08 +0100 Subject: RFR(XS): 8067144: SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects In-Reply-To: <5488853F.2030409@oracle.com> References: <5488853F.2030409@oracle.com> Message-ID: Thanks for the review, Vladimir. Roland. > On Dec 10, 2014, at 6:39 PM, Vladimir Kozlov wrote: > > Good. > > thanks, > Vladimir > > On 12/10/14 7:56 AM, Roland Westrelin wrote: >> -XX:+TraceDeoptimization tries to print realloc'ed objects even when there are none (following the recent deoptimization changes): >> >> http://cr.openjdk.java.net/~roland/8067144/webrev.00/ >> >> Roland. >> From igor.veresov at oracle.com Wed Dec 10 22:26:51 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 10 Dec 2014 14:26:51 -0800 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <54888A10.90800@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> <548212BE.7010500@oracle.com> <54855381.8030002@oracle.com> <54888A10.90800@oracle.com> Message-ID: Looks ok. However, one general comment... I skimmed through the WB API and noticed that you guys get nmethod* and operate on it without any precausions, it?s not really safe. nmethods can go away at anytime (starting from concurrent nmethod::_state modification and ending with the codeblob deallocation). So you have to either disable the sweeper, and/or make sure you cooperate with nmethod::make_not_entrant_or_zombie(). igor > On Dec 10, 2014, at 9:59 AM, Pavel Punegov wrote: > > Hi Tobias and Igor, > > could you please review this: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.05/ > > I replaced the check for OSR-methods to skip transitions after deoptimization as they may make intermittent failures. > See 67-70 lines at LevelTransitionTest.java > > I will file a separate RFE to improve this test to be able to check transitions after deopt too. > > Testing: jprt, locally > > On 08.12.2014 10:30, Tobias Hartmann wrote: >> Hi Pavel, >> >> looks good (not a reviewer). >> >> Best, >> Tobias >> >> On 05.12.2014 21:17, Pavel Punegov wrote: >>> Hi Tobias, >>> >>> see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ >>> >>> I added TransitionsTestExecutor.java class that checks if TieredCompilation is >>> available in the VM it was started with. Then it starts test for >>> CompilatonPolicyChoice 2 and 3. >>> >>> On 01.12.2014 11:27, Tobias Hartmann wrote: >>>> Hi Pavel, >>>> >>>> the tests fail with a client VM: >>>> >>>>> Error occurred during initialization of VM >>>>> Incompatible compilation policy selected >>>> Please execute them on JPRT to make sure they work on all platforms. >>>> >>>> Best, >>>> Tobias >>>> >>>> On 28.11.2014 13:27, Pavel Punegov wrote: >>>>> Hi all, >>>>> >>>>> please review new tests developed as a part of the test task: >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >>>>> >>>>> Description: >>>>> There are two tests to verify level transitions in Tiered Compilation: >>>>> 1. LevelTransitionTest verifies that in case of no load on compiler queues test >>>>> methods go through common transition patterns: >>>>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >>>>> trivial methods, and 0 -> 4 after deoptimization. >>>>> Test provokes compilations of the method and checks that all transitions are >>>>> correct for CompilationPolicyChoice=2 and 3. >>>>> >>>>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used for >>>>> 8056071 (see [*] for details). It checks that all constant getters are always >>>>> compiled with C1. >>>>> >>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >>>>> >>>>> Testing: done locally >>>>> > > -- > Thanks, > Pavel Punegov > From rednaxelafx at gmail.com Wed Dec 10 23:59:35 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 10 Dec 2014 15:59:35 -0800 Subject: Deoptimize on putfield CallSite.target? Message-ID: Hi everyone, I'd like to ask a question on the handling of setting CallSite.target in compiled code. Specifically, is the following piece of code in C2's Parse::do_field_access() [1] necessary? // Deoptimize on putfield writes to call site target field. if (!is_get && field->is_call_site_target()) { uncommon_trap(Deoptimization::Reason_unhandled, Deoptimization::Action_reinterpret, NULL, "put to call site target field"); return; } If it is necessary, then why isn't it mirrored in C1's GraphBuilder::access_field() [2] ? My take is that the C2 deoptimization is unnecessary here, since a dependency is added when the compilers speculatively take a CallSite.target as constant. There's no internal Java code that would do a putfield on a CallSite.target anyway, and all external requests to change the target would have gone through CallSite.setTarget(), which is appropriately routed to the runtime already. I'm okay with the "it won't hurt to leave the code there" idea. Just want to make sure I understood things correctly. Thanks, Kris [1]: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/38cb4fbd47e3/src/share/vm/opto/parse3.cpp#l104 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Thu Dec 11 07:27:25 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 08:27:25 +0100 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <54888A10.90800@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> <548212BE.7010500@oracle.com> <54855381.8030002@oracle.com> <54888A10.90800@oracle.com> Message-ID: <5489475D.9020907@oracle.com> Hi, I agree with Igor that concurrent removal of nmethods by the sweeper may be a problem. I think in 'WB_GetNMethod' we should at least acquire the nmethod lock (using 'nmethodLocker') to prevent concurrent removal. As far as I understand, the JNI functions copy the nmethod data. It should be fine for the sweeper to remove the nmethod afterwards. As a result, the data may be outdated and we should not expect Whitebox.getNMethod() to always return a NMethod object, even if the corresponding method was compiled right before. Maybe you can file a separate bug for that issue. Otherwise your change looks good (not a reviewer). Thanks, Tobias On 10.12.2014 18:59, Pavel Punegov wrote: > Hi Tobias and Igor, > > could you please review this: > http://cr.openjdk.java.net/~ppunegov/8059575/webrev.05/ > > I replaced the check for OSR-methods to skip transitions after deoptimization as > they may make intermittent failures. > See 67-70 lines at LevelTransitionTest.java > > I will file a separate RFE to improve this test to be able to check transitions > after deopt too. > > Testing: jprt, locally > > On 08.12.2014 10:30, Tobias Hartmann wrote: >> Hi Pavel, >> >> looks good (not a reviewer). >> >> Best, >> Tobias >> >> On 05.12.2014 21:17, Pavel Punegov wrote: >>> Hi Tobias, >>> >>> see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ >>> >>> I added TransitionsTestExecutor.java class that checks if TieredCompilation is >>> available in the VM it was started with. Then it starts test for >>> CompilatonPolicyChoice 2 and 3. >>> >>> On 01.12.2014 11:27, Tobias Hartmann wrote: >>>> Hi Pavel, >>>> >>>> the tests fail with a client VM: >>>> >>>>> Error occurred during initialization of VM >>>>> Incompatible compilation policy selected >>>> Please execute them on JPRT to make sure they work on all platforms. >>>> >>>> Best, >>>> Tobias >>>> >>>> On 28.11.2014 13:27, Pavel Punegov wrote: >>>>> Hi all, >>>>> >>>>> please review new tests developed as a part of the test task: >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >>>>> >>>>> Description: >>>>> There are two tests to verify level transitions in Tiered Compilation: >>>>> 1. LevelTransitionTest verifies that in case of no load on compiler queues >>>>> test >>>>> methods go through common transition patterns: >>>>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >>>>> trivial methods, and 0 -> 4 after deoptimization. >>>>> Test provokes compilations of the method and checks that all transitions are >>>>> correct for CompilationPolicyChoice=2 and 3. >>>>> >>>>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used for >>>>> 8056071 (see [*] for details). It checks that all constant getters are always >>>>> compiled with C1. >>>>> >>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >>>>> >>>>> Testing: done locally >>>>> > From staffan.larsen at oracle.com Thu Dec 11 09:05:28 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 11 Dec 2014 10:05:28 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5486F03D.6060608@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> <5486D0B3.5060209@oracle.com> <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com> <5486F03D.6060608@oracle.com> Message-ID: In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result. /Staffan > On 9 dec 2014, at 13:51, Igor Ignatyev wrote: > > this solution doesn't allow us to change iteration count for all tests. > > Igor > > On 12/09/2014 03:22 PM, Staffan Larsen wrote: >> I would favor a solution where the iteration count is an argument to the test instead of being a global variable. >> >> /Staffan >> >>> On 9 dec 2014, at 11:36, Igor Ignatyev wrote: >>> >>> On 12/09/2014 01:20 PM, Staffan Larsen wrote: >>>> >>>>> On 9 dec 2014, at 11:11, Igor Ignatyev wrote: >>>>> >>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. >>>>> >>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. >>>>> >>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) >>>>> >>>>> for all of these cases, I'd like to use one variable. >>>> >>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed. >>>> >>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. >>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib? >>> >>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one. >>> >>> -- Igor >>>> >>>> /Staffan >>>> >>>>> >>>>> Thanks, >>>>> Igor >>>>> >>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote: >>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>>>>>> >>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>>>>>> >>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>>>>>> >>>>>>>>> Hi Staffan, >>>>>>>>> >>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Igor >>>>>>>>> >>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>>>>>> perhaps he has future plans for this. >>>>>>>>>> Igor? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>>>>>> outside these specific tests? Should it really be part of the test >>>>>>>>>>> library? >>>>>>>>>>> >>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>>>>>> Pochepko wrote: >>>>>>>>>>>> >>>>>>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>>>>>> Test task: JMX- tests >>>>>>>>>>>>> and >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>>>>>> >>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>>>>>> testing thresholds, usage, >>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>>>>>> tests. >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>>>>>> >>>>>>>>>>>>> Additional note: this patch assumes >>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>>>>>> is fixed. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Dmitrij >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Igor >>>>>> >>>>> >>>>> -- >>>>> Igor >>>> >> From tobias.hartmann at oracle.com Thu Dec 11 09:14:27 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 10:14:27 +0100 Subject: [9] RFR(S): 8066763: fatal error "assert(false) failed: unexpected yanked node" in postaloc.cpp:139 Message-ID: <54896073.1010005@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8066763 Webrev: http://cr.openjdk.java.net/~thartmann/8066763/webrev.00/ Problem: A null check for an oop loaded by a LoadNNode (300) consists of a CmpNNode (388), a BoolNode (356) and a IfNode (357) [1]. After matching, the CmpNNode is replaced by a testN_reg node (56) and a jmpCon node (55) [2]. With implicit null checks enabled (default), the compiler notices that the oop is accessed by a nearby loadINode (131) and optimizes the code by using an implicit null check: Instead of checking the oop explicitly, the loadINode is moved upwards and executed without a check. Code is added to handle the SIGSEGV and throw the corresponding NullPointerException [3]. The problem is that after the optimization the testN_reg node is dead (see [3]) and triggers the assert in the register allocator. With implicit null checks disabled (-XX:-ImplicitNullChecks) the bug does not appear. Solution: The proposed fix checks for dead input nodes after removing the old compare node. This removes the dead testN_reg node (see [4]). Testing: - Failing test - JPRT Thanks, Tobias [1] https://bugs.openjdk.java.net/secure/attachment/24158/1_before_matching.png [2] https://bugs.openjdk.java.net/secure/attachment/24187/2_global_code_motion.png [3] https://bugs.openjdk.java.net/secure/attachment/24159/1_global_code_motion.png [4] https://bugs.openjdk.java.net/secure/attachment/24161/3_global_code_motion.png From vladimir.kozlov at oracle.com Thu Dec 11 09:28:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Dec 2014 01:28:13 -0800 Subject: [9] RFR(S): 8066763: fatal error "assert(false) failed: unexpected yanked node" in postaloc.cpp:139 In-Reply-To: <54896073.1010005@oracle.com> References: <54896073.1010005@oracle.com> Message-ID: <548963AD.8020502@oracle.com> Looks good but rename local from 'req' (required) to 'in' (input) or 'dead'. Thanks, Vladimir On 12/11/14 1:14 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066763 > Webrev: http://cr.openjdk.java.net/~thartmann/8066763/webrev.00/ > > Problem: > A null check for an oop loaded by a LoadNNode (300) consists of a CmpNNode > (388), a BoolNode (356) and a IfNode (357) [1]. > After matching, the CmpNNode is replaced by a testN_reg node (56) and a jmpCon > node (55) [2]. With implicit null checks enabled (default), the compiler notices > that the oop is accessed by a nearby loadINode (131) and optimizes the code by > using an implicit null check: Instead of checking the oop explicitly, the > loadINode is moved upwards and executed without a check. Code is added to handle > the SIGSEGV and throw the corresponding NullPointerException [3]. > > The problem is that after the optimization the testN_reg node is dead (see [3]) > and triggers the assert in the register allocator. With implicit null checks > disabled (-XX:-ImplicitNullChecks) the bug does not appear. > > Solution: > The proposed fix checks for dead input nodes after removing the old compare > node. This removes the dead testN_reg node (see [4]). > > Testing: > - Failing test > - JPRT > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/24158/1_before_matching.png > [2] https://bugs.openjdk.java.net/secure/attachment/24187/2_global_code_motion.png > [3] https://bugs.openjdk.java.net/secure/attachment/24159/1_global_code_motion.png > [4] https://bugs.openjdk.java.net/secure/attachment/24161/3_global_code_motion.png > From igor.ignatyev at oracle.com Thu Dec 11 09:39:23 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Dec 2014 12:39:23 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> <5486D0B3.5060209@oracle.com> <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com> <5486F03D.6060608@oracle.com> Message-ID: <5489664B.50904@oracle.com> Staffan, nope, since external flags append to the flags specified it a test, we will get '-Dc.o.j.t.iterations=10 -Dc.o.j.t.iterations=' and the value of this property will be . Thanks, Igor On 12/11/2014 12:05 PM, Staffan Larsen wrote: > In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result. > > /Staffan > >> On 9 dec 2014, at 13:51, Igor Ignatyev wrote: >> >> this solution doesn't allow us to change iteration count for all tests. >> >> Igor >> >> On 12/09/2014 03:22 PM, Staffan Larsen wrote: >>> I would favor a solution where the iteration count is an argument to the test instead of being a global variable. >>> >>> /Staffan >>> >>>> On 9 dec 2014, at 11:36, Igor Ignatyev wrote: >>>> >>>> On 12/09/2014 01:20 PM, Staffan Larsen wrote: >>>>> >>>>>> On 9 dec 2014, at 11:11, Igor Ignatyev wrote: >>>>>> >>>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. >>>>>> >>>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. >>>>>> >>>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) >>>>>> >>>>>> for all of these cases, I'd like to use one variable. >>>>> >>>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed. >>>>> >>>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. >>>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib? >>>> >>>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one. >>>> >>>> -- Igor >>>>> >>>>> /Staffan >>>>> >>>>>> >>>>>> Thanks, >>>>>> Igor >>>>>> >>>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote: >>>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>>>>>>> >>>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>>>>>>> >>>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>>>>>>> >>>>>>>>>> Hi Staffan, >>>>>>>>>> >>>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Igor >>>>>>>>>> >>>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>>>>>>> perhaps he has future plans for this. >>>>>>>>>>> Igor? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>>>>>>> outside these specific tests? Should it really be part of the test >>>>>>>>>>>> library? >>>>>>>>>>>> >>>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>>>>>>> Pochepko wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>>>>>>> Test task: JMX- tests >>>>>>>>>>>>>> and >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>>>>>>> >>>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>>>>>>> testing thresholds, usage, >>>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>>>>>>> tests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Additional note: this patch assumes >>>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>>>>>>> is fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Dmitrij >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Igor >>>>>>> >>>>>> >>>>>> -- >>>>>> Igor >>>>> >>> > From tobias.hartmann at oracle.com Thu Dec 11 09:49:46 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 10:49:46 +0100 Subject: [9] RFR(S): 8066763: fatal error "assert(false) failed: unexpected yanked node" in postaloc.cpp:139 In-Reply-To: <548963AD.8020502@oracle.com> References: <54896073.1010005@oracle.com> <548963AD.8020502@oracle.com> Message-ID: <548968BA.1000607@oracle.com> Thanks, Vladimir. I renamed the variable to 'in': http://cr.openjdk.java.net/~thartmann/8066763/webrev.01/ Best, Tobias On 11.12.2014 10:28, Vladimir Kozlov wrote: > Looks good but rename local from 'req' (required) to 'in' (input) or 'dead'. > > Thanks, > Vladimir > > On 12/11/14 1:14 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8066763 >> Webrev: http://cr.openjdk.java.net/~thartmann/8066763/webrev.00/ >> >> Problem: >> A null check for an oop loaded by a LoadNNode (300) consists of a CmpNNode >> (388), a BoolNode (356) and a IfNode (357) [1]. >> After matching, the CmpNNode is replaced by a testN_reg node (56) and a jmpCon >> node (55) [2]. With implicit null checks enabled (default), the compiler notices >> that the oop is accessed by a nearby loadINode (131) and optimizes the code by >> using an implicit null check: Instead of checking the oop explicitly, the >> loadINode is moved upwards and executed without a check. Code is added to handle >> the SIGSEGV and throw the corresponding NullPointerException [3]. >> >> The problem is that after the optimization the testN_reg node is dead (see [3]) >> and triggers the assert in the register allocator. With implicit null checks >> disabled (-XX:-ImplicitNullChecks) the bug does not appear. >> >> Solution: >> The proposed fix checks for dead input nodes after removing the old compare >> node. This removes the dead testN_reg node (see [4]). >> >> Testing: >> - Failing test >> - JPRT >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/secure/attachment/24158/1_before_matching.png >> [2] >> https://bugs.openjdk.java.net/secure/attachment/24187/2_global_code_motion.png >> [3] >> https://bugs.openjdk.java.net/secure/attachment/24159/1_global_code_motion.png >> [4] >> https://bugs.openjdk.java.net/secure/attachment/24161/3_global_code_motion.png >> From vladimir.kozlov at oracle.com Thu Dec 11 09:52:55 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Dec 2014 01:52:55 -0800 Subject: [9] RFR(S): 8066763: fatal error "assert(false) failed: unexpected yanked node" in postaloc.cpp:139 In-Reply-To: <548968BA.1000607@oracle.com> References: <54896073.1010005@oracle.com> <548963AD.8020502@oracle.com> <548968BA.1000607@oracle.com> Message-ID: <54896977.5050306@oracle.com> Good. Thanks, Vladimir On 12/11/14 1:49 AM, Tobias Hartmann wrote: > Thanks, Vladimir. > > I renamed the variable to 'in': > > http://cr.openjdk.java.net/~thartmann/8066763/webrev.01/ > > Best, > Tobias > > On 11.12.2014 10:28, Vladimir Kozlov wrote: >> Looks good but rename local from 'req' (required) to 'in' (input) or 'dead'. >> >> Thanks, >> Vladimir >> >> On 12/11/14 1:14 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066763 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8066763/webrev.00/ >>> >>> Problem: >>> A null check for an oop loaded by a LoadNNode (300) consists of a CmpNNode >>> (388), a BoolNode (356) and a IfNode (357) [1]. >>> After matching, the CmpNNode is replaced by a testN_reg node (56) and a jmpCon >>> node (55) [2]. With implicit null checks enabled (default), the compiler notices >>> that the oop is accessed by a nearby loadINode (131) and optimizes the code by >>> using an implicit null check: Instead of checking the oop explicitly, the >>> loadINode is moved upwards and executed without a check. Code is added to handle >>> the SIGSEGV and throw the corresponding NullPointerException [3]. >>> >>> The problem is that after the optimization the testN_reg node is dead (see [3]) >>> and triggers the assert in the register allocator. With implicit null checks >>> disabled (-XX:-ImplicitNullChecks) the bug does not appear. >>> >>> Solution: >>> The proposed fix checks for dead input nodes after removing the old compare >>> node. This removes the dead testN_reg node (see [4]). >>> >>> Testing: >>> - Failing test >>> - JPRT >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/secure/attachment/24158/1_before_matching.png >>> [2] >>> https://bugs.openjdk.java.net/secure/attachment/24187/2_global_code_motion.png >>> [3] >>> https://bugs.openjdk.java.net/secure/attachment/24159/1_global_code_motion.png >>> [4] >>> https://bugs.openjdk.java.net/secure/attachment/24161/3_global_code_motion.png >>> From tobias.hartmann at oracle.com Thu Dec 11 09:56:15 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 10:56:15 +0100 Subject: [9] RFR(S): 8066763: fatal error "assert(false) failed: unexpected yanked node" in postaloc.cpp:139 In-Reply-To: <54896977.5050306@oracle.com> References: <54896073.1010005@oracle.com> <548963AD.8020502@oracle.com> <548968BA.1000607@oracle.com> <54896977.5050306@oracle.com> Message-ID: <54896A3F.90100@oracle.com> Thanks, Vladimir. Best, Tobias On 11.12.2014 10:52, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/11/14 1:49 AM, Tobias Hartmann wrote: >> Thanks, Vladimir. >> >> I renamed the variable to 'in': >> >> http://cr.openjdk.java.net/~thartmann/8066763/webrev.01/ >> >> Best, >> Tobias >> >> On 11.12.2014 10:28, Vladimir Kozlov wrote: >>> Looks good but rename local from 'req' (required) to 'in' (input) or 'dead'. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/11/14 1:14 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066763 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066763/webrev.00/ >>>> >>>> Problem: >>>> A null check for an oop loaded by a LoadNNode (300) consists of a CmpNNode >>>> (388), a BoolNode (356) and a IfNode (357) [1]. >>>> After matching, the CmpNNode is replaced by a testN_reg node (56) and a jmpCon >>>> node (55) [2]. With implicit null checks enabled (default), the compiler >>>> notices >>>> that the oop is accessed by a nearby loadINode (131) and optimizes the code by >>>> using an implicit null check: Instead of checking the oop explicitly, the >>>> loadINode is moved upwards and executed without a check. Code is added to >>>> handle >>>> the SIGSEGV and throw the corresponding NullPointerException [3]. >>>> >>>> The problem is that after the optimization the testN_reg node is dead (see [3]) >>>> and triggers the assert in the register allocator. With implicit null checks >>>> disabled (-XX:-ImplicitNullChecks) the bug does not appear. >>>> >>>> Solution: >>>> The proposed fix checks for dead input nodes after removing the old compare >>>> node. This removes the dead testN_reg node (see [4]). >>>> >>>> Testing: >>>> - Failing test >>>> - JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/secure/attachment/24158/1_before_matching.png >>>> [2] >>>> https://bugs.openjdk.java.net/secure/attachment/24187/2_global_code_motion.png >>>> [3] >>>> https://bugs.openjdk.java.net/secure/attachment/24159/1_global_code_motion.png >>>> [4] >>>> https://bugs.openjdk.java.net/secure/attachment/24161/3_global_code_motion.png >>>> From staffan.larsen at oracle.com Thu Dec 11 10:00:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 11 Dec 2014 11:00:32 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5489664B.50904@oracle.com> References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> <5486D0B3.5060209@oracle.com> <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com> <5486F03D.6060608@oracle.com> <5489664B.50904@oracle.com> Message-ID: > On 11 dec 2014, at 10:39, Igor Ignatyev wrote: > > Staffan, > > nope, since external flags append to the flags specified it a test, we will get '-Dc.o.j.t.iterations=10 -Dc.o.j.t.iterations=' and the value of this property will be . I thought so too, but when I tested, external flags (-vmoption) were pre-pended. /Staffan > > Thanks, > Igor > > On 12/11/2014 12:05 PM, Staffan Larsen wrote: >> In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result. >> >> /Staffan >> >>> On 9 dec 2014, at 13:51, Igor Ignatyev wrote: >>> >>> this solution doesn't allow us to change iteration count for all tests. >>> >>> Igor >>> >>> On 12/09/2014 03:22 PM, Staffan Larsen wrote: >>>> I would favor a solution where the iteration count is an argument to the test instead of being a global variable. >>>> >>>> /Staffan >>>> >>>>> On 9 dec 2014, at 11:36, Igor Ignatyev wrote: >>>>> >>>>> On 12/09/2014 01:20 PM, Staffan Larsen wrote: >>>>>> >>>>>>> On 9 dec 2014, at 11:11, Igor Ignatyev wrote: >>>>>>> >>>>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. >>>>>>> >>>>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. >>>>>>> >>>>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) >>>>>>> >>>>>>> for all of these cases, I'd like to use one variable. >>>>>> >>>>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed. >>>>>> >>>>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. >>>>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib? >>>>> >>>>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one. >>>>> >>>>> -- Igor >>>>>> >>>>>> /Staffan >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Igor >>>>>>> >>>>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote: >>>>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >>>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>>>>>>>> >>>>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>>>>>>>> >>>>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>>>>>>>> >>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Staffan, >>>>>>>>>>> >>>>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Igor >>>>>>>>>>> >>>>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>>>>>>>> perhaps he has future plans for this. >>>>>>>>>>>> Igor? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dmitrij >>>>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>>>>>>>> outside these specific tests? Should it really be part of the test >>>>>>>>>>>>> library? >>>>>>>>>>>>> >>>>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>>>>>>>> Pochepko wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>>>>>>>> Test task: JMX- tests >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>>>>>>>> testing thresholds, usage, >>>>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>>>>>>>> tests. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Additional note: this patch assumes >>>>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>>>>>>>> is fixed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Dmitrij >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Igor >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Igor >>>>>> >>>> >> From dmitrij.pochepko at oracle.com Thu Dec 11 12:25:44 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 11 Dec 2014 15:25:44 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: References: <5480B272.3030808@oracle.com> <5481E8F9.1080307@oracle.com> <8ECE2EC3-0763-4103-9392-251A2BCFEC4F@oracle.com> <548211EF.3050402@oracle.com> <5482237E.6010201@oracle.com> <5486C215.2090206@oracle.com> <5486CABC.9090107@oracle.com> <5486D0B3.5060209@oracle.com> <0DB5911A-A1FC-40C6-A775-3400412C06F4@oracle.com> <5486F03D.6060608@oracle.com> Message-ID: <54898D48.7090005@oracle.com> Yes, but in order to launch with any terations count, one shold just launch UsageThresholdExceededTest with -Dcom.oracle.java.testlibrary.iterations specified. Thanks, Dmitrij > In UsageThresholdExceededSeveralTimesTest you have specified -Dcom.oracle.java.testlibrary.iterations=10 in the test - this will also mean that you cannot override it from outside. So same result. > > /Staffan > >> On 9 dec 2014, at 13:51, Igor Ignatyev wrote: >> >> this solution doesn't allow us to change iteration count for all tests. >> >> Igor >> >> On 12/09/2014 03:22 PM, Staffan Larsen wrote: >>> I would favor a solution where the iteration count is an argument to the test instead of being a global variable. >>> >>> /Staffan >>> >>>> On 9 dec 2014, at 11:36, Igor Ignatyev wrote: >>>> >>>> On 12/09/2014 01:20 PM, Staffan Larsen wrote: >>>>>> On 9 dec 2014, at 11:11, Igor Ignatyev wrote: >>>>>> >>>>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it. >>>>>> >>>>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases. >>>>>> >>>>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc) >>>>>> >>>>>> for all of these cases, I'd like to use one variable. >>>>> But these look like three different counters to me? And for some tests all three counter could possibly be needed. >>>>> >>>>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from ?quick but less coverage? to ?slow but with more coverage? for some types of tests. >>>> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib? >>>> >>>> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one. >>>> >>>> -- Igor >>>>> /Staffan >>>>> >>>>>> Thanks, >>>>>> Igor >>>>>> >>>>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote: >>>>>>> But what is an ?iteration count?? It does not seem to be ?the number of times the test should be run?, but more ?how many times an arbitrary loop should be run?. And it is the ?arbitrary? that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing? >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev wrote: >>>>>>>> >>>>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view. >>>>>>>> >>>>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote: >>>>>>>>> I still don?t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache. >>>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev wrote: >>>>>>>>>> >>>>>>>>>> Hi Staffan, >>>>>>>>>> >>>>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Igor >>>>>>>>>> >>>>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote: >>>>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils, >>>>>>>>>>> perhaps he has future plans for this. >>>>>>>>>>> Igor? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable >>>>>>>>>>>> outside these specific tests? Should it really be part of the test >>>>>>>>>>>> library? >>>>>>>>>>>> >>>>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij >>>>>>>>>>>>> Pochepko wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Adding hotspot-dev for wider audience. >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: >>>>>>>>>>>>>> Test task: JMX- tests >>>>>>>>>>>>>> and >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes >>>>>>>>>>>>>> in testlibrary for JDK-8059613 >>>>>>>>>>>>>> >>>>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>>>>>>>>>> testing thresholds, usage, >>>>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in >>>>>>>>>>>>>> tests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Additional note: this patch assumes >>>>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" >>>>>>>>>>>>>> is fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Dmitrij >>>>>>>> -- >>>>>>>> Igor >>>>>> -- >>>>>> Igor From filipp.zhinkin at oracle.com Thu Dec 11 12:33:43 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 11 Dec 2014 16:33:43 +0400 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <548888D0.3030103@oracle.com> References: <54884F27.2020206@oracle.com> <548888D0.3030103@oracle.com> Message-ID: <54898F27.4090903@oracle.com> Vladimir, thank you for review. Bengt's fix already pushed into gc repo, so I've just updated webrev to use gc repo instead of comp one: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.01/ Thanks, Filipp. On 12/10/2014 09:54 PM, Vladimir Kozlov wrote: > Filipp, > > Your changes are in conflict with 8067115 changes in hs-gc repo: > > http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ > > Please, use gc repo instead of hs-comp and coordinate the push with Bengt. > > Otherwise looks good. > > Thanks, > Vladimir > > On 12/10/14 5:48 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a fix for 8066862. >> >> Issue: >> testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with >> RuntimeException: All Platform's methods with signature '():Z' should be >> tested >> >> Root cause: >> In order to prevent issues caused by the fact that some mutually exclusive >> predicates may return "true" on on the same platform (for example if >> isARM and >> isPPC will return true simultaneously) I decided to check in test if all >> Platform's methods with '():Z' signature were tested. >> >> Fix for 8039995 added new methods with "():Z" signature, but these >> methods were >> not marked in TestMutuallyExclusivePlatformPredicates as methods that >> should be ignored. >> >> Proposed fix: >> Mark newly added methods as ignored in >> TestMutuallyExclusivePlatformPredicates.java, >> add this test to sanity test group in order to run it in JPRT >> >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ >> Testing: manual & automated From vladimir.x.ivanov at oracle.com Thu Dec 11 12:46:11 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 11 Dec 2014 15:46:11 +0300 Subject: Deoptimize on putfield CallSite.target? In-Reply-To: References: Message-ID: <54899213.8040802@oracle.com> Krystal, I agree with your reasoning. There's no particular reason to keep this code. CallSite.target is package-private and there's a contract in java.lang.invoke package to change it using MethodHandleNatives.setCallSiteTargetNormal & MethodHandleNatives.setCallSiteTargetVolatile. IMO, it worth a cleanup. Feel free to submit a patch. Best regards, Vladimir Ivanov On 12/11/14, 2:59 AM, Krystal Mok wrote: > Hi everyone, > > I'd like to ask a question on the handling of setting CallSite.target in > compiled code. > Specifically, is the following piece of code in C2's > Parse::do_field_access() [1] necessary? > > // Deoptimize on putfield writes to call site target field. > if (!is_get && field->is_call_site_target()) { > uncommon_trap(Deoptimization::Reason_unhandled, > Deoptimization::Action_reinterpret, > NULL, "put to call site target field"); > return; > } > > If it is necessary, then why isn't it mirrored in C1's > GraphBuilder::access_field() [2] ? > > My take is that the C2 deoptimization is unnecessary here, since a > dependency is added when the compilers speculatively take a > CallSite.target as constant. > > There's no internal Java code that would do a putfield on a > CallSite.target anyway, and all external requests to change the target > would have gone through CallSite.setTarget(), which is appropriately > routed to the runtime already. > > I'm okay with the "it won't hurt to leave the code there" idea. Just > want to make sure I understood things correctly. > > Thanks, > Kris > > [1]: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/38cb4fbd47e3/src/share/vm/opto/parse3.cpp#l104 From pavel.punegov at oracle.com Thu Dec 11 13:41:42 2014 From: pavel.punegov at oracle.com (Pavel Punegov) Date: Thu, 11 Dec 2014 16:41:42 +0300 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <5489475D.9020907@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> <548212BE.7010500@oracle.com> <54855381.8030002@oracle.com> <54888A10.90800@oracle.com> <5489475D.9020907@oracle.com> Message-ID: <54899F16.5000406@oracle.com> Igor and Tobias, thank you for your reviews. I submitted an issue for the nmethod locking: https://bugs.openjdk.java.net/browse/JDK-8067229 On 11.12.2014 10:27, Tobias Hartmann wrote: > Hi, > > I agree with Igor that concurrent removal of nmethods by the sweeper may be a > problem. I think in 'WB_GetNMethod' we should at least acquire the nmethod lock > (using 'nmethodLocker') to prevent concurrent removal. As far as I understand, > the JNI functions copy the nmethod data. It should be fine for the sweeper to > remove the nmethod afterwards. As a result, the data may be outdated and we > should not expect Whitebox.getNMethod() to always return a NMethod object, even > if the corresponding method was compiled right before. > > Maybe you can file a separate bug for that issue. > > Otherwise your change looks good (not a reviewer). > > Thanks, > Tobias > > On 10.12.2014 18:59, Pavel Punegov wrote: >> Hi Tobias and Igor, >> >> could you please review this: >> http://cr.openjdk.java.net/~ppunegov/8059575/webrev.05/ >> >> I replaced the check for OSR-methods to skip transitions after deoptimization as >> they may make intermittent failures. >> See 67-70 lines at LevelTransitionTest.java >> >> I will file a separate RFE to improve this test to be able to check transitions >> after deopt too. >> >> Testing: jprt, locally >> >> On 08.12.2014 10:30, Tobias Hartmann wrote: >>> Hi Pavel, >>> >>> looks good (not a reviewer). >>> >>> Best, >>> Tobias >>> >>> On 05.12.2014 21:17, Pavel Punegov wrote: >>>> Hi Tobias, >>>> >>>> see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ >>>> >>>> I added TransitionsTestExecutor.java class that checks if TieredCompilation is >>>> available in the VM it was started with. Then it starts test for >>>> CompilatonPolicyChoice 2 and 3. >>>> >>>> On 01.12.2014 11:27, Tobias Hartmann wrote: >>>>> Hi Pavel, >>>>> >>>>> the tests fail with a client VM: >>>>> >>>>>> Error occurred during initialization of VM >>>>>> Incompatible compilation policy selected >>>>> Please execute them on JPRT to make sure they work on all platforms. >>>>> >>>>> Best, >>>>> Tobias >>>>> >>>>> On 28.11.2014 13:27, Pavel Punegov wrote: >>>>>> Hi all, >>>>>> >>>>>> please review new tests developed as a part of the test task: >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >>>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >>>>>> >>>>>> Description: >>>>>> There are two tests to verify level transitions in Tiered Compilation: >>>>>> 1. LevelTransitionTest verifies that in case of no load on compiler queues >>>>>> test >>>>>> methods go through common transition patterns: >>>>>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >>>>>> trivial methods, and 0 -> 4 after deoptimization. >>>>>> Test provokes compilations of the method and checks that all transitions are >>>>>> correct for CompilationPolicyChoice=2 and 3. >>>>>> >>>>>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used for >>>>>> 8056071 (see [*] for details). It checks that all constant getters are always >>>>>> compiled with C1. >>>>>> >>>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >>>>>> >>>>>> Testing: done locally >>>>>> -- Thanks, Pavel Punegov From tobias.hartmann at oracle.com Thu Dec 11 14:57:00 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 15:57:00 +0100 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <5487285A.8000402@oracle.com> References: <5487285A.8000402@oracle.com> Message-ID: <5489B0BC.4000203@oracle.com> Hi Pavel, looks good (not a reviewer). Please also run the tests on JPRT. Best, Tobias On 09.12.2014 17:50, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8059551 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.00/ > > > It introduces several stress tests for segmented code cache. There are main > thread that calls given method and checks its return value and several testing > threads: > > * OverloadCompileQueueTest - locks compilation for random time periods trying > to full compile queues and to break tested method compilation; > * RandomAllocationTest - randomly allocates and removes "dummy" code blobs in > different code cache heaps tries to corrupt tested method code in code cache; > * UnexpectedDeoptimizationTest - deoptimizes on stack frames in random times > tries to break tested method execution/return value > > > Testing: manual > > ------------------- > Thanks, > Pavel From pavel.chistyakov at oracle.com Thu Dec 11 15:19:41 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Thu, 11 Dec 2014 07:19:41 -0800 (PST) Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests Message-ID: <5f7c6fc5-c151-42d1-9e12-be3bb03d8f99@default> Hi Tobias, Thank you for review. ------------- Pavel ----- Original Message ----- From: tobias.hartmann at oracle.com To: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net Sent: Thursday, December 11, 2014 5:57:06 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests Hi Pavel, looks good (not a reviewer). Please also run the tests on JPRT. Best, Tobias On 09.12.2014 17:50, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8059551 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.00/ > > > It introduces several stress tests for segmented code cache. There are main > thread that calls given method and checks its return value and several testing > threads: > > * OverloadCompileQueueTest - locks compilation for random time periods trying > to full compile queues and to break tested method compilation; > * RandomAllocationTest - randomly allocates and removes "dummy" code blobs in > different code cache heaps tries to corrupt tested method code in code cache; > * UnexpectedDeoptimizationTest - deoptimizes on stack frames in random times > tries to break tested method execution/return value > > > Testing: manual > > ------------------- > Thanks, > Pavel From david.r.chase at oracle.com Thu Dec 11 16:31:42 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 11 Dec 2014 11:31:42 -0500 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <5487285A.8000402@oracle.com> References: <5487285A.8000402@oracle.com> Message-ID: <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> Also looks good, except for two extremely picky details 1. "Exception occured during test method execution" should be "occurred" (two R's), string occurs twice in patch. and (very picky) 2. "TESTBUG: lockUnlock'er thread was unexpectedly interrupted" I think maybe "lockUnlock-er" or even "lockUnlocker". ( ' in a word implies omitted letters, "don't" for "do not", 'n' for "and" ) Again, tiny details, but if you haven't pushed yet.... David On 2014-12-09, at 11:50 AM, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8059551 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.00/ > > It introduces several stress tests for segmented code cache. There are main thread that calls given method and checks its return value and several testing threads: > ? OverloadCompileQueueTest - locks compilation for random time periods trying to full compile queues and to break tested method compilation; > ? RandomAllocationTest - randomly allocates and removes "dummy" code blobs in different code cache heaps tries to corrupt tested method code in code cache; > ? UnexpectedDeoptimizationTest - deoptimizes on stack frames in random times tries to break tested method execution/return value > > Testing: manual > > ------------------- > Thanks, > Pavel -------------- 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: From aph at redhat.com Thu Dec 11 16:37:28 2014 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Dec 2014 16:37:28 +0000 Subject: [aarch64-port-dev ] Assertion failed: int pressure is incorrect Message-ID: <5489C848.5050907@redhat.com> I'm occasionally seeing this: # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/scratch1/large-codecache/hotspot/src/share/vm/opto/ifg.cpp:693), pid=9212, tid=4395909313024 # assert(int_pressure.current_pressure() == count_int_pressure(liveout)) failed: the int pressure is incorrect # Does anyone know what might cause this? Perhaps a bug in my back end? If not, can I please have some advice about how to debug it? I'm only seeing this with a fairly recent cut of JDK9. Thanks, Andrew, From vladimir.kozlov at oracle.com Thu Dec 11 17:42:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Dec 2014 09:42:35 -0800 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <54898F27.4090903@oracle.com> References: <54884F27.2020206@oracle.com> <548888D0.3030103@oracle.com> <54898F27.4090903@oracle.com> Message-ID: <5489D78B.2030501@oracle.com> Good. Thanks, Vladimir On 12/11/14 4:33 AM, Filipp Zhinkin wrote: > Vladimir, > > thank you for review. > > Bengt's fix already pushed into gc repo, > so I've just updated webrev to use gc repo instead of comp one: > > http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.01/ > > Thanks, > Filipp. > > On 12/10/2014 09:54 PM, Vladimir Kozlov wrote: >> Filipp, >> >> Your changes are in conflict with 8067115 changes in hs-gc repo: >> >> http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ >> >> Please, use gc repo instead of hs-comp and coordinate the push with Bengt. >> >> Otherwise looks good. >> >> Thanks, >> Vladimir >> >> On 12/10/14 5:48 AM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> please review a fix for 8066862. >>> >>> Issue: >>> testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with >>> RuntimeException: All Platform's methods with signature '():Z' should be >>> tested >>> >>> Root cause: >>> In order to prevent issues caused by the fact that some mutually exclusive >>> predicates may return "true" on on the same platform (for example if >>> isARM and >>> isPPC will return true simultaneously) I decided to check in test if all >>> Platform's methods with '():Z' signature were tested. >>> >>> Fix for 8039995 added new methods with "():Z" signature, but these >>> methods were >>> not marked in TestMutuallyExclusivePlatformPredicates as methods that >>> should be ignored. >>> >>> Proposed fix: >>> Mark newly added methods as ignored in >>> TestMutuallyExclusivePlatformPredicates.java, >>> add this test to sanity test group in order to run it in JPRT >>> >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ >>> Testing: manual & automated > From vladimir.kozlov at oracle.com Thu Dec 11 21:57:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Dec 2014 13:57:11 -0800 Subject: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout In-Reply-To: <54872848.2050002@oracle.com> References: <54872848.2050002@oracle.com> Message-ID: <548A1337.1080304@oracle.com> Why it is a problem? /** * Class which runs another Runnable in infinite loop with certain pauses * between cycles. */ It does not say that it will not pause for few instructions to execute Thread.sleep(0). Thanks, Vladimir On 12/9/14 8:50 AM, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066896 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066896/webrev.00/ > > > Problem: > InfiniteLoop allows zero value as timeout and waste time for Thread.sleep(0) call that is not needed in this case. > > Solution: > Add a condition for skipping 0 (zero) timeout when calling Thread.sleep > > Testing: manual > > ------------------- > Thanks, > Pavel From vladimir.kozlov at oracle.com Thu Dec 11 22:00:51 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Dec 2014 14:00:51 -0800 Subject: RFR (XXS): 8066473: Port timeout utils from jdk test library into hotspot In-Reply-To: <54872850.1060508@oracle.com> References: <54872850.1060508@oracle.com> Message-ID: <548A1413.3070508@oracle.com> Seems fine. thanks, Vladimir On 12/9/14 8:50 AM, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066473 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066473/webrev.00/ > > > We need some timeout staff that exists in jdk testlibrary in hotspot tests. > This fix ports DEFAULT_TEST_TIMEOUT constant and adjustTimeout method. > > Testing: manual > > ------------------- > Thanks, > Pavel From filipp.zhinkin at oracle.com Fri Dec 12 05:55:18 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 12 Dec 2014 09:55:18 +0400 Subject: [9] RFR (XS): JDK-8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms In-Reply-To: <5489D78B.2030501@oracle.com> References: <54884F27.2020206@oracle.com> <548888D0.3030103@oracle.com> <54898F27.4090903@oracle.com> <5489D78B.2030501@oracle.com> Message-ID: <548A8346.5020300@oracle.com> Thank you, Vladimir. Regards, Filipp. On 12/11/2014 09:42 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/11/14 4:33 AM, Filipp Zhinkin wrote: >> Vladimir, >> >> thank you for review. >> >> Bengt's fix already pushed into gc repo, >> so I've just updated webrev to use gc repo instead of comp one: >> >> http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.01/ >> >> Thanks, >> Filipp. >> >> On 12/10/2014 09:54 PM, Vladimir Kozlov wrote: >>> Filipp, >>> >>> Your changes are in conflict with 8067115 changes in hs-gc repo: >>> >>> http://cr.openjdk.java.net/~brutisso/8067115/webrev.00/ >>> >>> Please, use gc repo instead of hs-comp and coordinate the push with Bengt. >>> >>> Otherwise looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/10/14 5:48 AM, Filipp Zhinkin wrote: >>>> Hi all, >>>> >>>> please review a fix for 8066862. >>>> >>>> Issue: >>>> testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fails with >>>> RuntimeException: All Platform's methods with signature '():Z' should be >>>> tested >>>> >>>> Root cause: >>>> In order to prevent issues caused by the fact that some mutually exclusive >>>> predicates may return "true" on on the same platform (for example if >>>> isARM and >>>> isPPC will return true simultaneously) I decided to check in test if all >>>> Platform's methods with '():Z' signature were tested. >>>> >>>> Fix for 8039995 added new methods with "():Z" signature, but these >>>> methods were >>>> not marked in TestMutuallyExclusivePlatformPredicates as methods that >>>> should be ignored. >>>> >>>> Proposed fix: >>>> Mark newly added methods as ignored in >>>> TestMutuallyExclusivePlatformPredicates.java, >>>> add this test to sanity test group in order to run it in JPRT >>>> >>>> >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8066862 >>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8066862/webrev.00/ >>>> Testing: manual & automated >> From cnewland at chrisnewland.com Fri Dec 12 08:31:29 2014 From: cnewland at chrisnewland.com (Chris Newland) Date: Fri, 12 Dec 2014 08:31:29 -0000 Subject: %ld instead of %d for LogCompilation counts? In-Reply-To: <5485F3B1.4070405@oracle.com> References: <548240FB.2030804@oracle.com> <5485F3B1.4070405@oracle.com> Message-ID: Hi Vladimir, I've tested changing %g to %f in those 2 places on OpenJDK9 and it looks good: No accuracy is lost and I can parse using Double.valueOf().longValue() to get a cardinal number for the count. Kind regards, Chris On Mon, December 8, 2014 18:53, Vladimir Kozlov wrote: > Thank you, Chris > > > What do you think about using %f as John suggested? Will it solve your > problem? > > Both cases may have a fractional part and with 'long' it will be lost. > > > Thanks, > Vladimir > > > On 12/8/14 3:56 AM, Chris Newland wrote: > >> Hi Vladimir, >> >> >> The believe the only other LogCompilation output where %g is used for a >> cardinal number is this one? >> >> share/vm/opto/parse1.cpp:443: >> >> >> log->begin_head("parse method='%d' uses='%g'", >> log->identify(parse_method), expected_uses); >> >> >> Kind regards, >> >> >> Chris >> >> >> On Fri, December 5, 2014 23:34, Vladimir Kozlov wrote: >> >>> Hi, >>> >>> >>> >>> The output was produced by following lines: >>> >>> >>> >>> C->log()->elem("branch target_bci='%d' taken='%d' not_taken='%d' >>> cnt='%g' prob='%s'", iter().get_dest(), taken, not_taken, cnt, >>> prob_str); >>> >>> 'cnt' is declared as 'float' and defined as: >>> >>> >>> >>> cnt = (taken + not_taken) / FreqCountInvocations; >>> >>> I think it is artifact from long time ago when FreqCountInvocations >>> was >>> >>>> 1. And to avoid integer overflow, so we want to keep variable as >>>> float. >>>> >>> >>> But I am fine to change log output to long by converting it to >>> (jlong)cnt and using JLONG_FORMAT format. >>> >>> >>> >>> Do you know other places where we use %g for counters? >>> >>> >>> >>> Thanks, >>> Vladimir >>> >>> >>> >>> On 12/5/14 1:09 PM, Chris Newland wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> I've encountered some LogCompilation counters in 8u25 that are >>>> getting printed in exponential form in hotspot.log : >>>> >>>> >>> cnt='2.38658e+06' prob='0.00990148'/> >>>> >>>> This is harder to parse and loses accuracy because %d is used as a >>>> formatter in hotspot/src/share/vm/opto/parse2.cpp: >>>> >>>> if (C->log() != NULL) { C->log()->elem("branch target_bci='%d' >>>> taken='%d' not_taken='%d'", iter().get_dest(), taken, not_taken); } >>>> >>>> >>>> >>>> Would it be possible to modify some or all of the LogCompilation >>>> format strings to use %ld so that large integers can be printed >>>> without exponents? >>>> >>>> I don't mind going through the OpenJDK motions to submit this as a >>>> patch if it's a sensible idea. >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Chris >>>> >>>> >>>> >>> >> >> > From tobias.hartmann at oracle.com Fri Dec 12 08:52:20 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 12 Dec 2014 09:52:20 +0100 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <54899F16.5000406@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> <548212BE.7010500@oracle.com> <54855381.8030002@oracle.com> <54888A10.90800@oracle.com> <5489475D.9020907@oracle.com> <54899F16.5000406@oracle.com> Message-ID: <548AACC4.60609@oracle.com> Thanks, Pavel. Best, Tobias On 11.12.2014 14:41, Pavel Punegov wrote: > Igor and Tobias, > > thank you for your reviews. > I submitted an issue for the nmethod locking: > https://bugs.openjdk.java.net/browse/JDK-8067229 > > On 11.12.2014 10:27, Tobias Hartmann wrote: >> Hi, >> >> I agree with Igor that concurrent removal of nmethods by the sweeper may be a >> problem. I think in 'WB_GetNMethod' we should at least acquire the nmethod lock >> (using 'nmethodLocker') to prevent concurrent removal. As far as I understand, >> the JNI functions copy the nmethod data. It should be fine for the sweeper to >> remove the nmethod afterwards. As a result, the data may be outdated and we >> should not expect Whitebox.getNMethod() to always return a NMethod object, even >> if the corresponding method was compiled right before. >> >> Maybe you can file a separate bug for that issue. >> >> Otherwise your change looks good (not a reviewer). >> >> Thanks, >> Tobias >> >> On 10.12.2014 18:59, Pavel Punegov wrote: >>> Hi Tobias and Igor, >>> >>> could you please review this: >>> http://cr.openjdk.java.net/~ppunegov/8059575/webrev.05/ >>> >>> I replaced the check for OSR-methods to skip transitions after deoptimization as >>> they may make intermittent failures. >>> See 67-70 lines at LevelTransitionTest.java >>> >>> I will file a separate RFE to improve this test to be able to check transitions >>> after deopt too. >>> >>> Testing: jprt, locally >>> >>> On 08.12.2014 10:30, Tobias Hartmann wrote: >>>> Hi Pavel, >>>> >>>> looks good (not a reviewer). >>>> >>>> Best, >>>> Tobias >>>> >>>> On 05.12.2014 21:17, Pavel Punegov wrote: >>>>> Hi Tobias, >>>>> >>>>> see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ >>>>> >>>>> I added TransitionsTestExecutor.java class that checks if TieredCompilation is >>>>> available in the VM it was started with. Then it starts test for >>>>> CompilatonPolicyChoice 2 and 3. >>>>> >>>>> On 01.12.2014 11:27, Tobias Hartmann wrote: >>>>>> Hi Pavel, >>>>>> >>>>>> the tests fail with a client VM: >>>>>> >>>>>>> Error occurred during initialization of VM >>>>>>> Incompatible compilation policy selected >>>>>> Please execute them on JPRT to make sure they work on all platforms. >>>>>> >>>>>> Best, >>>>>> Tobias >>>>>> >>>>>> On 28.11.2014 13:27, Pavel Punegov wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> please review new tests developed as a part of the test task: >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >>>>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >>>>>>> >>>>>>> Description: >>>>>>> There are two tests to verify level transitions in Tiered Compilation: >>>>>>> 1. LevelTransitionTest verifies that in case of no load on compiler queues >>>>>>> test >>>>>>> methods go through common transition patterns: >>>>>>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >>>>>>> trivial methods, and 0 -> 4 after deoptimization. >>>>>>> Test provokes compilations of the method and checks that all transitions are >>>>>>> correct for CompilationPolicyChoice=2 and 3. >>>>>>> >>>>>>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used >>>>>>> for >>>>>>> 8056071 (see [*] for details). It checks that all constant getters are >>>>>>> always >>>>>>> compiled with C1. >>>>>>> >>>>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >>>>>>> >>>>>>> Testing: done locally >>>>>>> > From albert.noll at oracle.com Fri Dec 12 10:08:13 2014 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 12 Dec 2014 11:08:13 +0100 Subject: RFR(S): 8027829: CompileCommand does not accept all JLS-conformant class/method names In-Reply-To: <54876BAB.6070502@oracle.com> References: <546F6201.6070000@oracle.com> <546F5AA6.3020805@oracle.com> <547331A5.40609@oracle.com> <54733A50.5030705@oracle.com> <5474804A.4040208@oracle.com> <54876BAB.6070502@oracle.com> Message-ID: <548ABE8D.1090003@oracle.com> Some minor things: 518 // The characters allowed is based on the JVM specification. I am not sure if this is a correct sentence, but I am not a native speaker. "The JVM specification defines the allowed characters" sounds more correct to me. 519 // Some tokens disallowed in the JVMS have some meaning 520 // when parsing so we need to include them here. Same here. Maybe we could use: "Tokens that are disallowed by the JVM specification can have a meaning to the parser so we need to include them here..." // The parser do not enforce all rules of the JVMS - a successful parse "The parser *does* not .... Best, Albert On 12/09/2014 10:37 PM, Vladimir Kozlov wrote: > Missing "method" at the end: > > ! tty->print_cr(" exclude, - don't compile or inline > this "); > > Also add that these commands can be listed in .hotspot_compiler file > instead of command line. > > Otherwise looks good. > > Thanks, > Vladimir > > On 11/25/14 5:12 AM, Nils Eliasson wrote: >> Hi, >> >> I added an improved help text and included a format description that is >> printed on parse error. >> >> webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.04/ >> >> Thanks! >> Nils >> >> On 2014-11-24 15:01, Vladimir Ivanov wrote: >>> Looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/24/14, 5:24 PM, Nils Eliasson wrote: >>>> Hi Vladimir, >>>> >>>> You are absolutely correct. Of course it is the JVMS that should be >>>> targeted. >>>> >>>> I have updated the change adding all characters that do not create >>>> problem with the >>>> command line parser or pattern matcher, and are allowed by the JVMS. >>>> >>>> Also fixed so that we can match the signature without requiring a >>>> whitespace before. >>>> >>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.02 >>>> >>>> Thanks, >>>> //Nils >>>> >>>> On 2014-11-21 16:30, Vladimir Ivanov wrote: >>>>> Nils, >>>>> >>>>> 2 typos: Charachter.isJavaIdentiferPart >>>>> >>>>> Are there any plans to extend this further past JLS? >>>>> JVMS allows arbitrary UTF8 string to be used as a class/method/field >>>>> name and some JVM languages use that. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/21/14, 8:02 PM, Nils Eliasson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this patch. >>>>>> >>>>>> It includes two fixes: >>>>>> >>>>>> 1) Improve CompileCommand so that it now accepts all JLS conformant >>>>>> class and method names. (With one exception - \u0000 can not be used >>>>>> since the commandline parsing uses null terminated strings.) For >>>>>> parsing >>>>>> simplicity it is possible in some case to specify a pattern that is >>>>>> not >>>>>> JLS-conformant. That is however not a problem - the pattern will be >>>>>> saved as a symbol and will simply never match any allowed name. >>>>>> >>>>>> 2) Fixed some output to make it more understandable. The user is >>>>>> specifying the flag "CompileCommand" and any output should be >>>>>> annotated >>>>>> with the flag name, and not "CompilerOracle". Also added more >>>>>> describing >>>>>> error messages. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027829 >>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.01/ >>>>>> >>>>>> Regards, >>>>>> Nils Eliasson >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Dec 12 10:20:47 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 12 Dec 2014 11:20:47 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <5480B272.3030808@oracle.com> References: <5480B272.3030808@oracle.com> Message-ID: <548AC17F.7020703@oracle.com> Hi Dmitrij, here are some comments about the tests (not a reviewer). UsageThresholdNotExceededTest: - You can use CodeCacheUtils.MIN_ALLOCATION instead of CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. - Please add a comment to 'CodeCacheUtils.WB.fullGC()' UsageThresholdIncreasedTest: - Typo "hasn't been hit after allocationg smaller" -> "allocating" - Maybe you should disable code cache sweeping here as well (as you did for the UsageThresholdNotExceededTest) UsageThresholdExceededTest: - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold if the code cache sweeper is enabled and removes nmethods in between. I think you should disable code cache sweeping. - Please print information about the counters if the assert is hit in line 66. ThresholdNotificationsTest: - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" - If not all notifications are received/handled, the test will timeout at line 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and print a useful error message if the timeout is reached. PoolsIndependenceTest: - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" - Typos "event to be recieved ..." -> "received" (3x) PeakUsageTest: - Compilation is not disabled. The asserts may fail because a method is compiled in between. Even with compilation disabled, adapters and other non-nmethod code may be generated and stored in the non-nmethod code heap. ManagerNamesTest: - Typo: "calls in case on segmented code cache" -> "of segmented" GetUsageTest: - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? General: - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it would be easier to understand if you invoke WB.allocateCodeBlob(...) directly. Please run the tests on JPRT! Thanks, Tobias On 04.12.2014 20:13, Dmitrij Pochepko wrote: > Hi, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: > JMX- tests > and > https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in > testlibrary for JDK-8059613 > > It introduce a number of tests for segmented code cache, mostly testing > thresholds, usage, > memory notifications using respective MemoryPoolMXBean(s). > There is also a small modification for testlibrary(8066440) used in tests. > > Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ > > Testing: manually, using fastdebug nightly build from 2014-12-02 > > Additional note: this patch assumes > "https://bugs.openjdk.java.net/browse/JDK-8065134 - > Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. > > Thanks, > Dmitrij From pavel.chistyakov at oracle.com Fri Dec 12 10:14:06 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Fri, 12 Dec 2014 13:14:06 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> References: <5487285A.8000402@oracle.com> <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> Message-ID: <548ABFEE.40307@oracle.com> David, thank you for review. Here is updated webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 -------------- Regards, Pavel On 11.12.2014 19:31, David Chase wrote: > Also looks good, except for two extremely picky details > > 1. "Exception occured during test method execution" > should be "occurred" (two R's), string occurs twice in patch. > > and (very picky) > > 2. "TESTBUG: lockUnlock'er thread was unexpectedly interrupted" > I think maybe "lockUnlock-er" or even "lockUnlocker". > > ( ' in a word implies omitted letters, "don't" for "do not", 'n' for "and" ) > > Again, tiny details, but if you haven't pushed yet.... > > David > > On 2014-12-09, at 11:50 AM, Pavel Chistyakov wrote: > >> Hi all, >> >> please review changes for: https://bugs.openjdk.java.net/browse/JDK-8059551 >> webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.00/ >> >> It introduces several stress tests for segmented code cache. There are main thread that calls given method and checks its return value and several testing threads: >> ? OverloadCompileQueueTest - locks compilation for random time periods trying to full compile queues and to break tested method compilation; >> ? RandomAllocationTest - randomly allocates and removes "dummy" code blobs in different code cache heaps tries to corrupt tested method code in code cache; >> ? UnexpectedDeoptimizationTest - deoptimizes on stack frames in random times tries to break tested method execution/return value >> >> Testing: manual >> >> ------------------- >> Thanks, >> Pavel From pavel.chistyakov at oracle.com Fri Dec 12 10:15:31 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Fri, 12 Dec 2014 13:15:31 +0300 Subject: RFR (XXS): 8066473: Port timeout utils from jdk test library into hotspot In-Reply-To: <548A1413.3070508@oracle.com> References: <54872850.1060508@oracle.com> <548A1413.3070508@oracle.com> Message-ID: <548AC043.2050600@oracle.com> Vladimir, thank you for review. ------------- Pavel On 12.12.2014 01:00, Vladimir Kozlov wrote: > Seems fine. > > thanks, > Vladimir > > On 12/9/14 8:50 AM, Pavel Chistyakov wrote: >> Hi all, >> >> please review changes for: >> https://bugs.openjdk.java.net/browse/JDK-8066473 >> webrev: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066473/webrev.00/ >> >> >> We need some timeout staff that exists in jdk testlibrary in hotspot >> tests. >> This fix ports DEFAULT_TEST_TIMEOUT constant and adjustTimeout method. >> >> Testing: manual >> >> ------------------- >> Thanks, >> Pavel From tatiana.pivovarova at oracle.com Fri Dec 12 12:37:29 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 12 Dec 2014 15:37:29 +0300 Subject: RFR(S): 8067211: rewrite Utils::fileAsString Message-ID: <548AE189.9020800@oracle.com> Hi all, please review this small patch bugid: https://bugs.openjdk.java.net/browse/JDK-8067211 webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8067211/webrev.00/ Problem: Utils::fileAsString implementation has several issues: - using '\n' instead of platform independent EOL - catching wide spectre of exceptions and "ignoring" them - partially duplicates code of Utils::fileAsList method which duplicates File::readAllLines Solution: - using library method for reading lines - using system property for EndOfLine. Testing: jprt Thanks, Tatiana From tatiana.pivovarova at oracle.com Fri Dec 12 12:46:19 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 12 Dec 2014 15:46:19 +0300 Subject: RFR(S): 8067211: rewrite Utils::fileAsString In-Reply-To: <548AE189.9020800@oracle.com> References: <548AE189.9020800@oracle.com> Message-ID: <548AE39B.2080808@oracle.com> Added hotspot-dev at openjdk.java.net On 12/12/2014 03:37 PM, Tatiana Pivovarova wrote: > Hi all, > > please review this small patch > > bugid: https://bugs.openjdk.java.net/browse/JDK-8067211 > webrev: > http://cr.openjdk.java.net/~ppunegov/tpivovarova/8067211/webrev.00/ > > Problem: > Utils::fileAsString implementation has several issues: > - using '\n' instead of platform independent EOL > - catching wide spectre of exceptions and "ignoring" them > - partially duplicates code of Utils::fileAsList method which > duplicates File::readAllLines > > Solution: > - using library method for reading lines > - using system property for EndOfLine. > > Testing: jprt > > Thanks, > Tatiana From david.r.chase at oracle.com Fri Dec 12 14:07:23 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 12 Dec 2014 09:07:23 -0500 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <548ABFEE.40307@oracle.com> References: <5487285A.8000402@oracle.com> <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> <548ABFEE.40307@oracle.com> Message-ID: On 2014-12-12, at 5:14 AM, Pavel Chistyakov wrote: > David, thank you for review. > Here is updated webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 That is excellent -- now we just need a real reviewer. 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: From vladimir.kempik at oracle.com Fri Dec 12 14:14:29 2014 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Fri, 12 Dec 2014 17:14:29 +0300 Subject: [7u] RFR: 8054478: C2: Incorrectly compiled char[] array access crashes JVM In-Reply-To: <5488729F.8080402@oracle.com> References: <5488729F.8080402@oracle.com> Message-ID: <548AF845.6000903@oracle.com> Hello Can I have somebody with jdk7u reviewer role to look at this please? Author of original commit approved it already. Thanks, Vladimir. On 10.12.2014 19:19, Vladimir Kempik wrote: > Hello > > Please review this backport of 8054478 to jdk7. > Few changes was needed to make it compatible with jdk7u: > - in connode.cpp use res->filter() instead of res->filter_speculative() > - enable TiredCompilation in testcase > - few other small changes. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8054478 > Webrev: http://cr.openjdk.java.net/~vkempik/8054478/webrev.00/ > Testing: jprt > Original fix: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/49dd956bc8c0 > > Thanks, Vladimir. From igor.veresov at oracle.com Fri Dec 12 18:02:57 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 12 Dec 2014 10:02:57 -0800 Subject: [7u] RFR: 8054478: C2: Incorrectly compiled char[] array access crashes JVM In-Reply-To: <548AF845.6000903@oracle.com> References: <5488729F.8080402@oracle.com> <548AF845.6000903@oracle.com> Message-ID: <9BB86838-F4EA-461C-965A-103134C63FBA@oracle.com> Good. igor > On Dec 12, 2014, at 6:14 AM, Vladimir Kempik wrote: > > Hello > > Can I have somebody with jdk7u reviewer role to look at this please? > > Author of original commit approved it already. > > Thanks, Vladimir. > On 10.12.2014 19:19, Vladimir Kempik wrote: >> Hello >> >> Please review this backport of 8054478 to jdk7. >> Few changes was needed to make it compatible with jdk7u: >> - in connode.cpp use res->filter() instead of res->filter_speculative() >> - enable TiredCompilation in testcase >> - few other small changes. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8054478 >> Webrev: http://cr.openjdk.java.net/~vkempik/8054478/webrev.00/ >> Testing: jprt >> Original fix: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/49dd956bc8c0 >> >> Thanks, Vladimir. > From vladimir.kozlov at oracle.com Fri Dec 12 20:05:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Dec 2014 12:05:47 -0800 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: References: <5487285A.8000402@oracle.com> <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> <548ABFEE.40307@oracle.com> Message-ID: <548B4A9B.2050603@oracle.com> Looks fine. Thanks, Vladimir On 12/12/14 6:07 AM, David Chase wrote: > > On 2014-12-12, at 5:14 AM, Pavel Chistyakov wrote: > >> David, thank you for review. >> Here is updated webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 > > That is excellent -- now we just need a real reviewer. > > David > From vladimir.kozlov at oracle.com Fri Dec 12 20:08:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Dec 2014 12:08:34 -0800 Subject: RFR(S): 8067211: rewrite Utils::fileAsString In-Reply-To: <548AE39B.2080808@oracle.com> References: <548AE189.9020800@oracle.com> <548AE39B.2080808@oracle.com> Message-ID: <548B4B42.5070109@oracle.com> Looks good. Thanks, Vladimir On 12/12/14 4:46 AM, Tatiana Pivovarova wrote: > Added hotspot-dev at openjdk.java.net > > On 12/12/2014 03:37 PM, Tatiana Pivovarova wrote: >> Hi all, >> >> please review this small patch >> >> bugid: https://bugs.openjdk.java.net/browse/JDK-8067211 >> webrev: http://cr.openjdk.java.net/~ppunegov/tpivovarova/8067211/webrev.00/ >> >> Problem: >> Utils::fileAsString implementation has several issues: >> - using '\n' instead of platform independent EOL >> - catching wide spectre of exceptions and "ignoring" them >> - partially duplicates code of Utils::fileAsList method which duplicates File::readAllLines >> >> Solution: >> - using library method for reading lines >> - using system property for EndOfLine. >> >> Testing: jprt >> >> Thanks, >> Tatiana > From vladimir.kozlov at oracle.com Fri Dec 12 20:42:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 12 Dec 2014 12:42:24 -0800 Subject: %ld instead of %d for LogCompilation counts? In-Reply-To: References: <548240FB.2030804@oracle.com> <5485F3B1.4070405@oracle.com> Message-ID: <548B5330.9060408@oracle.com> I filed RFE and we will fix it in jdk9: https://bugs.openjdk.java.net/browse/JDK-8067374 Thanks, Vladimir On 12/12/14 12:31 AM, Chris Newland wrote: > Hi Vladimir, > > I've tested changing %g to %f in those 2 places on OpenJDK9 and it looks > good: > > > > prob='4.99975e-05'/> > > No accuracy is lost and I can parse using Double.valueOf().longValue() to > get a cardinal number for the count. > > Kind regards, > > Chris > > > On Mon, December 8, 2014 18:53, Vladimir Kozlov wrote: >> Thank you, Chris >> >> >> What do you think about using %f as John suggested? Will it solve your >> problem? >> >> Both cases may have a fractional part and with 'long' it will be lost. >> >> >> Thanks, >> Vladimir >> >> >> On 12/8/14 3:56 AM, Chris Newland wrote: >> >>> Hi Vladimir, >>> >>> >>> The believe the only other LogCompilation output where %g is used for a >>> cardinal number is this one? >>> >>> share/vm/opto/parse1.cpp:443: >>> >>> >>> log->begin_head("parse method='%d' uses='%g'", >>> log->identify(parse_method), expected_uses); >>> >>> >>> Kind regards, >>> >>> >>> Chris >>> >>> >>> On Fri, December 5, 2014 23:34, Vladimir Kozlov wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> The output was produced by following lines: >>>> >>>> >>>> >>>> C->log()->elem("branch target_bci='%d' taken='%d' not_taken='%d' >>>> cnt='%g' prob='%s'", iter().get_dest(), taken, not_taken, cnt, >>>> prob_str); >>>> >>>> 'cnt' is declared as 'float' and defined as: >>>> >>>> >>>> >>>> cnt = (taken + not_taken) / FreqCountInvocations; >>>> >>>> I think it is artifact from long time ago when FreqCountInvocations >>>> was >>>> >>>>> 1. And to avoid integer overflow, so we want to keep variable as >>>>> float. >>>>> >>>> >>>> But I am fine to change log output to long by converting it to >>>> (jlong)cnt and using JLONG_FORMAT format. >>>> >>>> >>>> >>>> Do you know other places where we use %g for counters? >>>> >>>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> >>>> On 12/5/14 1:09 PM, Chris Newland wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I've encountered some LogCompilation counters in 8u25 that are >>>>> getting printed in exponential form in hotspot.log : >>>>> >>>>> >>>> cnt='2.38658e+06' prob='0.00990148'/> >>>>> >>>>> This is harder to parse and loses accuracy because %d is used as a >>>>> formatter in hotspot/src/share/vm/opto/parse2.cpp: >>>>> >>>>> if (C->log() != NULL) { C->log()->elem("branch target_bci='%d' >>>>> taken='%d' not_taken='%d'", iter().get_dest(), taken, not_taken); } >>>>> >>>>> >>>>> >>>>> Would it be possible to modify some or all of the LogCompilation >>>>> format strings to use %ld so that large integers can be printed >>>>> without exponents? >>>>> >>>>> I don't mind going through the OpenJDK motions to submit this as a >>>>> patch if it's a sensible idea. >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> Chris >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From dmitrij.pochepko at oracle.com Fri Dec 12 20:54:27 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 12 Dec 2014 23:54:27 +0300 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... Message-ID: <548B5603.5030902@oracle.com> Hi, Please review changes for https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm checks in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking which vm is run https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils chagnes from JDK-8059613 into jdk workspace https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom classloaders(parent-last and filtering one) for JDK-8066625 in testlibrary Description: A number of small testlibrary changes needed for further test development, 2 of 3 is porn from respective hotspot changes 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is FilterClassLoader - loads classes using target classloader in case class name meets provided condition, and using parent otherwise. 2nd is ParentLastURLClassLoader which loads classes using provided URL[] with fallback to parent, Webrevs: http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ Thanks, Dmitrij From igor.ignatyev at oracle.com Fri Dec 12 22:16:06 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 13 Dec 2014 01:16:06 +0300 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <548637E5.5060807@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> <547E352A.5040806@oracle.com> <548602CD.805@oracle.com> <54862C70.5020006@oracle.com> <54862ED1.5010305@oracle.com> <548637E5.5060807@oracle.com> Message-ID: <548B6926.1090606@oracle.com> Vladimir, I rewrote the test to use Phaser. this made the test more robust and removed needs for '::getCompiler' method. http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.02/ 211 lines changed: 203 ins; 8 del; 0 mod; (whitebox class changes) http://cr.openjdk.java.net/~iignatyev/8028595/top/webrev.00/ 1 line changed: 1 ins; 0 del; 0 mod; Thanks, Igor On 12/09/2014 02:44 AM, Vladimir Kozlov wrote: > On 12/8/14 3:05 PM, Igor Ignatyev wrote: >> On 12/09/2014 01:55 AM, Vladimir Kozlov wrote: >>> On 12/8/14 11:58 AM, Igor Ignatyev wrote: >>>> Vladimir, >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/ >>>> >>>> On 12/03/2014 12:54 AM, Vladimir Kozlov wrote: >>>>> On 12/2/14 1:32 AM, Igor Ignatyev wrote: >>>>>> Vladimir, >>>>>> >>>>>> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in >>>>>> 'non-makeNotEntrant' case, there's no way to determine if the method >>>>>> was >>>>>> deoptimized. >>>>> >>>>> I don't understand how you check that in the test. >>>> getCompiler returns 0 if method isn't compiled or (in my case) was >>>> deoptimized. TestCaseImpl::method uses 'getCompiler' method as a >>>> multiplier for result value. if TestCaseImpl::method returns 0, >>>> for-loop >>>> (lines 75--80) quits. >>> >>> Okay. I missed that compile() calls method() and returns sum of its >>> results. >>> >>>> >>>>> >>>>> If you only want to check if method was deoptimized you can check >>>>> MethodData::decompile_count(). >>>> >>>> MethodData::decompile_count is incremented only if nmethod is compiled >>>> by c2. so it can't be used. >>>>> >>>>> I don't like extending Unsafe API for just this test. >>>> well, I can move it to whitebox, if you don't mind to have intrinsics >>>> for it. >>> >>> I would rather see changes in nmethod and new WB accessors to it. >>> >>> And sorry, I don't like the test. The test does not have >>> comments/description. It is difficult to judge, is it doing what it is >>> suppose to do or not. >> yeap, sorry. I'll add the comments. >> >>> >>> nm->make_not_entrant() will call method()->clear_code(). So how you >>> expect that checkCompiled() will not throw Error after deoptimization?: >>> >>> 69 WHITE_BOX.deoptimizeFrames(makeNotEntrant); >>> 70 checkCompiled(); >>> >>> Your loop (lines 75--80) is in a race of compilations vs >>> deoptimizations. The test on machines with different numbers of threads >>> will behave differently. Where is guarantee that you will get your >>> result == 0 case? >>> Why do you even need these *concurrent* deoptimization, compilation >>> loops? >>> Can you do it synchronously? Execute method in separate thread and stop >>> it when you get compilation of requested level or other condition >>> (recursion level). Do deoptimization in main thread and see if methods >>> are deoptimized. >> >> WB::deoptimizeFrames has to deoptimize methods which are currently on >> stack, that's why I expect that checkCompiled on line 70 won't throw an >> exception and that's why I do need these concurrent >> deoptimization/compilation. > > So you are testing in first lines that if the compiled method does not > have the frame on stack it will not be deoptimized - *comment* please. > > Again. I think the test will be simpler if you execute compiled method > in a separate thread instead of main where you do all checks. > > Vladimir > >> >>> >>> Regards, >>> Vladimir >>> >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Thanks, >>>>>> Igor >>>>>> >>>>>> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >>>>>>> Why you need new Unsafe.getCompiler()? >>>>>>> >>>>>>> thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>>>>>>> 220 lines changed: 212 ins; 8 del; 0 mod; >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>>>>>>> 4 lines changed: 4 ins; 0 del; 0 mod; >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> please review the patch which adds >>>>>>>> - a new whitebox method 'deoptimizeFrames' which deoptimizes >>>>>>>> methods >>>>>>>> which are currently on stack >>>>>>>> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net >>>>>>>> which >>>>>>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 >>>>>>>> accordingly. >>>>>>>> >>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>>>>>>> testing: jprt + new added test >>>>>>>> >>>> >> From dmitrij.pochepko at oracle.com Fri Dec 12 22:39:28 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Sat, 13 Dec 2014 01:39:28 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <548AC17F.7020703@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> Message-ID: <548B6EA0.1010802@oracle.com> Hi all, i've corrected diff according to comments. please see corrected version(also modified according to latest commits) http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 a jprt testing job has been created: http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp Thanks, Dmitrij > Hi Dmitrij, > > here are some comments about the tests (not a reviewer). > > UsageThresholdNotExceededTest: > - You can use CodeCacheUtils.MIN_ALLOCATION instead of > CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. > - Please add a comment to 'CodeCacheUtils.WB.fullGC()' > > UsageThresholdIncreasedTest: > - Typo "hasn't been hit after allocationg smaller" -> "allocating" > - Maybe you should disable code cache sweeping here as well (as you did for the > UsageThresholdNotExceededTest) > > UsageThresholdExceededTest: > - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold > if the code cache sweeper is enabled and removes nmethods in between. I think > you should disable code cache sweeping. > - Please print information about the counters if the assert is hit in line 66. > > ThresholdNotificationsTest: > - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" > - If not all notifications are received/handled, the test will timeout at line > 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and > print a useful error message if the timeout is reached. > > PoolsIndependenceTest: > - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" > - Typos "event to be recieved ..." -> "received" (3x) > > PeakUsageTest: > - Compilation is not disabled. The asserts may fail because a method is compiled > in between. Even with compilation disabled, adapters and other non-nmethod code > may be generated and stored in the non-nmethod code heap. > > ManagerNamesTest: > - Typo: "calls in case on segmented code cache" -> "of segmented" > > GetUsageTest: > - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? > > General: > - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it > would be easier to understand if you invoke WB.allocateCodeBlob(...) directly. > > Please run the tests on JPRT! > > Thanks, > Tobias > > On 04.12.2014 20:13, Dmitrij Pochepko wrote: >> Hi, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: >> JMX- tests >> and >> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in >> testlibrary for JDK-8059613 >> >> It introduce a number of tests for segmented code cache, mostly testing >> thresholds, usage, >> memory notifications using respective MemoryPoolMXBean(s). >> There is also a small modification for testlibrary(8066440) used in tests. >> >> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >> >> Testing: manually, using fastdebug nightly build from 2014-12-02 >> >> Additional note: this patch assumes >> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. >> >> Thanks, >> Dmitrij From christian.thalinger at oracle.com Fri Dec 12 22:42:08 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 12 Dec 2014 14:42:08 -0800 Subject: Locating call sites of methods in C2 In-Reply-To: <20931467-4789-48E0-8851-CF775AE34882@gmail.com> References: <64E2023B-8362-4ED2-B755-366FAA5B615D@gmail.com> <3BC4BB0F-E901-4D59-95A5-BDC8B56D5B89@oracle.com> <20931467-4789-48E0-8851-CF775AE34882@gmail.com> Message-ID: > On Dec 8, 2014, at 7:46 PM, Manas Thakur wrote: > > Hi Christian > > Yes, I am looking for something similar: at the time I am compiling bar(), I want to know the BCI of the invoke instruction, as well as the caller method, because of which bar() was added to the compile queue. You can?t. bar() can be called from many different places and all call sites add to the invocation counter. It?s purely random which call site will trigger the method to be queued for compilation. > > Regards, > Manas > > >> On 08-Dec-2014, at 11:45 pm, Christian Thalinger > wrote: >> >> >>> On Dec 5, 2014, at 2:49 AM, Manas Thakur > wrote: >>> >>> Hi >>> >>> Is there a way to access the call-site (possibly in terms of the bytecode offset) of a method being compiled by C2? Doesn?t the current compile task store it in some variable? >> >> I?m not sure I understand. Are you asking for the BCI (bytecode index) of the invoke instruction to method bar if you compile a method foo which calls bar: >> >> void foo() { >> bar(); >> } >> >>> >>> Regards, >>> Manas >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Mon Dec 15 11:23:16 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 15 Dec 2014 12:23:16 +0100 Subject: RFR(S): 8027829: CompileCommand does not accept all JLS-conformant class/method names In-Reply-To: <548ABE8D.1090003@oracle.com> References: <546F6201.6070000@oracle.com> <546F5AA6.3020805@oracle.com> <547331A5.40609@oracle.com> <54733A50.5030705@oracle.com> <5474804A.4040208@oracle.com> <54876BAB.6070502@oracle.com> <548ABE8D.1090003@oracle.com> Message-ID: <548EC4A4.8060608@oracle.com> I updated the webrev with suggestions and corrections from Albert, Dean, Doug and Vladimir. 1) Removed 'this method' from the descriptions of the commands and instead clarified that the pattern defined a set of methods in the text 2) Removed some quotes from the examples. Quotes are a character allowed in the names and a part of the method patterns 3) Added a note about the .hotspot_compiler file webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.07 bug: https://bugs.openjdk.java.net/browse/JDK-8027829 Thanks, Nils On 2014-12-12 11:08, Albert Noll wrote: > Some minor things: > > 518 // The characters allowed is based on the JVM specification. > I am not sure if this is a correct sentence, but I am not a native > speaker. > "The JVM specification defines the allowed characters" sounds more > correct to me. > > 519 // Some tokens disallowed in the JVMS have some meaning > 520 // when parsing so we need to include them here. > > Same here. > Maybe we could use: > "Tokens that are disallowed by the JVM specification can have a > meaning to the parser so we need to include them here..." > > // The parser do not enforce all rules of the JVMS - a successful parse > "The parser *does* not .... > > Best, > Albert > > > On 12/09/2014 10:37 PM, Vladimir Kozlov wrote: >> Missing "method" at the end: >> >> ! tty->print_cr(" exclude, - don't compile or inline >> this "); >> >> Also add that these commands can be listed in .hotspot_compiler file >> instead of command line. >> >> Otherwise looks good. >> >> Thanks, >> Vladimir >> >> On 11/25/14 5:12 AM, Nils Eliasson wrote: >>> Hi, >>> >>> I added an improved help text and included a format description that is >>> printed on parse error. >>> >>> webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.04/ >>> >>> Thanks! >>> Nils >>> >>> On 2014-11-24 15:01, Vladimir Ivanov wrote: >>>> Looks good. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/24/14, 5:24 PM, Nils Eliasson wrote: >>>>> Hi Vladimir, >>>>> >>>>> You are absolutely correct. Of course it is the JVMS that should be >>>>> targeted. >>>>> >>>>> I have updated the change adding all characters that do not create >>>>> problem with the >>>>> command line parser or pattern matcher, and are allowed by the JVMS. >>>>> >>>>> Also fixed so that we can match the signature without requiring a >>>>> whitespace before. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.02 >>>>> >>>>> Thanks, >>>>> //Nils >>>>> >>>>> On 2014-11-21 16:30, Vladimir Ivanov wrote: >>>>>> Nils, >>>>>> >>>>>> 2 typos: Charachter.isJavaIdentiferPart >>>>>> >>>>>> Are there any plans to extend this further past JLS? >>>>>> JVMS allows arbitrary UTF8 string to be used as a class/method/field >>>>>> name and some JVM languages use that. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/21/14, 8:02 PM, Nils Eliasson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this patch. >>>>>>> >>>>>>> It includes two fixes: >>>>>>> >>>>>>> 1) Improve CompileCommand so that it now accepts all JLS conformant >>>>>>> class and method names. (With one exception - \u0000 can not be >>>>>>> used >>>>>>> since the commandline parsing uses null terminated strings.) For >>>>>>> parsing >>>>>>> simplicity it is possible in some case to specify a pattern that is >>>>>>> not >>>>>>> JLS-conformant. That is however not a problem - the pattern will be >>>>>>> saved as a symbol and will simply never match any allowed name. >>>>>>> >>>>>>> 2) Fixed some output to make it more understandable. The user is >>>>>>> specifying the flag "CompileCommand" and any output should be >>>>>>> annotated >>>>>>> with the flag name, and not "CompilerOracle". Also added more >>>>>>> describing >>>>>>> error messages. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027829 >>>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.01/ >>>>>>> >>>>>>> Regards, >>>>>>> Nils Eliasson >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Mon Dec 15 11:53:28 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 15 Dec 2014 12:53:28 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <548B6EA0.1010802@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> <548B6EA0.1010802@oracle.com> Message-ID: <548ECBB8.7010008@oracle.com> Hi Dmitrij, For PeakUsageTest I'm still worried that the asserts may fail if class loading happens in between and triggers compilation of adapters. Why did you surround two of the asserts with a try? Like this the assert is useless because we ignore failures. Otherwise it looks good. Best, Tobias On 12.12.2014 23:39, Dmitrij Pochepko wrote: > Hi all, > > i've corrected diff according to comments. > > please see corrected version(also modified according to latest commits) > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 > http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 > > a jprt testing job has been created: > http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp > > Thanks, > Dmitrij >> Hi Dmitrij, >> >> here are some comments about the tests (not a reviewer). >> >> UsageThresholdNotExceededTest: >> - You can use CodeCacheUtils.MIN_ALLOCATION instead of >> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. >> - Please add a comment to 'CodeCacheUtils.WB.fullGC()' >> >> UsageThresholdIncreasedTest: >> - Typo "hasn't been hit after allocationg smaller" -> "allocating" >> - Maybe you should disable code cache sweeping here as well (as you did for the >> UsageThresholdNotExceededTest) >> >> UsageThresholdExceededTest: >> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold >> if the code cache sweeper is enabled and removes nmethods in between. I think >> you should disable code cache sweeping. >> - Please print information about the counters if the assert is hit in line 66. >> >> ThresholdNotificationsTest: >> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >> - If not all notifications are received/handled, the test will timeout at line >> 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and >> print a useful error message if the timeout is reached. >> >> PoolsIndependenceTest: >> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >> - Typos "event to be recieved ..." -> "received" (3x) >> >> PeakUsageTest: >> - Compilation is not disabled. The asserts may fail because a method is compiled >> in between. Even with compilation disabled, adapters and other non-nmethod code >> may be generated and stored in the non-nmethod code heap. >> >> ManagerNamesTest: >> - Typo: "calls in case on segmented code cache" -> "of segmented" >> >> GetUsageTest: >> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? >> >> General: >> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it >> would be easier to understand if you invoke WB.allocateCodeBlob(...) directly. >> >> Please run the tests on JPRT! >> >> Thanks, >> Tobias >> >> On 04.12.2014 20:13, Dmitrij Pochepko wrote: >>> Hi, >>> >>> Please review changes for >>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: >>> JMX- tests >>> and >>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in >>> testlibrary for JDK-8059613 >>> >>> It introduce a number of tests for segmented code cache, mostly testing >>> thresholds, usage, >>> memory notifications using respective MemoryPoolMXBean(s). >>> There is also a small modification for testlibrary(8066440) used in tests. >>> >>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>> >>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>> >>> Additional note: this patch assumes >>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. >>> >>> Thanks, >>> Dmitrij > From dmitrij.pochepko at oracle.com Mon Dec 15 12:53:50 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 15 Dec 2014 15:53:50 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <548ECBB8.7010008@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> <548B6EA0.1010802@oracle.com> <548ECBB8.7010008@oracle.com> Message-ID: <548ED9DE.4040701@oracle.com> Hi, see comments below > Hi Dmitrij, > > For PeakUsageTest I'm still worried that the asserts may fail if class loading > happens in between and triggers compilation of adapters. non-nmethods heap is excluded from testing(CodeCacheUtils.isCodeHeapPredictable is used to filter out heaps because of this exact reason). > > Why did you surround two of the asserts with a try? Like this the assert is > useless because we ignore failures. there is no catch block there - it's just finally block to be sure we've cleaned up memory allocated before, since assertion can get us out without deallocating memory otherwise. Thanks, Dmitrij > > Otherwise it looks good. > > Best, > Tobias > > On 12.12.2014 23:39, Dmitrij Pochepko wrote: >> Hi all, >> >> i've corrected diff according to comments. >> >> please see corrected version(also modified according to latest commits) >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 >> >> a jprt testing job has been created: >> http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp >> >> Thanks, >> Dmitrij >>> Hi Dmitrij, >>> >>> here are some comments about the tests (not a reviewer). >>> >>> UsageThresholdNotExceededTest: >>> - You can use CodeCacheUtils.MIN_ALLOCATION instead of >>> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. >>> - Please add a comment to 'CodeCacheUtils.WB.fullGC()' >>> >>> UsageThresholdIncreasedTest: >>> - Typo "hasn't been hit after allocationg smaller" -> "allocating" >>> - Maybe you should disable code cache sweeping here as well (as you did for the >>> UsageThresholdNotExceededTest) >>> >>> UsageThresholdExceededTest: >>> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold >>> if the code cache sweeper is enabled and removes nmethods in between. I think >>> you should disable code cache sweeping. >>> - Please print information about the counters if the assert is hit in line 66. >>> >>> ThresholdNotificationsTest: >>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>> - If not all notifications are received/handled, the test will timeout at line >>> 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and >>> print a useful error message if the timeout is reached. >>> >>> PoolsIndependenceTest: >>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>> - Typos "event to be recieved ..." -> "received" (3x) >>> >>> PeakUsageTest: >>> - Compilation is not disabled. The asserts may fail because a method is compiled >>> in between. Even with compilation disabled, adapters and other non-nmethod code >>> may be generated and stored in the non-nmethod code heap. >>> >>> ManagerNamesTest: >>> - Typo: "calls in case on segmented code cache" -> "of segmented" >>> >>> GetUsageTest: >>> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? >>> >>> General: >>> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it >>> would be easier to understand if you invoke WB.allocateCodeBlob(...) directly. >>> >>> Please run the tests on JPRT! >>> >>> Thanks, >>> Tobias >>> >>> On 04.12.2014 20:13, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> Please review changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: >>>> JMX- tests >>>> and >>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in >>>> testlibrary for JDK-8059613 >>>> >>>> It introduce a number of tests for segmented code cache, mostly testing >>>> thresholds, usage, >>>> memory notifications using respective MemoryPoolMXBean(s). >>>> There is also a small modification for testlibrary(8066440) used in tests. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>> >>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>> >>>> Additional note: this patch assumes >>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. >>>> >>>> Thanks, >>>> Dmitrij From tobias.hartmann at oracle.com Mon Dec 15 12:53:10 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 15 Dec 2014 13:53:10 +0100 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <548ED9DE.4040701@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> <548B6EA0.1010802@oracle.com> <548ECBB8.7010008@oracle.com> <548ED9DE.4040701@oracle.com> Message-ID: <548ED9B6.6080008@oracle.com> Hi, On 15.12.2014 13:53, Dmitrij Pochepko wrote: > Hi, > see comments below >> Hi Dmitrij, >> >> For PeakUsageTest I'm still worried that the asserts may fail if class loading >> happens in between and triggers compilation of adapters. > non-nmethods heap is excluded from testing(CodeCacheUtils.isCodeHeapPredictable > is used to filter out heaps because of this exact reason). Okay, good. >> >> Why did you surround two of the asserts with a try? Like this the assert is >> useless because we ignore failures. > there is no catch block there - it's just finally block to be sure we've cleaned > up memory allocated before, > since assertion can get us out without deallocating memory otherwise. Right, I missed that. Looks good (not a reviewer). Best, Tobias > > Thanks, > Dmitrij >> >> Otherwise it looks good. >> >> Best, >> Tobias >> >> On 12.12.2014 23:39, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> i've corrected diff according to comments. >>> >>> please see corrected version(also modified according to latest commits) >>> >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 >>> >>> a jprt testing job has been created: >>> http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp >>> >>> >>> Thanks, >>> Dmitrij >>>> Hi Dmitrij, >>>> >>>> here are some comments about the tests (not a reviewer). >>>> >>>> UsageThresholdNotExceededTest: >>>> - You can use CodeCacheUtils.MIN_ALLOCATION instead of >>>> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. >>>> - Please add a comment to 'CodeCacheUtils.WB.fullGC()' >>>> >>>> UsageThresholdIncreasedTest: >>>> - Typo "hasn't been hit after allocationg smaller" -> "allocating" >>>> - Maybe you should disable code cache sweeping here as well (as you did for the >>>> UsageThresholdNotExceededTest) >>>> >>>> UsageThresholdExceededTest: >>>> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold >>>> if the code cache sweeper is enabled and removes nmethods in between. I think >>>> you should disable code cache sweeping. >>>> - Please print information about the counters if the assert is hit in line 66. >>>> >>>> ThresholdNotificationsTest: >>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>> - If not all notifications are received/handled, the test will timeout at line >>>> 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and >>>> print a useful error message if the timeout is reached. >>>> >>>> PoolsIndependenceTest: >>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>> - Typos "event to be recieved ..." -> "received" (3x) >>>> >>>> PeakUsageTest: >>>> - Compilation is not disabled. The asserts may fail because a method is >>>> compiled >>>> in between. Even with compilation disabled, adapters and other non-nmethod code >>>> may be generated and stored in the non-nmethod code heap. >>>> >>>> ManagerNamesTest: >>>> - Typo: "calls in case on segmented code cache" -> "of segmented" >>>> >>>> GetUsageTest: >>>> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? >>>> >>>> General: >>>> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it >>>> would be easier to understand if you invoke WB.allocateCodeBlob(...) directly. >>>> >>>> Please run the tests on JPRT! >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 04.12.2014 20:13, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> Please review changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: >>>>> JMX- tests >>>>> and >>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in >>>>> testlibrary for JDK-8059613 >>>>> >>>>> It introduce a number of tests for segmented code cache, mostly testing >>>>> thresholds, usage, >>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>> There is also a small modification for testlibrary(8066440) used in tests. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>> >>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>> >>>>> Additional note: this patch assumes >>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. >>>>> >>>>> Thanks, >>>>> Dmitrij > From pavel.chistyakov at oracle.com Mon Dec 15 13:15:23 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Mon, 15 Dec 2014 16:15:23 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <548B4A9B.2050603@oracle.com> References: <5487285A.8000402@oracle.com> <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> <548ABFEE.40307@oracle.com> <548B4A9B.2050603@oracle.com> Message-ID: <548EDEEB.1090201@oracle.com> Hi, please take a look into slightly updated webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ -------------- Thanks, Pavel On 12.12.2014 23:05, Vladimir Kozlov wrote: > Looks fine. > > Thanks, > Vladimir > > On 12/12/14 6:07 AM, David Chase wrote: >> >> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >> wrote: >> >>> David, thank you for review. >>> Here is updated webrev: >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>> >> >> That is excellent -- now we just need a real reviewer. >> >> David >> From igor.ignatyev at oracle.com Mon Dec 15 13:34:26 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 15 Dec 2014 16:34:26 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <548EDEEB.1090201@oracle.com> References: <5487285A.8000402@oracle.com> <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> <548ABFEE.40307@oracle.com> <548B4A9B.2050603@oracle.com> <548EDEEB.1090201@oracle.com> Message-ID: <548EE362.1070406@oracle.com> Pavel, http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html > 45 CLASS_DATA = loadClassData(TestCaseImpl.class.getName()); > 95 String className = TestCaseImpl.class.getName(); these lines will load 'TestCaseImpl' class via default class loader, could you try to avoid it? Igor On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: > Hi, > > please take a look into slightly updated webrev: > http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ > > > -------------- > Thanks, > Pavel > > On 12.12.2014 23:05, Vladimir Kozlov wrote: >> Looks fine. >> >> Thanks, >> Vladimir >> >> On 12/12/14 6:07 AM, David Chase wrote: >>> >>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>> wrote: >>> >>>> David, thank you for review. >>>> Here is updated webrev: >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>> >>> >>> That is excellent -- now we just need a real reviewer. >>> >>> David >>> > From dmitrij.pochepko at oracle.com Mon Dec 15 14:06:16 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 15 Dec 2014 17:06:16 +0300 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... In-Reply-To: <548B5603.5030902@oracle.com> References: <548B5603.5030902@oracle.com> Message-ID: <548EEAD8.7000509@oracle.com> Hi, a bit of update for https://bugs.openjdk.java.net/browse/JDK-8067295 (port of JDK-8066440) http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.01/ Thanks, Dmitrij > Hi, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm > checks in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking > which vm is run > https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils > chagnes from JDK-8059613 into jdk workspace > https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom > classloaders(parent-last and filtering one) for JDK-8066625 in > testlibrary > > Description: A number of small testlibrary changes needed for further > test development, 2 of 3 is port from respective hotspot changes > 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is > FilterClassLoader - loads classes using target classloader in case > class name meets provided condition, and using parent otherwise. 2nd > is ParentLastURLClassLoader which loads classes using provided URL[] > with fallback to parent, > > Webrevs: > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ > > Thanks, > Dmitrij From aph at redhat.com Mon Dec 15 15:40:59 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Dec 2014 15:40:59 +0000 Subject: MatchNode::build_instr_pred Message-ID: <548F010B.5030202@redhat.com> I'm sorry this mail is rather long. Bottom line: there's a baffling bug in adlc, and I'm seeking help understanding how it's supposed to work. I've come across a very odd problem when building the AArch64 back end. I defined a certain pattern, and the compiler segfaulted when run. The pattern was this (Set dst (XorL src1 (OrL (URShiftL src2 shift1) (LShiftL src2 shift2)))) I think the bug which caused the segfault is in MatchNode::build_instr_pred(). This is a very simple routine which is passed a name; it walks a binary tree and returns the path to the Nth occurrence of that name. This is used for generating a matching predicate for an operand used twice in a pattern. I wouldn't expect anything to go wrong, but it generates the wrong code for the above pattern. The sub-pattern I was trying to match was this: (XorI (OrI (URShiftI src2 shift1) (LShiftI src2 shift2)) src1) For the two occurrences of "src2" in this pattern, build_instr_pred() returns "_kids[0]->_kids[0]->_kids[0]->_leaf" and "_kids[1]->_kids[0]->_leaf" but it should return "_kids[0]->_kids[0]->_kids[0]->_leaf" and "_kids[0]->_kids[1]->_kids[0]->_leaf" which is why it segfaults. Here is the source of build_instr_pred() : //------------------------------build_instr_pred------------------------------- // Build a path to 'name' in buf. Actually only build if cnt is zero, so we // can skip some leading instances of 'name'. int MatchNode::build_instr_pred( char *buf, const char *name, int cnt ) { if( _lChild ) { if( !cnt )strcpy( buf, "_kids[0]->" ); cnt = _lChild->build_instr_pred( buf+strlen(buf), name, cnt ); if( cnt < 0 ) return cnt; // Found it, all done } if( _rChild ) { if( !cnt ) strcpy( buf, "_kids[1]->" ); cnt = _rChild->build_instr_pred( buf+strlen(buf), name, cnt ); if( cnt < 0 ) return cnt; // Found it, all done } if( !_lChild && !_rChild ) { // Found a leaf // Wrong name? Give up... if( strcmp(name,_name) ) return cnt; if( !cnt ) strcpy(buf,"_leaf"); return cnt-1; } return cnt; } It seems to me that the use of "if( !cnt )" is simply wrong: for simple patterns it has no effect, and where it does have an effect it serves only to break things. The comment "Actually only build if cnt is zero, so we can skip some leading instances of 'name'" doesn't really help me to understand what it was supposed to do. I have tried the following patch, and it fixes my bug, and it doesn't break x86. However, I think this bug has been in C2 since the year dot, so I'm rather surprised no-one has ever been affected, and I am totally mystified: what is that "if( !cnt )" for? It doesn't seem to do anything useful, and I suspect it never has. Finally, how should I report this as a bug? It doesn't affect any existing OpenJDK targets, as far as I know. Thanks, Andrew. // ============================================================================ // Floating Point Arithmetic Instructions diff -r 50f6ffa33a7c src/share/vm/adlc/formssel.cpp --- a/src/share/vm/adlc/formssel.cpp Fri Dec 12 06:32:18 2014 -0500 +++ b/src/share/vm/adlc/formssel.cpp Mon Dec 15 10:30:49 2014 -0500 @@ -3407,12 +3407,12 @@ // can skip some leading instances of 'name'. int MatchNode::build_instr_pred( char *buf, const char *name, int cnt ) { if( _lChild ) { - if( !cnt ) strcpy( buf, "_kids[0]->" ); + strcpy( buf, "_kids[0]->" ); cnt = _lChild->build_instr_pred( buf+strlen(buf), name, cnt ); if( cnt < 0 ) return cnt; // Found it, all done } if( _rChild ) { - if( !cnt ) strcpy( buf, "_kids[1]->" ); + strcpy( buf, "_kids[1]->" ); cnt = _rChild->build_instr_pred( buf+strlen(buf), name, cnt ); if( cnt < 0 ) return cnt; // Found it, all done } From tatiana.pivovarova at oracle.com Mon Dec 15 15:46:16 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Mon, 15 Dec 2014 18:46:16 +0300 Subject: RFR(S): 8067211: rewrite Utils::fileAsString In-Reply-To: <548B4B42.5070109@oracle.com> References: <548AE189.9020800@oracle.com> <548AE39B.2080808@oracle.com> <548B4B42.5070109@oracle.com> Message-ID: <548F0248.8000103@oracle.com> Hi Vladimir, Thank you for your review! Tatiana On 12/12/2014 11:08 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 12/12/14 4:46 AM, Tatiana Pivovarova wrote: >> Added hotspot-dev at openjdk.java.net >> >> On 12/12/2014 03:37 PM, Tatiana Pivovarova wrote: >>> Hi all, >>> >>> please review this small patch >>> >>> bugid: https://bugs.openjdk.java.net/browse/JDK-8067211 >>> webrev: >>> http://cr.openjdk.java.net/~ppunegov/tpivovarova/8067211/webrev.00/ >>> >>> Problem: >>> Utils::fileAsString implementation has several issues: >>> - using '\n' instead of platform independent EOL >>> - catching wide spectre of exceptions and "ignoring" them >>> - partially duplicates code of Utils::fileAsList method which >>> duplicates File::readAllLines >>> >>> Solution: >>> - using library method for reading lines >>> - using system property for EndOfLine. >>> >>> Testing: jprt >>> >>> Thanks, >>> Tatiana >> From christian.thalinger at oracle.com Mon Dec 15 17:16:08 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 15 Dec 2014 09:16:08 -0800 Subject: How to build openJDK8 (build 32) In-Reply-To: References: Message-ID: Please refer to the README-builds.html file. > On Dec 9, 2014, at 11:09 PM, fuyou wrote: > > update : > > I want to try A hotspot patch for stack profiling (frame pointer) > ,but how build it by myself? > > I try to install from source code : > > step1: download source from http://download.java.net/openjdk/jdk8/ > step2 :git clone https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > step3 :unzip dk-8-src-b132-03_mar_2014.zip > and go to the openjdk > and patch -p1 openjdk8_b132-fp.diff > > step4 :bash configure; > unset CLASSPATH ; > unset JAVA_HOME; > make all > it is right ? > > 2014-12-10 13:20 GMT+08:00 fuyou >: > I want to try https://mail.google.com/mail/u/0/#label/java%2Fjdk%2Fcompiler-dev/14a178591a7c71f6 > > ,but how build it by myself? > > step1: download source from http://download.java.net/openjdk/jdk8/ > step2 :git clone https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > > step3 :unzip dk-8-src-b132-03_mar_2014.zip > and go to the openjdk > and patch -p1 openjdk8_b132-fp.diff > > it is right ? > -- > ============================================= > fuyou001 > Best Regards > > > > > -- > ============================================= > fuyou001 > > 2014-12-10 15:06 GMT+08:00 fuyou >: > update : > > I want to try A hotspot patch for stack profiling (frame pointer) > > ,but how build it by myself? > > step1: download source from http://download.java.net/openjdk/jdk8/ > step2 :git clone https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > > step3 :unzip dk-8-src-b132-03_mar_2014.zip > and go to the openjdk > and patch -p1 openjdk8_b132-fp.diff > > it is right ? > > 2014-12-10 13:20 GMT+08:00 fuyou >: > I want to try https://mail.google.com/mail/u/0/#label/java%2Fjdk%2Fcompiler-dev/14a178591a7c71f6 > > ,but how build it by myself? > > step1: download source from http://download.java.net/openjdk/jdk8/ > step2 :git clone https://github.com/brendangregg/Misc/blob/master/java/openjdk8_b132-fp.diff > > step3 :unzip dk-8-src-b132-03_mar_2014.zip > and go to the openjdk > and patch -p1 openjdk8_b132-fp.diff > > it is right ? > -- > ============================================= > fuyou001 > Best Regards > > > > > -- > ============================================= > fuyou001 > Best Regards > > > > > -- > ============================================= > fuyou001 > Best Regards > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Dec 15 22:25:41 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Dec 2014 14:25:41 -0800 Subject: RFR(S): 8027829: CompileCommand does not accept all JLS-conformant class/method names In-Reply-To: <548EC4A4.8060608@oracle.com> References: <546F6201.6070000@oracle.com> <546F5AA6.3020805@oracle.com> <547331A5.40609@oracle.com> <54733A50.5030705@oracle.com> <5474804A.4040208@oracle.com> <54876BAB.6070502@oracle.com> <548ABE8D.1090003@oracle.com> <548EC4A4.8060608@oracle.com> Message-ID: <548F5FE5.7090804@oracle.com> Looks good. Thanks, Vladimir On 12/15/14 3:23 AM, Nils Eliasson wrote: > I updated the webrev with suggestions and corrections from Albert, Dean, > Doug and Vladimir. > > 1) Removed 'this method' from the descriptions of the commands and > instead clarified that the pattern defined a set of methods in the text > 2) Removed some quotes from the examples. Quotes are a character allowed > in the names and a part of the method patterns > 3) Added a note about the .hotspot_compiler file > > webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.07 > bug: https://bugs.openjdk.java.net/browse/JDK-8027829 > > Thanks, > Nils > > On 2014-12-12 11:08, Albert Noll wrote: >> Some minor things: >> >> 518 // The characters allowed is based on the JVM specification. >> I am not sure if this is a correct sentence, but I am not a native >> speaker. >> "The JVM specification defines the allowed characters" sounds more >> correct to me. >> >> 519 // Some tokens disallowed in the JVMS have some meaning >> 520 // when parsing so we need to include them here. >> >> Same here. >> Maybe we could use: >> "Tokens that are disallowed by the JVM specification can have a >> meaning to the parser so we need to include them here..." >> >> // The parser do not enforce all rules of the JVMS - a successful parse >> "The parser *does* not .... >> >> Best, >> Albert >> >> >> On 12/09/2014 10:37 PM, Vladimir Kozlov wrote: >>> Missing "method" at the end: >>> >>> ! tty->print_cr(" exclude, - don't compile or inline >>> this "); >>> >>> Also add that these commands can be listed in .hotspot_compiler file >>> instead of command line. >>> >>> Otherwise looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/25/14 5:12 AM, Nils Eliasson wrote: >>>> Hi, >>>> >>>> I added an improved help text and included a format description that is >>>> printed on parse error. >>>> >>>> webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.04/ >>>> >>>> Thanks! >>>> Nils >>>> >>>> On 2014-11-24 15:01, Vladimir Ivanov wrote: >>>>> Looks good. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/24/14, 5:24 PM, Nils Eliasson wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> You are absolutely correct. Of course it is the JVMS that should be >>>>>> targeted. >>>>>> >>>>>> I have updated the change adding all characters that do not create >>>>>> problem with the >>>>>> command line parser or pattern matcher, and are allowed by the JVMS. >>>>>> >>>>>> Also fixed so that we can match the signature without requiring a >>>>>> whitespace before. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.02 >>>>>> >>>>>> Thanks, >>>>>> //Nils >>>>>> >>>>>> On 2014-11-21 16:30, Vladimir Ivanov wrote: >>>>>>> Nils, >>>>>>> >>>>>>> 2 typos: Charachter.isJavaIdentiferPart >>>>>>> >>>>>>> Are there any plans to extend this further past JLS? >>>>>>> JVMS allows arbitrary UTF8 string to be used as a class/method/field >>>>>>> name and some JVM languages use that. >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 11/21/14, 8:02 PM, Nils Eliasson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this patch. >>>>>>>> >>>>>>>> It includes two fixes: >>>>>>>> >>>>>>>> 1) Improve CompileCommand so that it now accepts all JLS conformant >>>>>>>> class and method names. (With one exception - \u0000 can not be >>>>>>>> used >>>>>>>> since the commandline parsing uses null terminated strings.) For >>>>>>>> parsing >>>>>>>> simplicity it is possible in some case to specify a pattern that is >>>>>>>> not >>>>>>>> JLS-conformant. That is however not a problem - the pattern will be >>>>>>>> saved as a symbol and will simply never match any allowed name. >>>>>>>> >>>>>>>> 2) Fixed some output to make it more understandable. The user is >>>>>>>> specifying the flag "CompileCommand" and any output should be >>>>>>>> annotated >>>>>>>> with the flag name, and not "CompilerOracle". Also added more >>>>>>>> describing >>>>>>>> error messages. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8027829 >>>>>>>> Webrev: http://cr.openjdk.java.net/~neliasso/8027829/webrev.01/ >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nils Eliasson >>>>>> >>>> >> > From vladimir.kozlov at oracle.com Mon Dec 15 23:07:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Dec 2014 15:07:27 -0800 Subject: MatchNode::build_instr_pred In-Reply-To: <548F010B.5030202@redhat.com> References: <548F010B.5030202@redhat.com> Message-ID: <548F69AF.6090003@oracle.com> In short: adlc and C2 matcher do not support such patterns - more then one references to the same leaf in match rule (DAG). Only pure trees are supported. If your change helped to your simple case, it does not mean it will not cause a problem later. Are you sure that your subtree is actually matched? Your change may avoid crash but the mach instruction is not matched anyway. See changes in matcher.cpp for 8031321 Igor added to workaround this problem: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9e9af3aa4278#l9.1 Igor, did you file an RFE for "support DAGs in ADL"? Andrew, in general we should fix problems, which you find in shared code, in main-stream jdk9 sources and then sync it into stage repo. Thanks, Vladimir On 12/15/14 7:40 AM, Andrew Haley wrote: > I'm sorry this mail is rather long. Bottom line: there's a baffling > bug in adlc, and I'm seeking help understanding how it's supposed to > work. > > I've come across a very odd problem when building the AArch64 back > end. I defined a certain pattern, and the compiler segfaulted when > run. > > The pattern was this > > (Set dst (XorL src1 (OrL (URShiftL src2 shift1) (LShiftL src2 shift2)))) > > I think the bug which caused the segfault is in > MatchNode::build_instr_pred(). This is a very simple routine which is > passed a name; it walks a binary tree and returns the path to the Nth > occurrence of that name. This is used for generating a matching > predicate for an operand used twice in a pattern. I wouldn't expect > anything to go wrong, but it generates the wrong code for the above > pattern. > > The sub-pattern I was trying to match was this: > > (XorI (OrI (URShiftI src2 shift1) (LShiftI src2 shift2)) src1) > > For the two occurrences of "src2" in this pattern, build_instr_pred() > returns > > "_kids[0]->_kids[0]->_kids[0]->_leaf" > > and > > "_kids[1]->_kids[0]->_leaf" > > but it should return > > "_kids[0]->_kids[0]->_kids[0]->_leaf" > > and > > "_kids[0]->_kids[1]->_kids[0]->_leaf" > > which is why it segfaults. > > Here is the source of build_instr_pred() : > > //------------------------------build_instr_pred------------------------------- > // Build a path to 'name' in buf. Actually only build if cnt is zero, so we > // can skip some leading instances of 'name'. > int MatchNode::build_instr_pred( char *buf, const char *name, int cnt ) { > if( _lChild ) { > if( !cnt )strcpy( buf, "_kids[0]->" ); > cnt = _lChild->build_instr_pred( buf+strlen(buf), name, cnt ); > if( cnt < 0 ) return cnt; // Found it, all done > } > if( _rChild ) { > if( !cnt ) strcpy( buf, "_kids[1]->" ); > cnt = _rChild->build_instr_pred( buf+strlen(buf), name, cnt ); > if( cnt < 0 ) return cnt; // Found it, all done > } > if( !_lChild && !_rChild ) { // Found a leaf > // Wrong name? Give up... > if( strcmp(name,_name) ) return cnt; > if( !cnt ) strcpy(buf,"_leaf"); > return cnt-1; > } > return cnt; > } > > It seems to me that the use of "if( !cnt )" is simply wrong: for > simple patterns it has no effect, and where it does have an effect it > serves only to break things. The comment "Actually only build if cnt > is zero, so we can skip some leading instances of 'name'" doesn't > really help me to understand what it was supposed to do. > > I have tried the following patch, and it fixes my bug, and it doesn't > break x86. However, I think this bug has been in C2 since the year > dot, so I'm rather surprised no-one has ever been affected, and I am > totally mystified: what is that "if( !cnt )" for? It doesn't seem to > do anything useful, and I suspect it never has. > > Finally, how should I report this as a bug? It doesn't affect any > existing OpenJDK targets, as far as I know. > > Thanks, > Andrew. > > > // ============================================================================ > // Floating Point Arithmetic Instructions > diff -r 50f6ffa33a7c src/share/vm/adlc/formssel.cpp > --- a/src/share/vm/adlc/formssel.cpp Fri Dec 12 06:32:18 2014 -0500 > +++ b/src/share/vm/adlc/formssel.cpp Mon Dec 15 10:30:49 2014 -0500 > @@ -3407,12 +3407,12 @@ > // can skip some leading instances of 'name'. > int MatchNode::build_instr_pred( char *buf, const char *name, int cnt ) { > if( _lChild ) { > - if( !cnt ) strcpy( buf, "_kids[0]->" ); > + strcpy( buf, "_kids[0]->" ); > cnt = _lChild->build_instr_pred( buf+strlen(buf), name, cnt ); > if( cnt < 0 ) return cnt; // Found it, all done > } > if( _rChild ) { > - if( !cnt ) strcpy( buf, "_kids[1]->" ); > + strcpy( buf, "_kids[1]->" ); > cnt = _rChild->build_instr_pred( buf+strlen(buf), name, cnt ); > if( cnt < 0 ) return cnt; // Found it, all done > } > From vladimir.kozlov at oracle.com Tue Dec 16 00:21:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 15 Dec 2014 16:21:24 -0800 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <548B6926.1090606@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> <547E352A.5040806@oracle.com> <548602CD.805@oracle.com> <54862C70.5020006@oracle.com> <54862ED1.5010305@oracle.com> <548637E5.5060807@oracle.com> <548B6926.1090606@oracle.com> Message-ID: <548F7B04.9050307@oracle.com> I am not familiar with Phaser. Do I understand correctly that until next line is executed in main thread: 82 phaser.register(); the method() will not wait - arriveAndAwaitAdvance() calls are nop because only one party is registered (in TestCaseImpl() constructor)? It allows to execute method() and compile it. And I assume "compileonly" prevents inlining of arriveAndAwaitAdvance() to avoid unneeded uncommon traps in compiled code. Looks good in this case. Yes, that is what I wanted. Thanks, Vladimir On 12/12/14 2:16 PM, Igor Ignatyev wrote: > Vladimir, > > I rewrote the test to use Phaser. this made the test more robust and > removed needs for '::getCompiler' method. > > http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.02/ > 211 lines changed: 203 ins; 8 del; 0 mod; > > (whitebox class changes) > http://cr.openjdk.java.net/~iignatyev/8028595/top/webrev.00/ > 1 line changed: 1 ins; 0 del; 0 mod; > > Thanks, > Igor > > On 12/09/2014 02:44 AM, Vladimir Kozlov wrote: >> On 12/8/14 3:05 PM, Igor Ignatyev wrote: >>> On 12/09/2014 01:55 AM, Vladimir Kozlov wrote: >>>> On 12/8/14 11:58 AM, Igor Ignatyev wrote: >>>>> Vladimir, >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/ >>>>> >>>>> On 12/03/2014 12:54 AM, Vladimir Kozlov wrote: >>>>>> On 12/2/14 1:32 AM, Igor Ignatyev wrote: >>>>>>> Vladimir, >>>>>>> >>>>>>> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in >>>>>>> 'non-makeNotEntrant' case, there's no way to determine if the method >>>>>>> was >>>>>>> deoptimized. >>>>>> >>>>>> I don't understand how you check that in the test. >>>>> getCompiler returns 0 if method isn't compiled or (in my case) was >>>>> deoptimized. TestCaseImpl::method uses 'getCompiler' method as a >>>>> multiplier for result value. if TestCaseImpl::method returns 0, >>>>> for-loop >>>>> (lines 75--80) quits. >>>> >>>> Okay. I missed that compile() calls method() and returns sum of its >>>> results. >>>> >>>>> >>>>>> >>>>>> If you only want to check if method was deoptimized you can check >>>>>> MethodData::decompile_count(). >>>>> >>>>> MethodData::decompile_count is incremented only if nmethod is compiled >>>>> by c2. so it can't be used. >>>>>> >>>>>> I don't like extending Unsafe API for just this test. >>>>> well, I can move it to whitebox, if you don't mind to have intrinsics >>>>> for it. >>>> >>>> I would rather see changes in nmethod and new WB accessors to it. >>>> >>>> And sorry, I don't like the test. The test does not have >>>> comments/description. It is difficult to judge, is it doing what it is >>>> suppose to do or not. >>> yeap, sorry. I'll add the comments. >>> >>>> >>>> nm->make_not_entrant() will call method()->clear_code(). So how you >>>> expect that checkCompiled() will not throw Error after deoptimization?: >>>> >>>> 69 WHITE_BOX.deoptimizeFrames(makeNotEntrant); >>>> 70 checkCompiled(); >>>> >>>> Your loop (lines 75--80) is in a race of compilations vs >>>> deoptimizations. The test on machines with different numbers of threads >>>> will behave differently. Where is guarantee that you will get your >>>> result == 0 case? >>>> Why do you even need these *concurrent* deoptimization, compilation >>>> loops? >>>> Can you do it synchronously? Execute method in separate thread and stop >>>> it when you get compilation of requested level or other condition >>>> (recursion level). Do deoptimization in main thread and see if methods >>>> are deoptimized. >>> >>> WB::deoptimizeFrames has to deoptimize methods which are currently on >>> stack, that's why I expect that checkCompiled on line 70 won't throw an >>> exception and that's why I do need these concurrent >>> deoptimization/compilation. >> >> So you are testing in first lines that if the compiled method does not >> have the frame on stack it will not be deoptimized - *comment* please. >> >> Again. I think the test will be simpler if you execute compiled method >> in a separate thread instead of main where you do all checks. >> >> Vladimir >> >>> >>>> >>>> Regards, >>>> Vladimir >>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Igor >>>>>>> >>>>>>> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >>>>>>>> Why you need new Unsafe.getCompiler()? >>>>>>>> >>>>>>>> thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>>>>>>>> 220 lines changed: 212 ins; 8 del; 0 mod; >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>>>>>>>> 4 lines changed: 4 ins; 0 del; 0 mod; >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> please review the patch which adds >>>>>>>>> - a new whitebox method 'deoptimizeFrames' which deoptimizes >>>>>>>>> methods >>>>>>>>> which are currently on stack >>>>>>>>> - Unsafe.getCompiler methodhotspot-compiler-dev at openjdk.java.net >>>>>>>>> which >>>>>>>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 >>>>>>>>> accordingly. >>>>>>>>> >>>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>>>>>>>> testing: jprt + new added test >>>>>>>>> >>>>> >>> From igor.ignatyev at oracle.com Tue Dec 16 00:28:50 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 16 Dec 2014 03:28:50 +0300 Subject: RFR(S) 8028595 : WhiteBox API for stress testing of TieredCompilation In-Reply-To: <548F7B04.9050307@oracle.com> References: <5477A263.6090102@oracle.com> <547D1BC8.7000301@oracle.com> <547D8723.6090102@oracle.com> <547E352A.5040806@oracle.com> <548602CD.805@oracle.com> <54862C70.5020006@oracle.com> <54862ED1.5010305@oracle.com> <548637E5.5060807@oracle.com> <548B6926.1090606@oracle.com> <548F7B04.9050307@oracle.com> Message-ID: <548F7CC2.3060600@oracle.com> On 12/16/2014 03:21 AM, Vladimir Kozlov wrote: > I am not familiar with Phaser. > Do I understand correctly that until next line is executed in main thread: > > 82 phaser.register(); > > the method() will not wait - arriveAndAwaitAdvance() calls are nop > because only one party is registered (in TestCaseImpl() constructor)? > It allows to execute method() and compile it. correct + ' phaser.awaitAdvance(phaser.arriveAndDeregister());' deregister one of party, so after that, calls of arriveAndAwaitAdvance() become "nop" again. > And I assume "compileonly" prevents inlining of arriveAndAwaitAdvance() > to avoid unneeded uncommon traps in compiled code. > > Looks good in this case. Yes, that is what I wanted. thank you for review. > > Thanks, > Vladimir > > > On 12/12/14 2:16 PM, Igor Ignatyev wrote: >> Vladimir, >> >> I rewrote the test to use Phaser. this made the test more robust and >> removed needs for '::getCompiler' method. >> >> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.02/ >> 211 lines changed: 203 ins; 8 del; 0 mod; >> >> (whitebox class changes) >> http://cr.openjdk.java.net/~iignatyev/8028595/top/webrev.00/ >> 1 line changed: 1 ins; 0 del; 0 mod; >> >> Thanks, >> Igor >> >> On 12/09/2014 02:44 AM, Vladimir Kozlov wrote: >>> On 12/8/14 3:05 PM, Igor Ignatyev wrote: >>>> On 12/09/2014 01:55 AM, Vladimir Kozlov wrote: >>>>> On 12/8/14 11:58 AM, Igor Ignatyev wrote: >>>>>> Vladimir, >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.01/ >>>>>> >>>>>> On 12/03/2014 12:54 AM, Vladimir Kozlov wrote: >>>>>>> On 12/2/14 1:32 AM, Igor Ignatyev wrote: >>>>>>>> Vladimir, >>>>>>>> >>>>>>>> I need Unsafe.getCompiler for DeoptimizeFramesTest, because in >>>>>>>> 'non-makeNotEntrant' case, there's no way to determine if the >>>>>>>> method >>>>>>>> was >>>>>>>> deoptimized. >>>>>>> >>>>>>> I don't understand how you check that in the test. >>>>>> getCompiler returns 0 if method isn't compiled or (in my case) was >>>>>> deoptimized. TestCaseImpl::method uses 'getCompiler' method as a >>>>>> multiplier for result value. if TestCaseImpl::method returns 0, >>>>>> for-loop >>>>>> (lines 75--80) quits. >>>>> >>>>> Okay. I missed that compile() calls method() and returns sum of its >>>>> results. >>>>> >>>>>> >>>>>>> >>>>>>> If you only want to check if method was deoptimized you can check >>>>>>> MethodData::decompile_count(). >>>>>> >>>>>> MethodData::decompile_count is incremented only if nmethod is >>>>>> compiled >>>>>> by c2. so it can't be used. >>>>>>> >>>>>>> I don't like extending Unsafe API for just this test. >>>>>> well, I can move it to whitebox, if you don't mind to have intrinsics >>>>>> for it. >>>>> >>>>> I would rather see changes in nmethod and new WB accessors to it. >>>>> >>>>> And sorry, I don't like the test. The test does not have >>>>> comments/description. It is difficult to judge, is it doing what it is >>>>> suppose to do or not. >>>> yeap, sorry. I'll add the comments. >>>> >>>>> >>>>> nm->make_not_entrant() will call method()->clear_code(). So how you >>>>> expect that checkCompiled() will not throw Error after >>>>> deoptimization?: >>>>> >>>>> 69 WHITE_BOX.deoptimizeFrames(makeNotEntrant); >>>>> 70 checkCompiled(); >>>>> >>>>> Your loop (lines 75--80) is in a race of compilations vs >>>>> deoptimizations. The test on machines with different numbers of >>>>> threads >>>>> will behave differently. Where is guarantee that you will get your >>>>> result == 0 case? >>>>> Why do you even need these *concurrent* deoptimization, compilation >>>>> loops? >>>>> Can you do it synchronously? Execute method in separate thread and >>>>> stop >>>>> it when you get compilation of requested level or other condition >>>>> (recursion level). Do deoptimization in main thread and see if methods >>>>> are deoptimized. >>>> >>>> WB::deoptimizeFrames has to deoptimize methods which are currently on >>>> stack, that's why I expect that checkCompiled on line 70 won't throw an >>>> exception and that's why I do need these concurrent >>>> deoptimization/compilation. >>> >>> So you are testing in first lines that if the compiled method does not >>> have the frame on stack it will not be deoptimized - *comment* please. >>> >>> Again. I think the test will be simpler if you execute compiled method >>> in a separate thread instead of main where you do all checks. >>> >>> Vladimir >>> >>>> >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Igor >>>>>>>> >>>>>>>> On 12/02/2014 04:54 AM, Vladimir Kozlov wrote: >>>>>>>>> Why you need new Unsafe.getCompiler()? >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 11/27/14 2:14 PM, Igor Ignatyev wrote: >>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/hotspot/webrev.00/ >>>>>>>>>> 220 lines changed: 212 ins; 8 del; 0 mod; >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/8028595/jdk/webrev.00/ >>>>>>>>>> 4 lines changed: 4 ins; 0 del; 0 mod; >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> please review the patch which adds >>>>>>>>>> - a new whitebox method 'deoptimizeFrames' which deoptimizes >>>>>>>>>> methods >>>>>>>>>> which are currently on stack >>>>>>>>>> - Unsafe.getCompiler >>>>>>>>>> methodhotspot-compiler-dev at openjdk.java.net >>>>>>>>>> which >>>>>>>>>> returns 0, 1, 2 if it is interpreted, compiled by c1, c2 >>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8028595 >>>>>>>>>> testing: jprt + new added test >>>>>>>>>> >>>>>> >>>> From igor.veresov at oracle.com Tue Dec 16 07:12:40 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 15 Dec 2014 23:12:40 -0800 Subject: MatchNode::build_instr_pred In-Reply-To: <548F69AF.6090003@oracle.com> References: <548F010B.5030202@redhat.com> <548F69AF.6090003@oracle.com> Message-ID: <68D8D341-F0A7-4E5E-BBD0-45C7E4CE89AC@oracle.com> This case is different, since only inputs form a DAG. I think the 0th occurrence is assumed to be the first argument of the ?Set?, for cases when the destination is one of the sources. Andrew?s case can be fixed by checking if the first occurrence is the destination argument or not. igor > On Dec 15, 2014, at 3:07 PM, Vladimir Kozlov wrote: > > In short: adlc and C2 matcher do not support such patterns - more then one references to the same leaf in match rule (DAG). Only pure trees are supported. If your change helped to your simple case, it does not mean it will not cause a problem later. Are you sure that your subtree is actually matched? Your change may avoid crash but the mach instruction is not matched anyway. > > See changes in matcher.cpp for 8031321 Igor added to workaround this problem: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9e9af3aa4278#l9.1 > > Igor, did you file an RFE for "support DAGs in ADL"? > > Andrew, in general we should fix problems, which you find in shared code, in main-stream jdk9 sources and then sync it into stage repo. > > Thanks, > Vladimir > > On 12/15/14 7:40 AM, Andrew Haley wrote: >> I'm sorry this mail is rather long. Bottom line: there's a baffling >> bug in adlc, and I'm seeking help understanding how it's supposed to >> work. >> >> I've come across a very odd problem when building the AArch64 back >> end. I defined a certain pattern, and the compiler segfaulted when >> run. >> >> The pattern was this >> >> (Set dst (XorL src1 (OrL (URShiftL src2 shift1) (LShiftL src2 shift2)))) >> >> I think the bug which caused the segfault is in >> MatchNode::build_instr_pred(). This is a very simple routine which is >> passed a name; it walks a binary tree and returns the path to the Nth >> occurrence of that name. This is used for generating a matching >> predicate for an operand used twice in a pattern. I wouldn't expect >> anything to go wrong, but it generates the wrong code for the above >> pattern. >> >> The sub-pattern I was trying to match was this: >> >> (XorI (OrI (URShiftI src2 shift1) (LShiftI src2 shift2)) src1) >> >> For the two occurrences of "src2" in this pattern, build_instr_pred() >> returns >> >> "_kids[0]->_kids[0]->_kids[0]->_leaf" >> >> and >> >> "_kids[1]->_kids[0]->_leaf" >> >> but it should return >> >> "_kids[0]->_kids[0]->_kids[0]->_leaf" >> >> and >> >> "_kids[0]->_kids[1]->_kids[0]->_leaf" >> >> which is why it segfaults. >> >> Here is the source of build_instr_pred() : >> >> //------------------------------build_instr_pred------------------------------- >> // Build a path to 'name' in buf. Actually only build if cnt is zero, so we >> // can skip some leading instances of 'name'. >> int MatchNode::build_instr_pred( char *buf, const char *name, int cnt ) { >> if( _lChild ) { >> if( !cnt )strcpy( buf, "_kids[0]->" ); >> cnt = _lChild->build_instr_pred( buf+strlen(buf), name, cnt ); >> if( cnt < 0 ) return cnt; // Found it, all done >> } >> if( _rChild ) { >> if( !cnt ) strcpy( buf, "_kids[1]->" ); >> cnt = _rChild->build_instr_pred( buf+strlen(buf), name, cnt ); >> if( cnt < 0 ) return cnt; // Found it, all done >> } >> if( !_lChild && !_rChild ) { // Found a leaf >> // Wrong name? Give up... >> if( strcmp(name,_name) ) return cnt; >> if( !cnt ) strcpy(buf,"_leaf"); >> return cnt-1; >> } >> return cnt; >> } >> >> It seems to me that the use of "if( !cnt )" is simply wrong: for >> simple patterns it has no effect, and where it does have an effect it >> serves only to break things. The comment "Actually only build if cnt >> is zero, so we can skip some leading instances of 'name'" doesn't >> really help me to understand what it was supposed to do. >> >> I have tried the following patch, and it fixes my bug, and it doesn't >> break x86. However, I think this bug has been in C2 since the year >> dot, so I'm rather surprised no-one has ever been affected, and I am >> totally mystified: what is that "if( !cnt )" for? It doesn't seem to >> do anything useful, and I suspect it never has. >> >> Finally, how should I report this as a bug? It doesn't affect any >> existing OpenJDK targets, as far as I know. >> >> Thanks, >> Andrew. >> >> >> // ============================================================================ >> // Floating Point Arithmetic Instructions >> diff -r 50f6ffa33a7c src/share/vm/adlc/formssel.cpp >> --- a/src/share/vm/adlc/formssel.cpp Fri Dec 12 06:32:18 2014 -0500 >> +++ b/src/share/vm/adlc/formssel.cpp Mon Dec 15 10:30:49 2014 -0500 >> @@ -3407,12 +3407,12 @@ >> // can skip some leading instances of 'name'. >> int MatchNode::build_instr_pred( char *buf, const char *name, int cnt ) { >> if( _lChild ) { >> - if( !cnt ) strcpy( buf, "_kids[0]->" ); >> + strcpy( buf, "_kids[0]->" ); >> cnt = _lChild->build_instr_pred( buf+strlen(buf), name, cnt ); >> if( cnt < 0 ) return cnt; // Found it, all done >> } >> if( _rChild ) { >> - if( !cnt ) strcpy( buf, "_kids[1]->" ); >> + strcpy( buf, "_kids[1]->" ); >> cnt = _rChild->build_instr_pred( buf+strlen(buf), name, cnt ); >> if( cnt < 0 ) return cnt; // Found it, all done >> } >> From roland.westrelin at oracle.com Tue Dec 16 16:50:09 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 16 Dec 2014 17:50:09 +0100 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <02C11976-5D45-40F7-A852-5BBA274CA963@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> <543833F6.5050002@oracle.com> <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> <025487DA-04CA-49BB-885C-39446D0C9BF7@oracle.com> <544F67A4.3060801@oracle.com> <02C11976-5D45-40F7-A852-5BBA274CA963@oracle.com> Message-ID: <39B2F20F-B0AE-49CA-9A7D-E67276E248BD@oracle.com> I?ve added some test cases for this change: http://cr.openjdk.java.net/~roland/6700100/webrev.02/ I still need a second review. Roland. From roland.westrelin at oracle.com Tue Dec 16 19:19:54 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 16 Dec 2014 20:19:54 +0100 Subject: RFR(XS): 8067647: [TESTBUG] compiler/rangechecks/TestRangeCheckSmearing.java uses wrong path to Whitebox API Message-ID: <7F257944-B3D1-4EF4-9C90-174B27D8C96C@oracle.com> A test case that was missed when the white box test library was moved. http://cr.openjdk.java.net/~roland/8067647/webrev.00/ Roland. From vladimir.kozlov at oracle.com Tue Dec 16 19:32:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 16 Dec 2014 11:32:26 -0800 Subject: RFR(XS): 8067647: [TESTBUG] compiler/rangechecks/TestRangeCheckSmearing.java uses wrong path to Whitebox API In-Reply-To: <7F257944-B3D1-4EF4-9C90-174B27D8C96C@oracle.com> References: <7F257944-B3D1-4EF4-9C90-174B27D8C96C@oracle.com> Message-ID: <549088CA.9080604@oracle.com> Good. Thanks, Vladimir On 12/16/14 11:19 AM, Roland Westrelin wrote: > A test case that was missed when the white box test library was moved. > > http://cr.openjdk.java.net/~roland/8067647/webrev.00/ > > Roland. > From tobias.hartmann at oracle.com Tue Dec 16 19:35:12 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 16 Dec 2014 20:35:12 +0100 Subject: RFR(XS): 8067647: [TESTBUG] compiler/rangechecks/TestRangeCheckSmearing.java uses wrong path to Whitebox API In-Reply-To: <7F257944-B3D1-4EF4-9C90-174B27D8C96C@oracle.com> References: <7F257944-B3D1-4EF4-9C90-174B27D8C96C@oracle.com> Message-ID: <54908970.7070809@oracle.com> Hi Roland, looks good, thanks for fixing this. Best, Tobias On 16.12.2014 20:19, Roland Westrelin wrote: > A test case that was missed when the white box test library was moved. > > http://cr.openjdk.java.net/~roland/8067647/webrev.00/ > > Roland. > From roland.westrelin at oracle.com Tue Dec 16 19:41:16 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 16 Dec 2014 20:41:16 +0100 Subject: RFR(XS): 8067647: [TESTBUG] compiler/rangechecks/TestRangeCheckSmearing.java uses wrong path to Whitebox API In-Reply-To: <54908970.7070809@oracle.com> References: <7F257944-B3D1-4EF4-9C90-174B27D8C96C@oracle.com> <54908970.7070809@oracle.com> Message-ID: <90BD73B2-4AF4-4730-B444-387411C112E7@oracle.com> Thanks Vladimir & Tobias for reviewing this. Roland. From vladimir.x.ivanov at oracle.com Thu Dec 18 00:01:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Dec 2014 03:01:12 +0300 Subject: C2: cyclic IR for JVMS Message-ID: <54921948.5010702@oracle.com> Hi! I stumbled upon the following cyclic Ideal graph shape: 21580 CallStaticJava === ... 21585 ... // some local in JVMS 21585 Proj === 21580 #5 Is it a legal shape? It looks broken to me. Or do we fix such quirks later in the pipeline? It's a result of a transformation (Phi removal [1]) in RegionNode::Ideal from the following shape: 21580 CallStaticJava === ... 21457 ... // some local in JVMS 21585 Proj === 21580 #5 21457 Phi === 21454 21585 I'm asking because it breaks compilation during incremental inlining. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff29b5858de6/src/share/vm/opto/cfgnode.cpp#l587 From rednaxelafx at gmail.com Thu Dec 18 00:54:30 2014 From: rednaxelafx at gmail.com (Krystal Mok) Date: Wed, 17 Dec 2014 16:54:30 -0800 Subject: C2: cyclic IR for JVMS In-Reply-To: <54921948.5010702@oracle.com> References: <54921948.5010702@oracle.com> Message-ID: Hi Vladimir, That looks like broken IR to me, too. I this case, why was there a Phi node in the first place that would only have a single input? Is it missing some inputs? - Kris On Wed, Dec 17, 2014 at 4:01 PM, Vladimir Ivanov < vladimir.x.ivanov at oracle.com> wrote: > Hi! > > I stumbled upon the following cyclic Ideal graph shape: > 21580 CallStaticJava === ... 21585 ... // some local in JVMS > 21585 Proj === 21580 #5 > > Is it a legal shape? It looks broken to me. > Or do we fix such quirks later in the pipeline? > > It's a result of a transformation (Phi removal [1]) in RegionNode::Ideal > from the following shape: > 21580 CallStaticJava === ... 21457 ... // some local in JVMS > 21585 Proj === 21580 #5 > 21457 Phi === 21454 21585 > > I'm asking because it breaks compilation during incremental inlining. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ > ff29b5858de6/src/share/vm/opto/cfgnode.cpp#l587 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Dec 18 01:07:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 17 Dec 2014 17:07:06 -0800 Subject: C2: cyclic IR for JVMS In-Reply-To: <54921948.5010702@oracle.com> References: <54921948.5010702@oracle.com> Message-ID: <549228BA.1050002@oracle.com> Nope, it is illegal. Except for dead code. There is code in RegionNode::Ideal which tries to detect dead loops and don't do transformation. if (this->is_Loop() && (del_it == LoopNode::EntryControl || del_it == 0 && is_unreachable_region(phase)) || !this->is_Loop() && has_phis && is_unreachable_region(phase)) { Vladimir K On 12/17/14 4:01 PM, Vladimir Ivanov wrote: > Hi! > > I stumbled upon the following cyclic Ideal graph shape: > 21580 CallStaticJava === ... 21585 ... // some local in JVMS > 21585 Proj === 21580 #5 > > Is it a legal shape? It looks broken to me. > Or do we fix such quirks later in the pipeline? > > It's a result of a transformation (Phi removal [1]) in RegionNode::Ideal > from the following shape: > 21580 CallStaticJava === ... 21457 ... // some local in JVMS > 21585 Proj === 21580 #5 > 21457 Phi === 21454 21585 > > I'm asking because it breaks compilation during incremental inlining. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff29b5858de6/src/share/vm/opto/cfgnode.cpp#l587 > From vladimir.x.ivanov at oracle.com Thu Dec 18 16:58:53 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Dec 2014 19:58:53 +0300 Subject: C2: cyclic IR for JVMS In-Reply-To: <549228BA.1050002@oracle.com> References: <54921948.5010702@oracle.com> <549228BA.1050002@oracle.com> Message-ID: <549307CD.1070802@oracle.com> Kris, Vladimir, As my investigations show, it's a leftover from a loop. CallStaticJava represents loop counter increment. The graph is as follows: Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) The Region is dead, but RegionNode::is_unreachable_region doesn't detect that. Node::simple_data_loop_check(Phi, Proj) doesn't find the cycle, because most of Proj nodes have Flag_is_dead_loop_safe set [1]. And I don't understand why it is so. Is the check in Node::is_dead_loop_safe() too weak or Flag_is_dead_loop_safe too "optimistic"? :-) Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff29b5858de6/src/share/vm/opto/multnode.hpp#l72 On 12/18/14, 4:07 AM, Vladimir Kozlov wrote: > Nope, it is illegal. Except for dead code. > > There is code in RegionNode::Ideal which tries to detect dead loops and > don't do transformation. > > if (this->is_Loop() && (del_it == LoopNode::EntryControl || > del_it == 0 && > is_unreachable_region(phase)) || > !this->is_Loop() && has_phis && is_unreachable_region(phase)) { > > Vladimir K > > On 12/17/14 4:01 PM, Vladimir Ivanov wrote: >> Hi! >> >> I stumbled upon the following cyclic Ideal graph shape: >> 21580 CallStaticJava === ... 21585 ... // some local in JVMS >> 21585 Proj === 21580 #5 >> >> Is it a legal shape? It looks broken to me. >> Or do we fix such quirks later in the pipeline? >> >> It's a result of a transformation (Phi removal [1]) in RegionNode::Ideal >> from the following shape: >> 21580 CallStaticJava === ... 21457 ... // some local in JVMS >> 21585 Proj === 21580 #5 >> 21457 Phi === 21454 21585 >> >> I'm asking because it breaks compilation during incremental inlining. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/ff29b5858de6/src/share/vm/opto/cfgnode.cpp#l587 >> >> From roland.westrelin at oracle.com Thu Dec 18 17:25:55 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 18 Dec 2014 18:25:55 +0100 Subject: C2: cyclic IR for JVMS In-Reply-To: <549307CD.1070802@oracle.com> References: <54921948.5010702@oracle.com> <549228BA.1050002@oracle.com> <549307CD.1070802@oracle.com> Message-ID: <8DDC9641-7D4F-4B2E-A713-25D373DA1D45@oracle.com> > As my investigations show, it's a leftover from a loop. > CallStaticJava represents loop counter increment. > > The graph is as follows: > Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) > > The Region is dead, but RegionNode::is_unreachable_region doesn't detect that. Node::simple_data_loop_check(Phi, Proj) doesn't find the cycle, because most of Proj nodes have Flag_is_dead_loop_safe set [1]. > And I don't understand why it is so. Is the check in Node::is_dead_loop_safe() too weak or Flag_is_dead_loop_safe too "optimistic"? :-) Isn?t the problem that you try to late inline a call that is dead and that the checks in LateInlineCallGenerator::do_late_inline(): if (call == NULL || call->outcnt() == 0 || call->in(0) == NULL || call->in(0)->is_top()) { return; } const TypeTuple *r = call->tf()->domain(); for (int i1 = 0; i1 < method()->arg_size(); i1++) { if (call->in(TypeFunc::Parms + i1)->is_top() && r->field_at(TypeFunc::Parms + i1) != Type::HALF) { assert(Compile::current()->inlining_incrementally(), "shouldn't happen during parsing"); return; } } if (call->in(TypeFunc::Memory)->is_top()) { assert(Compile::current()->inlining_incrementally(), "shouldn't happen during parsing"); return; } don?t detect it? FWIW, I know there are rare cases where those tests are not sufficient. Ideally, you would need Compile::inline_incrementally() to do: PhaseIdealLoop ideal_loop( igvn, false, true ); after every inline but that?s very expensive. Roland. From vladimir.x.ivanov at oracle.com Thu Dec 18 19:11:15 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 18 Dec 2014 22:11:15 +0300 Subject: C2: cyclic IR for JVMS In-Reply-To: <8DDC9641-7D4F-4B2E-A713-25D373DA1D45@oracle.com> References: <54921948.5010702@oracle.com> <549228BA.1050002@oracle.com> <549307CD.1070802@oracle.com> <8DDC9641-7D4F-4B2E-A713-25D373DA1D45@oracle.com> Message-ID: <549326D3.3020007@oracle.com> Roland, The code is reachable by the time inlining occurs, but the call node is broken. The transformation which breaks the code is performed in RegionNode::Ideal() Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) ==> (Proj #5 (CallStaticJava ... Proj(backref)...)) The RegionNode and Phi are removed, but CallStaticJava is broken. It seems that if RegionNode::is_unreachable_region() detected that RegionNode is dead, it would break the vicious circle (PhiNode is replaced by top()). Not sure why the call node is live, though the loop was dead. Best regards, Vladimir Ivanov On 12/18/14, 8:25 PM, Roland Westrelin wrote: >> As my investigations show, it's a leftover from a loop. >> CallStaticJava represents loop counter increment. >> >> The graph is as follows: >> Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) >> >> The Region is dead, but RegionNode::is_unreachable_region doesn't detect that. Node::simple_data_loop_check(Phi, Proj) doesn't find the cycle, because most of Proj nodes have Flag_is_dead_loop_safe set [1]. >> And I don't understand why it is so. Is the check in Node::is_dead_loop_safe() too weak or Flag_is_dead_loop_safe too "optimistic"? :-) > > Isn?t the problem that you try to late inline a call that is dead and that the checks in LateInlineCallGenerator::do_late_inline(): > > if (call == NULL || call->outcnt() == 0 || > call->in(0) == NULL || call->in(0)->is_top()) { > return; > } > > const TypeTuple *r = call->tf()->domain(); > for (int i1 = 0; i1 < method()->arg_size(); i1++) { > if (call->in(TypeFunc::Parms + i1)->is_top() && r->field_at(TypeFunc::Parms + i1) != Type::HALF) { > assert(Compile::current()->inlining_incrementally(), "shouldn't happen during parsing"); > return; > } > } > > if (call->in(TypeFunc::Memory)->is_top()) { > assert(Compile::current()->inlining_incrementally(), "shouldn't happen during parsing"); > return; > } > > don?t detect it? > FWIW, I know there are rare cases where those tests are not sufficient. Ideally, you would need Compile::inline_incrementally() to do: > PhaseIdealLoop ideal_loop( igvn, false, true ); > after every inline but that?s very expensive. > > Roland. > From christian.thalinger at oracle.com Thu Dec 18 22:16:57 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 18 Dec 2014 14:16:57 -0800 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <548ED9B6.6080008@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> <548B6EA0.1010802@oracle.com> <548ECBB8.7010008@oracle.com> <548ED9DE.4040701@oracle.com> <548ED9B6.6080008@oracle.com> Message-ID: <9FDF1C34-968B-4BF2-B57E-4021207C1707@oracle.com> Looks good. > On Dec 15, 2014, at 4:53 AM, Tobias Hartmann wrote: > > Hi, > > On 15.12.2014 13:53, Dmitrij Pochepko wrote: >> Hi, >> see comments below >>> Hi Dmitrij, >>> >>> For PeakUsageTest I'm still worried that the asserts may fail if class loading >>> happens in between and triggers compilation of adapters. >> non-nmethods heap is excluded from testing(CodeCacheUtils.isCodeHeapPredictable >> is used to filter out heaps because of this exact reason). > > Okay, good. > >>> >>> Why did you surround two of the asserts with a try? Like this the assert is >>> useless because we ignore failures. >> there is no catch block there - it's just finally block to be sure we've cleaned >> up memory allocated before, >> since assertion can get us out without deallocating memory otherwise. > > Right, I missed that. > > Looks good (not a reviewer). > > Best, > Tobias > >> >> Thanks, >> Dmitrij >>> >>> Otherwise it looks good. >>> >>> Best, >>> Tobias >>> >>> On 12.12.2014 23:39, Dmitrij Pochepko wrote: >>>> Hi all, >>>> >>>> i've corrected diff according to comments. >>>> >>>> please see corrected version(also modified according to latest commits) >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 >>>> >>>> a jprt testing job has been created: >>>> http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp >>>> >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi Dmitrij, >>>>> >>>>> here are some comments about the tests (not a reviewer). >>>>> >>>>> UsageThresholdNotExceededTest: >>>>> - You can use CodeCacheUtils.MIN_ALLOCATION instead of >>>>> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. >>>>> - Please add a comment to 'CodeCacheUtils.WB.fullGC()' >>>>> >>>>> UsageThresholdIncreasedTest: >>>>> - Typo "hasn't been hit after allocationg smaller" -> "allocating" >>>>> - Maybe you should disable code cache sweeping here as well (as you did for the >>>>> UsageThresholdNotExceededTest) >>>>> >>>>> UsageThresholdExceededTest: >>>>> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold >>>>> if the code cache sweeper is enabled and removes nmethods in between. I think >>>>> you should disable code cache sweeping. >>>>> - Please print information about the counters if the assert is hit in line 66. >>>>> >>>>> ThresholdNotificationsTest: >>>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>>> - If not all notifications are received/handled, the test will timeout at line >>>>> 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and >>>>> print a useful error message if the timeout is reached. >>>>> >>>>> PoolsIndependenceTest: >>>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>>> - Typos "event to be recieved ..." -> "received" (3x) >>>>> >>>>> PeakUsageTest: >>>>> - Compilation is not disabled. The asserts may fail because a method is >>>>> compiled >>>>> in between. Even with compilation disabled, adapters and other non-nmethod code >>>>> may be generated and stored in the non-nmethod code heap. >>>>> >>>>> ManagerNamesTest: >>>>> - Typo: "calls in case on segmented code cache" -> "of segmented" >>>>> >>>>> GetUsageTest: >>>>> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? >>>>> >>>>> General: >>>>> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it >>>>> would be easier to understand if you invoke WB.allocateCodeBlob(...) directly. >>>>> >>>>> Please run the tests on JPRT! >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 04.12.2014 20:13, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> Please review changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test task: >>>>>> JMX- tests >>>>>> and >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in >>>>>> testlibrary for JDK-8059613 >>>>>> >>>>>> It introduce a number of tests for segmented code cache, mostly testing >>>>>> thresholds, usage, >>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>> There is also a small modification for testlibrary(8066440) used in tests. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>> >>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>> >>>>>> Additional note: this patch assumes >>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is fixed. >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >> From christian.thalinger at oracle.com Thu Dec 18 22:17:48 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 18 Dec 2014 14:17:48 -0800 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <548EE362.1070406@oracle.com> References: <5487285A.8000402@oracle.com> <4DD0DF6B-2649-45C5-8B7D-7D5D41F6825F@oracle.com> <548ABFEE.40307@oracle.com> <548B4A9B.2050603@oracle.com> <548EDEEB.1090201@oracle.com> <548EE362.1070406@oracle.com> Message-ID: <0442CAD7-51B0-4E13-8F58-90937324CF9F@oracle.com> > On Dec 15, 2014, at 5:34 AM, Igor Ignatyev wrote: > > Pavel, > > http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html > >> 45 CLASS_DATA = loadClassData(TestCaseImpl.class.getName()); >> 95 String className = TestCaseImpl.class.getName(); > > these lines will load 'TestCaseImpl' class via default class loader, could you try to avoid it? Any update on that? > > Igor > > On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >> Hi, >> >> please take a look into slightly updated webrev: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >> >> >> -------------- >> Thanks, >> Pavel >> >> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>> Looks fine. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/12/14 6:07 AM, David Chase wrote: >>>> >>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>> wrote: >>>> >>>>> David, thank you for review. >>>>> Here is updated webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>> >>>> >>>> That is excellent -- now we just need a real reviewer. >>>> >>>> David >>>> >> From christian.thalinger at oracle.com Thu Dec 18 22:18:35 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 18 Dec 2014 14:18:35 -0800 Subject: RFR (M): 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests In-Reply-To: <548AACC4.60609@oracle.com> References: <54786A47.2030505@oracle.com> <547C2654.8030808@oracle.com> <548212BE.7010500@oracle.com> <54855381.8030002@oracle.com> <54888A10.90800@oracle.com> <5489475D.9020907@oracle.com> <54899F16.5000406@oracle.com> <548AACC4.60609@oracle.com> Message-ID: Looks good. > On Dec 12, 2014, at 12:52 AM, Tobias Hartmann wrote: > > Thanks, Pavel. > > Best, > Tobias > > On 11.12.2014 14:41, Pavel Punegov wrote: >> Igor and Tobias, >> >> thank you for your reviews. >> I submitted an issue for the nmethod locking: >> https://bugs.openjdk.java.net/browse/JDK-8067229 >> >> On 11.12.2014 10:27, Tobias Hartmann wrote: >>> Hi, >>> >>> I agree with Igor that concurrent removal of nmethods by the sweeper may be a >>> problem. I think in 'WB_GetNMethod' we should at least acquire the nmethod lock >>> (using 'nmethodLocker') to prevent concurrent removal. As far as I understand, >>> the JNI functions copy the nmethod data. It should be fine for the sweeper to >>> remove the nmethod afterwards. As a result, the data may be outdated and we >>> should not expect Whitebox.getNMethod() to always return a NMethod object, even >>> if the corresponding method was compiled right before. >>> >>> Maybe you can file a separate bug for that issue. >>> >>> Otherwise your change looks good (not a reviewer). >>> >>> Thanks, >>> Tobias >>> >>> On 10.12.2014 18:59, Pavel Punegov wrote: >>>> Hi Tobias and Igor, >>>> >>>> could you please review this: >>>> http://cr.openjdk.java.net/~ppunegov/8059575/webrev.05/ >>>> >>>> I replaced the check for OSR-methods to skip transitions after deoptimization as >>>> they may make intermittent failures. >>>> See 67-70 lines at LevelTransitionTest.java >>>> >>>> I will file a separate RFE to improve this test to be able to check transitions >>>> after deopt too. >>>> >>>> Testing: jprt, locally >>>> >>>> On 08.12.2014 10:30, Tobias Hartmann wrote: >>>>> Hi Pavel, >>>>> >>>>> looks good (not a reviewer). >>>>> >>>>> Best, >>>>> Tobias >>>>> >>>>> On 05.12.2014 21:17, Pavel Punegov wrote: >>>>>> Hi Tobias, >>>>>> >>>>>> see new webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.04/ >>>>>> >>>>>> I added TransitionsTestExecutor.java class that checks if TieredCompilation is >>>>>> available in the VM it was started with. Then it starts test for >>>>>> CompilatonPolicyChoice 2 and 3. >>>>>> >>>>>> On 01.12.2014 11:27, Tobias Hartmann wrote: >>>>>>> Hi Pavel, >>>>>>> >>>>>>> the tests fail with a client VM: >>>>>>> >>>>>>>> Error occurred during initialization of VM >>>>>>>> Incompatible compilation policy selected >>>>>>> Please execute them on JPRT to make sure they work on all platforms. >>>>>>> >>>>>>> Best, >>>>>>> Tobias >>>>>>> >>>>>>> On 28.11.2014 13:27, Pavel Punegov wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> please review new tests developed as a part of the test task: >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8059575 >>>>>>>> webrev: http://cr.openjdk.java.net/~ppunegov/8059575/webrev.00/ >>>>>>>> >>>>>>>> Description: >>>>>>>> There are two tests to verify level transitions in Tiered Compilation: >>>>>>>> 1. LevelTransitionTest verifies that in case of no load on compiler queues >>>>>>>> test >>>>>>>> methods go through common transition patterns: >>>>>>>> 0 -> 3 (2) -> 4 for most of methods, 0 ->3(2) -> 1 and 0 -> 1 for different >>>>>>>> trivial methods, and 0 -> 4 after deoptimization. >>>>>>>> Test provokes compilations of the method and checks that all transitions are >>>>>>>> correct for CompilationPolicyChoice=2 and 3. >>>>>>>> >>>>>>>> 2. ConstantGettersTransitions is a test adapted from the test Tobias used >>>>>>>> for >>>>>>>> 8056071 (see [*] for details). It checks that all constant getters are >>>>>>>> always >>>>>>>> compiled with C1. >>>>>>>> >>>>>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8028590 >>>>>>>> >>>>>>>> Testing: done locally >>>>>>>> >> From christian.thalinger at oracle.com Thu Dec 18 22:19:30 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 18 Dec 2014 14:19:30 -0800 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <54883F17.4060904@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> Message-ID: Looks good. > On Dec 10, 2014, at 4:39 AM, Tobias Hartmann wrote: > > Hi Filipp, > > On 10.12.2014 13:21, Filipp Zhinkin wrote: >> Tobias, >> >> as I wrote you in a private message, until a fix for 8064940 doesn't affect >> the way options are processed there is no need to update proposed tests. >> >> I've filed 8067135 for new tests that will verify actual alignment of code heaps. > > Okay, sounds good. > > Thanks, > Tobias > >> >> Regards, >> Filipp. >> >> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>> Hi Tobias, >>>>> >>>>> thank you for suggestion. >>>>> >>>>> Yes, I think we should take code heap size alignment into account. >>>>> >>>>> What alignment policy you're going to implement for 8064940? >>>> My current fix just large-page-aligns the code heap sizes. >>>> >>>>> Maybe instead of checking that values are in >>>>> (value - page_size, value + page_size) interval we should just check >>>>> that all values were aligned up to page_size? >>>> Yes, that's a better solution. However, I don't know how to figure out the >>>> available page sizes from Java code. >>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>> about to add such method to WB API, but it need to check how well >>> it is going to work with large pages. >>> >>> Thanks, >>> Filipp. >>>> >>>> Best, >>>> Tobias >>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>> Hi Filipp, >>>>>> >>>>>> the actual size of a code heap is affected by alignment and therefore may be >>>>>> different to the size set via the command line. For example, on Sparc we >>>>>> have to >>>>>> make sure that the code heaps are large page (4MB) aligned to reduce the >>>>>> number >>>>>> of ITLB misses (will be introduced with [1]). >>>>>> >>>>>> Maybe we should check if the actual size of the code heap is within >>>>>> boundaries, >>>>>> i.e., within the specified size +- (large) page size. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>> >>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>>>>> >>>>>>> There are three new tests: >>>>>>> compiler/codecache/cli/ >>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>> TestSegmentedCodeCacheOption >>>>>>> >>>>>>> All tests consist of several test cases aimed to verify different aspects >>>>>>> of options' processing. >>>>>>> >>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>>>>> but add additional value - these tests actually check final values >>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>> >>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>> Testing: manual & automated >>>>>>> >>>>>>> This change depends on: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI >>>>>>> tests >>>>>>> error reporting >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>> testlibrary >>>>>>> for JDK-8059613 >>>>>>> >>>>>>> Thanks >>>>>>> Filipp. >>> >> From pavel.chistyakov at oracle.com Fri Dec 19 05:51:52 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Thu, 18 Dec 2014 21:51:52 -0800 (PST) Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class Message-ID: Hi David, In case of ByteCodeLoader we'd prefer to load class w/ given name and exact given bytecode. Even if parent loader can load class w/ such name, in general this class can have different bytecode. To prevent this situation we break delegation for our class name. Also, if we want to use parent loader we can get its instance and load class using it directly. ----------- Thanks, Pavel ----- Original Message ----- From: david.holmes at oracle.com To: vladimir.kozlov at oracle.com, hotspot-dev at openjdk.java.net Cc: pavel.chistyakov at oracle.com Sent: Friday, December 12, 2014 2:13:03 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class On 12/12/2014 8:04 AM, Vladimir Kozlov wrote: > Pavel, > > I am resending it to whole hotspot so you can get more help/explanations. > > Thanks, > Vladimir > > On 12/10/14 4:03 AM, Pavel Chistyakov wrote: >> Hi David, >> >> Thanks for review. >> >> The intent was: >> >> * be able to get */new/* instance of Class w/ given name and given >> bytecode for every /*new*/ instance of >> ByteCodeLoader even if this class was already loaded by parent >> loader. For this reason, I overrided loadClass to >> break delegation to parent loader for given className; I question why the parent should be able to load the class that is being "redefined"? If it can't, then breaking delegation is not necessary. If it can and you break delegation then you may be able to load the other variants of the class in new classloader instances, but depending on what you then do with the class you may get loader constraint violations. David H. >> * make single class definition for ByteCodeLoader instance. Here >> holder field appears and DCL for it's thread safe >> initialization. >> >> >> ------------- >> Pavel >> >> On 09.12.2014 23:49, David Chase wrote: >>> I agree with your changes to loadClass, but I am not sure that this >>> will allow you to redefine an existing class. My understanding of >>> how this would work is that it will allow you re-obtain the class >>> that was already loaded (but not to fail at this). Actually >>> redefining a class requires use of JVMTI (or so I think). >>> >>> Was that your intent? >>> >>> David >>> >>> >>> On 2014-12-09, at 11:50 AM, Pavel >>> Chistyakov wrote: >>> >>>> Hi all, >>>> >>>> please review changes >>>> for:https://bugs.openjdk.java.net/browse/JDK-8066497 >>>> webrev:http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ >>>> >>>> >>>> >>>> Problem: >>>> ByteCodeLoader allows one to load class with given name from >>>> existing bytecode. But if this class is already loaded by e.g. >>>> system classloader it cannot be redefined using another bytecode >>>> array because of delegation of loadClass call to parent classloader. >>>> >>>> Solution: >>>> override loadClass to break delegation for given className. >>>> >>>> Testing: manual >>>> >>>> ------------------- >>>> Thanks, >>>> Pavel >> From pavel.chistyakov at oracle.com Fri Dec 19 05:52:28 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Thu, 18 Dec 2014 21:52:28 -0800 (PST) Subject: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout Message-ID: <872d488f-555b-43c6-a87d-0d2f862970a4@default> Hi, Vladimir It's a little confusing corner case: to call sleep w/ 0 (zero) => expecting not to have any pause. If we call sleep w/ any other value then we expect some pause. So, in this case we need to prevent any pause. For this reason I added a conditional sleep call. --------- Thanks, Pavel ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Friday, December 12, 2014 12:57:29 AM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout Why it is a problem? /** * Class which runs another Runnable in infinite loop with certain pauses * between cycles. */ It does not say that it will not pause for few instructions to execute Thread.sleep(0). Thanks, Vladimir On 12/9/14 8:50 AM, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066896 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066896/webrev.00/ > > > Problem: > InfiniteLoop allows zero value as timeout and waste time for Thread.sleep(0) call that is not needed in this case. > > Solution: > Add a condition for skipping 0 (zero) timeout when calling Thread.sleep > > Testing: manual > > ------------------- > Thanks, > Pavel From filipp.zhinkin at oracle.com Fri Dec 19 10:33:08 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 19 Dec 2014 14:33:08 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> Message-ID: <5493FEE4.9070503@oracle.com> Christian, thank you for review! I've updated tests to reflect WhiteBox movement to top-level repo, added previously missed @bug tag and fixed few small issues: incremental diff: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ updated webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ Thanks, Filipp. On 12/19/2014 02:19 AM, Christian Thalinger wrote: > Looks good. > >> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann wrote: >> >> Hi Filipp, >> >> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>> Tobias, >>> >>> as I wrote you in a private message, until a fix for 8064940 doesn't affect >>> the way options are processed there is no need to update proposed tests. >>> >>> I've filed 8067135 for new tests that will verify actual alignment of code heaps. >> Okay, sounds good. >> >> Thanks, >> Tobias >> >>> Regards, >>> Filipp. >>> >>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>> Hi Tobias, >>>>>> >>>>>> thank you for suggestion. >>>>>> >>>>>> Yes, I think we should take code heap size alignment into account. >>>>>> >>>>>> What alignment policy you're going to implement for 8064940? >>>>> My current fix just large-page-aligns the code heap sizes. >>>>> >>>>>> Maybe instead of checking that values are in >>>>>> (value - page_size, value + page_size) interval we should just check >>>>>> that all values were aligned up to page_size? >>>>> Yes, that's a better solution. However, I don't know how to figure out the >>>>> available page sizes from Java code. >>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>> about to add such method to WB API, but it need to check how well >>>> it is going to work with large pages. >>>> >>>> Thanks, >>>> Filipp. >>>>> Best, >>>>> Tobias >>>>> >>>>>> Thanks, >>>>>> Filipp. >>>>>> >>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>> Hi Filipp, >>>>>>> >>>>>>> the actual size of a code heap is affected by alignment and therefore may be >>>>>>> different to the size set via the command line. For example, on Sparc we >>>>>>> have to >>>>>>> make sure that the code heaps are large page (4MB) aligned to reduce the >>>>>>> number >>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>> >>>>>>> Maybe we should check if the actual size of the code heap is within >>>>>>> boundaries, >>>>>>> i.e., within the specified size +- (large) page size. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>> >>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>>>>>> >>>>>>>> There are three new tests: >>>>>>>> compiler/codecache/cli/ >>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>> TestSegmentedCodeCacheOption >>>>>>>> >>>>>>>> All tests consist of several test cases aimed to verify different aspects >>>>>>>> of options' processing. >>>>>>>> >>>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>>>>>> but add additional value - these tests actually check final values >>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>> >>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>> Testing: manual & automated >>>>>>>> >>>>>>>> This change depends on: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI >>>>>>>> tests >>>>>>>> error reporting >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>>> testlibrary >>>>>>>> for JDK-8059613 >>>>>>>> >>>>>>>> Thanks >>>>>>>> Filipp. From pavel.chistyakov at oracle.com Fri Dec 19 10:53:24 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Fri, 19 Dec 2014 02:53:24 -0800 (PST) Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests Message-ID: Hi Christian, Yes, here is updated version: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 Could you please take a look into it? -------- Thanks, Pavel ----- Original Message ----- From: christian.thalinger at oracle.com To: igor.ignatyev at oracle.com Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests > On Dec 15, 2014, at 5:34 AM, Igor Ignatyev wrote: > > Pavel, > > http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html > >> 45 CLASS_DATA = loadClassData(TestCaseImpl.class.getName()); >> 95 String className = TestCaseImpl.class.getName(); > > these lines will load 'TestCaseImpl' class via default class loader, could you try to avoid it? Any update on that? > > Igor > > On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >> Hi, >> >> please take a look into slightly updated webrev: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >> >> >> -------------- >> Thanks, >> Pavel >> >> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>> Looks fine. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/12/14 6:07 AM, David Chase wrote: >>>> >>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>> wrote: >>>> >>>>> David, thank you for review. >>>>> Here is updated webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>> >>>> >>>> That is excellent -- now we just need a real reviewer. >>>> >>>> David >>>> >> From tatiana.pivovarova at oracle.com Fri Dec 19 12:44:34 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 19 Dec 2014 15:44:34 +0300 Subject: RFR(XS): 8062012: test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular image build Message-ID: <54941DB2.9070201@oracle.com> Hi all, please review this small patch bugid: https://bugs.openjdk.java.net/browse/JDK-8062012 webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.00/ Problem: TestSA.sh adds sa-jdi.jar to classpath, there are no such jar in modular image Solution: All classes from this jar are available in appmodules.jimage. so we just need to remove mention of the jar And this test will be still ignored because of another bug [*] Testing: jprt [*] https://bugs.openjdk.java.net/browse/JDK-8029528 Thanks, Tatiana From filipp.zhinkin at oracle.com Fri Dec 19 12:45:06 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Fri, 19 Dec 2014 16:45:06 +0400 Subject: RFR(XS): 8062012: test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular image build In-Reply-To: <54941DB2.9070201@oracle.com> References: <54941DB2.9070201@oracle.com> Message-ID: <54941DD2.3080704@oracle.com> Tatiana, The change itself looks good, but you have to use IDs instead of full names in "reviewed-by". Thanks, Filipp. On 12/19/2014 04:44 PM, Tatiana Pivovarova wrote: > Hi all, > > please review this small patch > > bugid: https://bugs.openjdk.java.net/browse/JDK-8062012 > webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.00/ > > Problem: > TestSA.sh adds sa-jdi.jar to classpath, there are no such jar in modular image > > Solution: > All classes from this jar are available in appmodules.jimage. so we just need > to remove mention of the jar > And this test will be still ignored because of another bug [*] > > Testing: jprt > > [*] https://bugs.openjdk.java.net/browse/JDK-8029528 > > Thanks, > Tatiana From tatiana.pivovarova at oracle.com Fri Dec 19 13:11:18 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 19 Dec 2014 16:11:18 +0300 Subject: RFR(XS): 8062012: test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular image build In-Reply-To: <54941DD2.3080704@oracle.com> References: <54941DB2.9070201@oracle.com> <54941DD2.3080704@oracle.com> Message-ID: <549423F6.80100@oracle.com> Hi Filipp, Thanks for the review! I will be more attentive with ID) webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.01/ Tatiana On 12/19/2014 03:45 PM, Filipp Zhinkin wrote: > Tatiana, > > The change itself looks good, but you have to use IDs instead of full > names in "reviewed-by". > > Thanks, > Filipp. > > On 12/19/2014 04:44 PM, Tatiana Pivovarova wrote: >> Hi all, >> >> please review this small patch >> >> bugid: https://bugs.openjdk.java.net/browse/JDK-8062012 >> webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.00/ >> >> Problem: >> TestSA.sh adds sa-jdi.jar to classpath, there are no such jar in >> modular image >> >> Solution: >> All classes from this jar are available in appmodules.jimage. so we >> just need to remove mention of the jar >> And this test will be still ignored because of another bug [*] >> >> Testing: jprt >> >> [*] https://bugs.openjdk.java.net/browse/JDK-8029528 >> >> Thanks, >> Tatiana > From roland.westrelin at oracle.com Fri Dec 19 13:50:12 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 19 Dec 2014 14:50:12 +0100 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined Message-ID: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> http://cr.openjdk.java.net/~roland/8055530/webrev.00/ From a core file: method being compiled is sun.nio.cs.ISO_8859_1::newDecoder public java.nio.charset.CharsetDecoder newDecoder(); Code: 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder 3: dup 4: aload_0 5: aconst_null 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V 9: areturn _exits.control() is a Region node. _gvn.type(ret_phi) is top ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result above the center line, which filter turns into top. I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. Roland. From tatiana.pivovarova at oracle.com Fri Dec 19 13:58:34 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 19 Dec 2014 16:58:34 +0300 Subject: RFR(XS): 8062012: test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular image build In-Reply-To: <549423F6.80100@oracle.com> References: <54941DB2.9070201@oracle.com> <54941DD2.3080704@oracle.com> <549423F6.80100@oracle.com> Message-ID: <54942F0A.4060400@oracle.com> And some another changes in the commit message: removed summary. webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.02/ Tatiana On 12/19/2014 04:11 PM, Tatiana Pivovarova wrote: > > Hi Filipp, > > Thanks for the review! I will be more attentive with ID) > webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.01/ > > Tatiana > > On 12/19/2014 03:45 PM, Filipp Zhinkin wrote: >> Tatiana, >> >> The change itself looks good, but you have to use IDs instead of full >> names in "reviewed-by". >> >> Thanks, >> Filipp. >> >> On 12/19/2014 04:44 PM, Tatiana Pivovarova wrote: >>> Hi all, >>> >>> please review this small patch >>> >>> bugid: https://bugs.openjdk.java.net/browse/JDK-8062012 >>> webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.00/ >>> >>> Problem: >>> TestSA.sh adds sa-jdi.jar to classpath, there are no such jar in >>> modular image >>> >>> Solution: >>> All classes from this jar are available in appmodules.jimage. so we >>> just need to remove mention of the jar >>> And this test will be still ignored because of another bug [*] >>> >>> Testing: jprt >>> >>> [*] https://bugs.openjdk.java.net/browse/JDK-8029528 >>> >>> Thanks, >>> Tatiana >> > From vladimir.x.ivanov at oracle.com Fri Dec 19 15:46:17 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 19 Dec 2014 18:46:17 +0300 Subject: C2: cyclic IR for JVMS In-Reply-To: <549326D3.3020007@oracle.com> References: <54921948.5010702@oracle.com> <549228BA.1050002@oracle.com> <549307CD.1070802@oracle.com> <8DDC9641-7D4F-4B2E-A713-25D373DA1D45@oracle.com> <549326D3.3020007@oracle.com> Message-ID: <54944849.2070805@oracle.com> So, if return value projection is not considered dead loop safe [1], the problem goes away. I'm curious whether it was an overlook in 6625997 [1] [2]. Best regards, Vladimir Ivanov [1] diff --git a/src/share/vm/opto/multnode.hpp b/src/share/vm/opto/multnode.hpp --- a/src/share/vm/opto/multnode.hpp +++ b/src/share/vm/opto/multnode.hpp @@ -68,7 +68,7 @@ { init_class_id(Class_Proj); // Optimistic setting. Need additional checks in Node::is_dead_loop_safe(). - if (con != TypeFunc::Memory || src->is_Start()) + if ((con != TypeFunc::Memory && con != TypeFunc::Parms) || src->is_Start()) init_flags(Flag_is_dead_loop_safe); debug_only(check_con()); } [2] https://jbs.oracle.com/bugs/browse/JDK-6625997 [3] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/diff/72f4a668df19/src/share/vm/opto/multnode.hpp On 12/18/14 10:11 PM, Vladimir Ivanov wrote: > Roland, > > The code is reachable by the time inlining occurs, but the call node is > broken. > > The transformation which breaks the code is performed in > RegionNode::Ideal() > Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) > ==> > (Proj #5 (CallStaticJava ... Proj(backref)...)) > > The RegionNode and Phi are removed, but CallStaticJava is broken. > > It seems that if RegionNode::is_unreachable_region() detected that > RegionNode is dead, it would break the vicious circle (PhiNode is > replaced by top()). > > Not sure why the call node is live, though the loop was dead. > > Best regards, > Vladimir Ivanov > > On 12/18/14, 8:25 PM, Roland Westrelin wrote: >>> As my investigations show, it's a leftover from a loop. >>> CallStaticJava represents loop counter increment. >>> >>> The graph is as follows: >>> Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) >>> >>> The Region is dead, but RegionNode::is_unreachable_region doesn't >>> detect that. Node::simple_data_loop_check(Phi, Proj) doesn't find the >>> cycle, because most of Proj nodes have Flag_is_dead_loop_safe set [1]. >>> And I don't understand why it is so. Is the check in >>> Node::is_dead_loop_safe() too weak or Flag_is_dead_loop_safe too >>> "optimistic"? :-) >> >> Isn?t the problem that you try to late inline a call that is dead and >> that the checks in LateInlineCallGenerator::do_late_inline(): >> >> if (call == NULL || call->outcnt() == 0 || >> call->in(0) == NULL || call->in(0)->is_top()) { >> return; >> } >> >> const TypeTuple *r = call->tf()->domain(); >> for (int i1 = 0; i1 < method()->arg_size(); i1++) { >> if (call->in(TypeFunc::Parms + i1)->is_top() && >> r->field_at(TypeFunc::Parms + i1) != Type::HALF) { >> assert(Compile::current()->inlining_incrementally(), "shouldn't >> happen during parsing"); >> return; >> } >> } >> >> if (call->in(TypeFunc::Memory)->is_top()) { >> assert(Compile::current()->inlining_incrementally(), "shouldn't >> happen during parsing"); >> return; >> } >> >> don?t detect it? >> FWIW, I know there are rare cases where those tests are not >> sufficient. Ideally, you would need Compile::inline_incrementally() >> to do: >> PhaseIdealLoop ideal_loop( igvn, false, true ); >> after every inline but that?s very expensive. >> >> Roland. >> From vladimir.kozlov at oracle.com Fri Dec 19 17:52:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Dec 2014 09:52:35 -0800 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined In-Reply-To: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> References: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> Message-ID: <549465E3.9070405@oracle.com> Why not bailout compilation when you detect such case? You changed only the assert. Thanks, Vladimir On 12/19/14 5:50 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8055530/webrev.00/ > > From a core file: > > method being compiled is sun.nio.cs.ISO_8859_1::newDecoder > > public java.nio.charset.CharsetDecoder newDecoder(); > Code: > 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder > 3: dup > 4: aload_0 > 5: aconst_null > 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V > 9: areturn > > _exits.control() is a Region node. > _gvn.type(ret_phi) is top > > ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result ab! ove the ce nter line, which filter turns into top. > > I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. > > Roland. > From vladimir.kozlov at oracle.com Fri Dec 19 17:53:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Dec 2014 09:53:45 -0800 Subject: RFR(XS): 8062012: test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular image build In-Reply-To: <54942F0A.4060400@oracle.com> References: <54941DB2.9070201@oracle.com> <54941DD2.3080704@oracle.com> <549423F6.80100@oracle.com> <54942F0A.4060400@oracle.com> Message-ID: <54946629.7010401@oracle.com> Looks good. Thanks, Vladimir On 12/19/14 5:58 AM, Tatiana Pivovarova wrote: > And some another changes in the commit message: removed summary. > webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.02/ > > Tatiana > > On 12/19/2014 04:11 PM, Tatiana Pivovarova wrote: >> >> Hi Filipp, >> >> Thanks for the review! I will be more attentive with ID) >> webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.01/ >> >> Tatiana >> >> On 12/19/2014 03:45 PM, Filipp Zhinkin wrote: >>> Tatiana, >>> >>> The change itself looks good, but you have to use IDs instead of full >>> names in "reviewed-by". >>> >>> Thanks, >>> Filipp. >>> >>> On 12/19/2014 04:44 PM, Tatiana Pivovarova wrote: >>>> Hi all, >>>> >>>> please review this small patch >>>> >>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8062012 >>>> webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.00/ >>>> >>>> Problem: >>>> TestSA.sh adds sa-jdi.jar to classpath, there are no such jar in >>>> modular image >>>> >>>> Solution: >>>> All classes from this jar are available in appmodules.jimage. so we >>>> just need to remove mention of the jar >>>> And this test will be still ignored because of another bug [*] >>>> >>>> Testing: jprt >>>> >>>> [*] https://bugs.openjdk.java.net/browse/JDK-8029528 >>>> >>>> Thanks, >>>> Tatiana >>> >> > From tatiana.pivovarova at oracle.com Fri Dec 19 17:55:21 2014 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Fri, 19 Dec 2014 20:55:21 +0300 Subject: RFR(XS): 8062012: test/compiler/ciReplay/TestSA.sh should be updated to work w/ modular image build In-Reply-To: <54946629.7010401@oracle.com> References: <54941DB2.9070201@oracle.com> <54941DD2.3080704@oracle.com> <549423F6.80100@oracle.com> <54942F0A.4060400@oracle.com> <54946629.7010401@oracle.com> Message-ID: <54946689.8050603@oracle.com> Hi Vladimir, Thanks for your review! Tatiana On 12/19/2014 08:53 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 12/19/14 5:58 AM, Tatiana Pivovarova wrote: >> And some another changes in the commit message: removed summary. >> webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.02/ >> >> Tatiana >> >> On 12/19/2014 04:11 PM, Tatiana Pivovarova wrote: >>> >>> Hi Filipp, >>> >>> Thanks for the review! I will be more attentive with ID) >>> webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.01/ >>> >>> Tatiana >>> >>> On 12/19/2014 03:45 PM, Filipp Zhinkin wrote: >>>> Tatiana, >>>> >>>> The change itself looks good, but you have to use IDs instead of full >>>> names in "reviewed-by". >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/19/2014 04:44 PM, Tatiana Pivovarova wrote: >>>>> Hi all, >>>>> >>>>> please review this small patch >>>>> >>>>> bugid: https://bugs.openjdk.java.net/browse/JDK-8062012 >>>>> webrev: http://cr.openjdk.java.net/~tpivovarova/8062012/webrev.00/ >>>>> >>>>> Problem: >>>>> TestSA.sh adds sa-jdi.jar to classpath, there are no such jar in >>>>> modular image >>>>> >>>>> Solution: >>>>> All classes from this jar are available in appmodules.jimage. so we >>>>> just need to remove mention of the jar >>>>> And this test will be still ignored because of another bug [*] >>>>> >>>>> Testing: jprt >>>>> >>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8029528 >>>>> >>>>> Thanks, >>>>> Tatiana >>>> >>> >> From roland.westrelin at oracle.com Fri Dec 19 17:58:53 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 19 Dec 2014 18:58:53 +0100 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined In-Reply-To: <549465E3.9070405@oracle.com> References: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> <549465E3.9070405@oracle.com> Message-ID: <41CA7748-5730-4D7C-BB10-5330600DEC64@oracle.com> Thanks for looking at this, Vladimir. > Why not bailout compilation when you detect such case? You changed only the assert. I thought about it. But it seems to me that similar inconsistencies might occur elsewhere during compilation and that we wouldn't necessarily detect them. So why a special case here? Roland. > > Thanks, > Vladimir > > On 12/19/14 5:50 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8055530/webrev.00/ >> >> From a core file: >> >> method being compiled is sun.nio.cs.ISO_8859_1::newDecoder >> >> public java.nio.charset.CharsetDecoder newDecoder(); >> Code: >> 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder >> 3: dup >> 4: aload_0 >> 5: aconst_null >> 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V >> 9: areturn >> >> _exits.control() is a Region node. >> _gvn.type(ret_phi) is top >> >> ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result ab! > ove the ce > nter line, which filter turns into top. >> >> I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. >> >> Roland. >> From vladimir.kozlov at oracle.com Fri Dec 19 18:07:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Dec 2014 10:07:42 -0800 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined In-Reply-To: <41CA7748-5730-4D7C-BB10-5330600DEC64@oracle.com> References: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> <549465E3.9070405@oracle.com> <41CA7748-5730-4D7C-BB10-5330600DEC64@oracle.com> Message-ID: <5494696E.3070200@oracle.com> I don't understand how you solved the problem in product build by relaxing the assert. Thanks, Vladimir On 12/19/14 9:58 AM, Roland Westrelin wrote: > Thanks for looking at this, Vladimir. > >> Why not bailout compilation when you detect such case? You changed only the assert. > > I thought about it. But it seems to me that similar inconsistencies might occur elsewhere during compilation and that we wouldn't necessarily detect them. So why a special case here? > > Roland. > >> >> Thanks, >> Vladimir >> >> On 12/19/14 5:50 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/8055530/webrev.00/ >>> >>> From a core file: >>> >>> method being compiled is sun.nio.cs.ISO_8859_1::newDecoder >>> >>> public java.nio.charset.CharsetDecoder newDecoder(); >>> Code: >>> 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder >>> 3: dup >>> 4: aload_0 >>> 5: aconst_null >>> 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V >>> 9: areturn >>> >>> _exits.control() is a Region node. >>> _gvn.type(ret_phi) is top >>> >>> ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result ! ab! >> ove the ce >> nter line, which filter turns into top. >>> >>> I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. >>> >>> Roland. >>> > From roland.westrelin at oracle.com Fri Dec 19 18:47:37 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 19 Dec 2014 19:47:37 +0100 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined In-Reply-To: <5494696E.3070200@oracle.com> References: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> <549465E3.9070405@oracle.com> <41CA7748-5730-4D7C-BB10-5330600DEC64@oracle.com> <5494696E.3070200@oracle.com> Message-ID: <87E2D6EA-D0D6-49C2-844F-E37FB2D2370D@oracle.com> > I don't understand how you solved the problem in product build by relaxing the assert. Ok. I thought more about it and that makes sense. I?ll send an updated webrev with a bailout. Roland. > > Thanks, > Vladimir > > On 12/19/14 9:58 AM, Roland Westrelin wrote: >> Thanks for looking at this, Vladimir. >> >>> Why not bailout compilation when you detect such case? You changed only the assert. >> >> I thought about it. But it seems to me that similar inconsistencies might occur elsewhere during compilation and that we wouldn't necessarily detect them. So why a special case here? >> >> Roland. >> >>> >>> Thanks, >>> Vladimir >>> >>> On 12/19/14 5:50 AM, Roland Westrelin wrote: >>>> http://cr.openjdk.java.net/~roland/8055530/webrev.00/ >>>> >>>> From a core file: >>>> >>>> method being compiled is sun.nio.cs.ISO_8859_1::newDecoder >>>> >>>> public java.nio.charset.CharsetDecoder newDecoder(); >>>> Code: >>>> 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder >>>> 3: dup >>>> 4: aload_0 >>>> 5: aconst_null >>>> 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V >>>> 9: areturn >>>> >>>> _exits.control() is a Region node. >>>> _gvn.type(ret_phi) is top >>>> >>>> ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result ab! >>> ove the ce >>> nter line, which filter turns into top. >>>> >>>> I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. >>>> >>>> Roland. >>>> >> From dmitrij.pochepko at oracle.com Fri Dec 19 19:03:19 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 19 Dec 2014 22:03:19 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature Message-ID: <54947677.7050104@oracle.com> Hi all, Please review changes for https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature Description: this fix introduce dtrace test, which verify that different combinations of available compile levels(and, in case compile levels allows it, different code heaps as result) doesn't affect callstack shown by dtrace. There is a control class SegmentedCodeCacheDtraceTest.java and class for running via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also present (SegmentedCodeCacheDtraceTestScript.d). A control class is using DtraceRunner.java to run dtrace and then analyzing results using class SegmentedCodeCacheDtraceResultsAnalyzer with DtraceResultsAnalyzer interface. There is also a small class CompilerUtils.java created for usefull common code. webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ Additional note: Please note that this path assumes that fix for JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also applied. Thanks, Dmitrij From vladimir.kozlov at oracle.com Fri Dec 19 19:16:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Dec 2014 11:16:58 -0800 Subject: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout In-Reply-To: <872d488f-555b-43c6-a87d-0d2f862970a4@default> References: <872d488f-555b-43c6-a87d-0d2f862970a4@default> Message-ID: <549479AA.9030100@oracle.com> I googled it and it explained that Thread.sleep(0) is not free. I am fine with this change. Thanks, Vladimir On 12/18/14 9:52 PM, Pavel Chistyakov wrote: > Hi, Vladimir > > It's a little confusing corner case: to call sleep w/ 0 (zero) => expecting not to have any pause. > If we call sleep w/ any other value then we expect some pause. > > So, in this case we need to prevent any pause. For this reason I added a conditional sleep call. > > --------- > Thanks, > Pavel > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Friday, December 12, 2014 12:57:29 AM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout > > Why it is a problem? > > /** > * Class which runs another Runnable in infinite loop with certain pauses > * between cycles. > */ > > It does not say that it will not pause for few instructions to execute Thread.sleep(0). > > Thanks, > Vladimir > > On 12/9/14 8:50 AM, Pavel Chistyakov wrote: >> Hi all, >> >> please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066896 >> webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066896/webrev.00/ >> >> >> Problem: >> InfiniteLoop allows zero value as timeout and waste time for Thread.sleep(0) call that is not needed in this case. >> >> Solution: >> Add a condition for skipping 0 (zero) timeout when calling Thread.sleep >> >> Testing: manual >> >> ------------------- >> Thanks, >> Pavel From pavel.chistyakov at oracle.com Fri Dec 19 20:12:23 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Fri, 19 Dec 2014 12:12:23 -0800 (PST) Subject: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout Message-ID: Hi Vladimir, thank you for review. --------- Pavel ----- Original Message ----- From: vladimir.kozlov at oracle.com To: pavel.chistyakov at oracle.com Cc: hotspot-compiler-dev at openjdk.java.net Sent: Friday, December 19, 2014 10:16:17 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout I googled it and it explained that Thread.sleep(0) is not free. I am fine with this change. Thanks, Vladimir On 12/18/14 9:52 PM, Pavel Chistyakov wrote: > Hi, Vladimir > > It's a little confusing corner case: to call sleep w/ 0 (zero) => expecting not to have any pause. > If we call sleep w/ any other value then we expect some pause. > > So, in this case we need to prevent any pause. For this reason I added a conditional sleep call. > > --------- > Thanks, > Pavel > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Friday, December 12, 2014 12:57:29 AM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR (XXS): 8066896: Update c.o.j.t.InfiniteLoop to skip zero timeout > > Why it is a problem? > > /** > * Class which runs another Runnable in infinite loop with certain pauses > * between cycles. > */ > > It does not say that it will not pause for few instructions to execute Thread.sleep(0). > > Thanks, > Vladimir > > On 12/9/14 8:50 AM, Pavel Chistyakov wrote: >> Hi all, >> >> please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066896 >> webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066896/webrev.00/ >> >> >> Problem: >> InfiniteLoop allows zero value as timeout and waste time for Thread.sleep(0) call that is not needed in this case. >> >> Solution: >> Add a condition for skipping 0 (zero) timeout when calling Thread.sleep >> >> Testing: manual >> >> ------------------- >> Thanks, >> Pavel From vladimir.kozlov at oracle.com Fri Dec 19 20:35:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Dec 2014 12:35:11 -0800 Subject: C2: cyclic IR for JVMS In-Reply-To: <54944849.2070805@oracle.com> References: <54921948.5010702@oracle.com> <549228BA.1050002@oracle.com> <549307CD.1070802@oracle.com> <8DDC9641-7D4F-4B2E-A713-25D373DA1D45@oracle.com> <549326D3.3020007@oracle.com> <54944849.2070805@oracle.com> Message-ID: <54948BFF.2030501@oracle.com> Did you find why "the call node is live, though the loop was dead"? I think I assumed that calls are safe - can't be in dead loop. Your fix is reasonable but, first, fins why call is alive. Thanks, Vladimir On 12/19/14 7:46 AM, Vladimir Ivanov wrote: > So, if return value projection is not considered dead loop safe [1], the > problem goes away. > > I'm curious whether it was an overlook in 6625997 [1] [2]. > > Best regards, > Vladimir Ivanov > > [1] > diff --git a/src/share/vm/opto/multnode.hpp > b/src/share/vm/opto/multnode.hpp > --- a/src/share/vm/opto/multnode.hpp > +++ b/src/share/vm/opto/multnode.hpp > @@ -68,7 +68,7 @@ > { > init_class_id(Class_Proj); > // Optimistic setting. Need additional checks in > Node::is_dead_loop_safe(). > - if (con != TypeFunc::Memory || src->is_Start()) > + if ((con != TypeFunc::Memory && con != TypeFunc::Parms) || > src->is_Start()) > init_flags(Flag_is_dead_loop_safe); > debug_only(check_con()); > } > > [2] https://jbs.oracle.com/bugs/browse/JDK-6625997 > [3] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/diff/72f4a668df19/src/share/vm/opto/multnode.hpp > > > On 12/18/14 10:11 PM, Vladimir Ivanov wrote: >> Roland, >> >> The code is reachable by the time inlining occurs, but the call node is >> broken. >> >> The transformation which breaks the code is performed in >> RegionNode::Ideal() >> Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) >> ==> >> (Proj #5 (CallStaticJava ... Proj(backref)...)) >> >> The RegionNode and Phi are removed, but CallStaticJava is broken. >> >> It seems that if RegionNode::is_unreachable_region() detected that >> RegionNode is dead, it would break the vicious circle (PhiNode is >> replaced by top()). >> >> Not sure why the call node is live, though the loop was dead. >> >> Best regards, >> Vladimir Ivanov >> >> On 12/18/14, 8:25 PM, Roland Westrelin wrote: >>>> As my investigations show, it's a leftover from a loop. >>>> CallStaticJava represents loop counter increment. >>>> >>>> The graph is as follows: >>>> Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) >>>> >>>> The Region is dead, but RegionNode::is_unreachable_region doesn't >>>> detect that. Node::simple_data_loop_check(Phi, Proj) doesn't find the >>>> cycle, because most of Proj nodes have Flag_is_dead_loop_safe set [1]. >>>> And I don't understand why it is so. Is the check in >>>> Node::is_dead_loop_safe() too weak or Flag_is_dead_loop_safe too >>>> "optimistic"? :-) >>> >>> Isn?t the problem that you try to late inline a call that is dead and >>> that the checks in LateInlineCallGenerator::do_late_inline(): >>> >>> if (call == NULL || call->outcnt() == 0 || >>> call->in(0) == NULL || call->in(0)->is_top()) { >>> return; >>> } >>> >>> const TypeTuple *r = call->tf()->domain(); >>> for (int i1 = 0; i1 < method()->arg_size(); i1++) { >>> if (call->in(TypeFunc::Parms + i1)->is_top() && >>> r->field_at(TypeFunc::Parms + i1) != Type::HALF) { >>> assert(Compile::current()->inlining_incrementally(), "shouldn't >>> happen during parsing"); >>> return; >>> } >>> } >>> >>> if (call->in(TypeFunc::Memory)->is_top()) { >>> assert(Compile::current()->inlining_incrementally(), "shouldn't >>> happen during parsing"); >>> return; >>> } >>> >>> don?t detect it? >>> FWIW, I know there are rare cases where those tests are not >>> sufficient. Ideally, you would need Compile::inline_incrementally() >>> to do: >>> PhaseIdealLoop ideal_loop( igvn, false, true ); >>> after every inline but that?s very expensive. >>> >>> Roland. >>> From vladimir.x.ivanov at oracle.com Fri Dec 19 23:07:21 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 20 Dec 2014 02:07:21 +0300 Subject: C2: cyclic IR for JVMS In-Reply-To: <54948BFF.2030501@oracle.com> References: <54921948.5010702@oracle.com> <549228BA.1050002@oracle.com> <549307CD.1070802@oracle.com> <8DDC9641-7D4F-4B2E-A713-25D373DA1D45@oracle.com> <549326D3.3020007@oracle.com> <54944849.2070805@oracle.com> <54948BFF.2030501@oracle.com> Message-ID: <5494AFA9.5080507@oracle.com> No, I have hard time gathering more data about the problem. I'm able to reproduce it only with product binaries and it happens during huge method compilation. Will try to add additional instrumentation, but I wouldn't expect much. Best regards, Vladimir Ivanov On 12/19/14 11:35 PM, Vladimir Kozlov wrote: > Did you find why "the call node is live, though the loop was dead"? > I think I assumed that calls are safe - can't be in dead loop. > Your fix is reasonable but, first, fins why call is alive. > > Thanks, > Vladimir > > On 12/19/14 7:46 AM, Vladimir Ivanov wrote: >> So, if return value projection is not considered dead loop safe [1], the >> problem goes away. >> >> I'm curious whether it was an overlook in 6625997 [1] [2]. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> diff --git a/src/share/vm/opto/multnode.hpp >> b/src/share/vm/opto/multnode.hpp >> --- a/src/share/vm/opto/multnode.hpp >> +++ b/src/share/vm/opto/multnode.hpp >> @@ -68,7 +68,7 @@ >> { >> init_class_id(Class_Proj); >> // Optimistic setting. Need additional checks in >> Node::is_dead_loop_safe(). >> - if (con != TypeFunc::Memory || src->is_Start()) >> + if ((con != TypeFunc::Memory && con != TypeFunc::Parms) || >> src->is_Start()) >> init_flags(Flag_is_dead_loop_safe); >> debug_only(check_con()); >> } >> >> [2] https://jbs.oracle.com/bugs/browse/JDK-6625997 >> [3] >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/diff/72f4a668df19/src/share/vm/opto/multnode.hpp >> >> >> >> On 12/18/14 10:11 PM, Vladimir Ivanov wrote: >>> Roland, >>> >>> The code is reachable by the time inlining occurs, but the call node is >>> broken. >>> >>> The transformation which breaks the code is performed in >>> RegionNode::Ideal() >>> Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) >>> ==> >>> (Proj #5 (CallStaticJava ... Proj(backref)...)) >>> >>> The RegionNode and Phi are removed, but CallStaticJava is broken. >>> >>> It seems that if RegionNode::is_unreachable_region() detected that >>> RegionNode is dead, it would break the vicious circle (PhiNode is >>> replaced by top()). >>> >>> Not sure why the call node is live, though the loop was dead. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 12/18/14, 8:25 PM, Roland Westrelin wrote: >>>>> As my investigations show, it's a leftover from a loop. >>>>> CallStaticJava represents loop counter increment. >>>>> >>>>> The graph is as follows: >>>>> Phi (Region) (Proj #5 (CallStaticJava ... Phi(backref)...)) >>>>> >>>>> The Region is dead, but RegionNode::is_unreachable_region doesn't >>>>> detect that. Node::simple_data_loop_check(Phi, Proj) doesn't find the >>>>> cycle, because most of Proj nodes have Flag_is_dead_loop_safe set [1]. >>>>> And I don't understand why it is so. Is the check in >>>>> Node::is_dead_loop_safe() too weak or Flag_is_dead_loop_safe too >>>>> "optimistic"? :-) >>>> >>>> Isn?t the problem that you try to late inline a call that is dead and >>>> that the checks in LateInlineCallGenerator::do_late_inline(): >>>> >>>> if (call == NULL || call->outcnt() == 0 || >>>> call->in(0) == NULL || call->in(0)->is_top()) { >>>> return; >>>> } >>>> >>>> const TypeTuple *r = call->tf()->domain(); >>>> for (int i1 = 0; i1 < method()->arg_size(); i1++) { >>>> if (call->in(TypeFunc::Parms + i1)->is_top() && >>>> r->field_at(TypeFunc::Parms + i1) != Type::HALF) { >>>> assert(Compile::current()->inlining_incrementally(), "shouldn't >>>> happen during parsing"); >>>> return; >>>> } >>>> } >>>> >>>> if (call->in(TypeFunc::Memory)->is_top()) { >>>> assert(Compile::current()->inlining_incrementally(), "shouldn't >>>> happen during parsing"); >>>> return; >>>> } >>>> >>>> don?t detect it? >>>> FWIW, I know there are rare cases where those tests are not >>>> sufficient. Ideally, you would need Compile::inline_incrementally() >>>> to do: >>>> PhaseIdealLoop ideal_loop( igvn, false, true ); >>>> after every inline but that?s very expensive. >>>> >>>> Roland. >>>> From vladimir.x.ivanov at oracle.com Fri Dec 19 23:31:06 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 20 Dec 2014 02:31:06 +0300 Subject: [9] RFR (S): 8067338: compiler/debug/TraceIterativeGVN.java segfaults Message-ID: <5494B53A.5040409@oracle.com> http://cr.openjdk.java.net/~vlivanov/8067338/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8067338 Yet another crash during IGVN tracing. Tried to maek *::dump_spec more reliable. Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Fri Dec 19 23:56:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Dec 2014 15:56:16 -0800 Subject: [9] RFR (S): 8067338: compiler/debug/TraceIterativeGVN.java segfaults In-Reply-To: <5494B53A.5040409@oracle.com> References: <5494B53A.5040409@oracle.com> Message-ID: <5494BB20.7090303@oracle.com> Looks good. Thanks, Vladimir On 12/19/14 3:31 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8067338/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8067338 > > Yet another crash during IGVN tracing. > Tried to maek *::dump_spec more reliable. > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Sat Dec 20 00:11:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 20 Dec 2014 03:11:12 +0300 Subject: [9] RFR (S): 8067338: compiler/debug/TraceIterativeGVN.java segfaults In-Reply-To: <5494BB20.7090303@oracle.com> References: <5494B53A.5040409@oracle.com> <5494BB20.7090303@oracle.com> Message-ID: <5494BEA0.7010702@oracle.com> Thanks, Vladimir. Best regards, Vladimir Ivanov On 12/20/14 2:56 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 12/19/14 3:31 PM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8067338/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8067338 >> >> Yet another crash during IGVN tracing. >> Tried to maek *::dump_spec more reliable. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From evgeniya.stepanova at oracle.com Mon Dec 22 09:52:00 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Mon, 22 Dec 2014 01:52:00 -0800 (PST) Subject: RFR(XS): 8066864: remove ctw-test from testlibrary/ Message-ID: <452642db-d20f-4a51-85b1-dbe507e89ed1@default> Hi Please review changes for 8066864 Issue: while applying http://cr.openjdk.java.net/~iignatyev/eistepan/8025606/webrev.00/ to the repo copying was performed instead of renaming. Fix: remove folder remained bug: https://bugs.openjdk.java.net/browse/JDK-8066864 webrev: http://cr.openjdk.java.net/~eistepan/8066864/webrev.00/ Thank you, Evgeniya Stepanova From roland.westrelin at oracle.com Mon Dec 22 10:43:11 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 22 Dec 2014 11:43:11 +0100 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined In-Reply-To: <87E2D6EA-D0D6-49C2-844F-E37FB2D2370D@oracle.com> References: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> <549465E3.9070405@oracle.com> <41CA7748-5730-4D7C-BB10-5330600DEC64@oracle.com> <5494696E.3070200@oracle.com> <87E2D6EA-D0D6-49C2-844F-E37FB2D2370D@oracle.com> Message-ID: >> I don't understand how you solved the problem in product build by relaxing the assert. > > Ok. I thought more about it and that makes sense. I?ll send an updated webrev with a bailout. Here is a new webrev: http://cr.openjdk.java.net/~roland/8055530/webrev.01/ Roland. >> >> Thanks, >> Vladimir >> >> On 12/19/14 9:58 AM, Roland Westrelin wrote: >>> Thanks for looking at this, Vladimir. >>> >>>> Why not bailout compilation when you detect such case? You changed only the assert. >>> >>> I thought about it. But it seems to me that similar inconsistencies might occur elsewhere during compilation and that we wouldn't necessarily detect them. So why a special case here? >>> >>> Roland. >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/19/14 5:50 AM, Roland Westrelin wrote: >>>>> http://cr.openjdk.java.net/~roland/8055530/webrev.00/ >>>>> >>>>> From a core file: >>>>> >>>>> method being compiled is sun.nio.cs.ISO_8859_1::newDecoder >>>>> >>>>> public java.nio.charset.CharsetDecoder newDecoder(); >>>>> Code: >>>>> 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder >>>>> 3: dup >>>>> 4: aload_0 >>>>> 5: aconst_null >>>>> 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V >>>>> 9: areturn >>>>> >>>>> _exits.control() is a Region node. >>>>> _gvn.type(ret_phi) is top >>>>> >>>>> ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result ab! >>>> ove the ce >>>> nter line, which filter turns into top. >>>>> >>>>> I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. >>>>> >>>>> Roland. >>>>> >>> > From igor.ignatyev at oracle.com Mon Dec 22 14:50:05 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 22 Dec 2014 17:50:05 +0300 Subject: RFR(XS): 8066864: remove ctw-test from testlibrary/ In-Reply-To: <452642db-d20f-4a51-85b1-dbe507e89ed1@default> References: <452642db-d20f-4a51-85b1-dbe507e89ed1@default> Message-ID: <54982F9D.6080204@oracle.com> looks good. Igor On 12/22/2014 12:52 PM, Evgeniya Stepanova wrote: > Hi > Please review changes for 8066864 > > Issue: while applying http://cr.openjdk.java.net/~iignatyev/eistepan/8025606/webrev.00/ to the repo copying was performed instead of renaming. > Fix: remove folder remained > > bug: https://bugs.openjdk.java.net/browse/JDK-8066864 > webrev: http://cr.openjdk.java.net/~eistepan/8066864/webrev.00/ > > Thank you, > Evgeniya Stepanova > From igor.ignatyev at oracle.com Mon Dec 22 14:59:32 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 22 Dec 2014 17:59:32 +0300 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... In-Reply-To: <548EEAD8.7000509@oracle.com> References: <548B5603.5030902@oracle.com> <548EEAD8.7000509@oracle.com> Message-ID: <549831D4.1070701@oracle.com> Dmitrij, all fixes look good to me. // could you please send separate RFR for each CR next time? Thanks, Igor On 12/15/2014 05:06 PM, Dmitrij Pochepko wrote: > Hi, > a bit of update for https://bugs.openjdk.java.net/browse/JDK-8067295 > (port of JDK-8066440) > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.01/ > > Thanks, > Dmitrij >> Hi, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm >> checks in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking >> which vm is run >> https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils >> chagnes from JDK-8059613 into jdk workspace >> https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom >> classloaders(parent-last and filtering one) for JDK-8066625 in >> testlibrary >> >> Description: A number of small testlibrary changes needed for further >> test development, 2 of 3 is port from respective hotspot changes >> 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is >> FilterClassLoader - loads classes using target classloader in case >> class name meets provided condition, and using parent otherwise. 2nd >> is ParentLastURLClassLoader which loads classes using provided URL[] >> with fallback to parent, >> >> Webrevs: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ >> >> Thanks, >> Dmitrij > From filipp.zhinkin at oracle.com Mon Dec 22 15:06:16 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 22 Dec 2014 19:06:16 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <5493FEE4.9070503@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> Message-ID: <54983368.7030303@oracle.com> Christian, are you ok with the latest fix version? Thanks, Filipp. On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: > Christian, thank you for review! > > I've updated tests to reflect WhiteBox movement to top-level repo, > added previously missed @bug tag and fixed few small issues: > > incremental diff: > http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ > > updated webrev: > http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ > > Thanks, > Filipp. > > On 12/19/2014 02:19 AM, Christian Thalinger wrote: >> Looks good. >> >>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann >>> wrote: >>> >>> Hi Filipp, >>> >>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>> Tobias, >>>> >>>> as I wrote you in a private message, until a fix for 8064940 doesn't affect >>>> the way options are processed there is no need to update proposed tests. >>>> >>>> I've filed 8067135 for new tests that will verify actual alignment of code >>>> heaps. >>> Okay, sounds good. >>> >>> Thanks, >>> Tobias >>> >>>> Regards, >>>> Filipp. >>>> >>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>> Hi Tobias, >>>>>>> >>>>>>> thank you for suggestion. >>>>>>> >>>>>>> Yes, I think we should take code heap size alignment into account. >>>>>>> >>>>>>> What alignment policy you're going to implement for 8064940? >>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>> >>>>>>> Maybe instead of checking that values are in >>>>>>> (value - page_size, value + page_size) interval we should just check >>>>>>> that all values were aligned up to page_size? >>>>>> Yes, that's a better solution. However, I don't know how to figure out the >>>>>> available page sizes from Java code. >>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>> about to add such method to WB API, but it need to check how well >>>>> it is going to work with large pages. >>>>> >>>>> Thanks, >>>>> Filipp. >>>>>> Best, >>>>>> Tobias >>>>>> >>>>>>> Thanks, >>>>>>> Filipp. >>>>>>> >>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>> Hi Filipp, >>>>>>>> >>>>>>>> the actual size of a code heap is affected by alignment and therefore >>>>>>>> may be >>>>>>>> different to the size set via the command line. For example, on Sparc we >>>>>>>> have to >>>>>>>> make sure that the code heaps are large page (4MB) aligned to reduce the >>>>>>>> number >>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>> >>>>>>>> Maybe we should check if the actual size of the code heap is within >>>>>>>> boundaries, >>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>> >>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>>>>>>> >>>>>>>>> There are three new tests: >>>>>>>>> compiler/codecache/cli/ >>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>> >>>>>>>>> All tests consist of several test cases aimed to verify different aspects >>>>>>>>> of options' processing. >>>>>>>>> >>>>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>>>>>>> but add additional value - these tests actually check final values >>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>> >>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>> Testing: manual & automated >>>>>>>>> >>>>>>>>> This change depends on: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI >>>>>>>>> tests >>>>>>>>> error reporting >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>>>> testlibrary >>>>>>>>> for JDK-8059613 >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Filipp. > From christian.thalinger at oracle.com Mon Dec 22 17:01:46 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Dec 2014 09:01:46 -0800 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <54983368.7030303@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> Message-ID: <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> Yes, looks good. > On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin wrote: > > Christian, are you ok with the latest fix version? > > Thanks, > Filipp. > > On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: >> Christian, thank you for review! >> >> I've updated tests to reflect WhiteBox movement to top-level repo, >> added previously missed @bug tag and fixed few small issues: >> >> incremental diff: >> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ >> >> updated webrev: >> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ >> >> Thanks, >> Filipp. >> >> On 12/19/2014 02:19 AM, Christian Thalinger wrote: >>> Looks good. >>> >>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann wrote: >>>> >>>> Hi Filipp, >>>> >>>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>>> Tobias, >>>>> >>>>> as I wrote you in a private message, until a fix for 8064940 doesn't affect >>>>> the way options are processed there is no need to update proposed tests. >>>>> >>>>> I've filed 8067135 for new tests that will verify actual alignment of code heaps. >>>> Okay, sounds good. >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> Regards, >>>>> Filipp. >>>>> >>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>>> Hi Tobias, >>>>>>>> >>>>>>>> thank you for suggestion. >>>>>>>> >>>>>>>> Yes, I think we should take code heap size alignment into account. >>>>>>>> >>>>>>>> What alignment policy you're going to implement for 8064940? >>>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>>> >>>>>>>> Maybe instead of checking that values are in >>>>>>>> (value - page_size, value + page_size) interval we should just check >>>>>>>> that all values were aligned up to page_size? >>>>>>> Yes, that's a better solution. However, I don't know how to figure out the >>>>>>> available page sizes from Java code. >>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>>> about to add such method to WB API, but it need to check how well >>>>>> it is going to work with large pages. >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>>>>> Best, >>>>>>> Tobias >>>>>>> >>>>>>>> Thanks, >>>>>>>> Filipp. >>>>>>>> >>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>>> Hi Filipp, >>>>>>>>> >>>>>>>>> the actual size of a code heap is affected by alignment and therefore may be >>>>>>>>> different to the size set via the command line. For example, on Sparc we >>>>>>>>> have to >>>>>>>>> make sure that the code heaps are large page (4MB) aligned to reduce the >>>>>>>>> number >>>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>>> >>>>>>>>> Maybe we should check if the actual size of the code heap is within >>>>>>>>> boundaries, >>>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>>> >>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>>>>>>>> >>>>>>>>>> There are three new tests: >>>>>>>>>> compiler/codecache/cli/ >>>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>>> >>>>>>>>>> All tests consist of several test cases aimed to verify different aspects >>>>>>>>>> of options' processing. >>>>>>>>>> >>>>>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>>>>>>>> but add additional value - these tests actually check final values >>>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>>> >>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>>> Testing: manual & automated >>>>>>>>>> >>>>>>>>>> This change depends on: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI >>>>>>>>>> tests >>>>>>>>>> error reporting >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>>>>> testlibrary >>>>>>>>>> for JDK-8059613 >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Filipp. >> > From vladimir.kozlov at oracle.com Mon Dec 22 17:12:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Dec 2014 09:12:35 -0800 Subject: RFR(XS): 8066864: remove ctw-test from testlibrary/ In-Reply-To: <452642db-d20f-4a51-85b1-dbe507e89ed1@default> References: <452642db-d20f-4a51-85b1-dbe507e89ed1@default> Message-ID: <54985103.1070107@oracle.com> Good. Thanks, Vladimir On 12/22/14 1:52 AM, Evgeniya Stepanova wrote: > Hi > Please review changes for 8066864 > > Issue: while applying http://cr.openjdk.java.net/~iignatyev/eistepan/8025606/webrev.00/ to the repo copying was performed instead of renaming. > Fix: remove folder remained > > bug: https://bugs.openjdk.java.net/browse/JDK-8066864 > webrev: http://cr.openjdk.java.net/~eistepan/8066864/webrev.00/ > > Thank you, > Evgeniya Stepanova > From vladimir.kozlov at oracle.com Mon Dec 22 17:20:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Dec 2014 09:20:08 -0800 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined In-Reply-To: References: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> <549465E3.9070405@oracle.com> <41CA7748-5730-4D7C-BB10-5330600DEC64@oracle.com> <5494696E.3070200@oracle.com> <87E2D6EA-D0D6-49C2-844F-E37FB2D2370D@oracle.com> Message-ID: <549852C8.1020608@oracle.com> This looks good. Thanks, Vladimir On 12/22/14 2:43 AM, Roland Westrelin wrote: >>> I don't understand how you solved the problem in product build by relaxing the assert. >> >> Ok. I thought more about it and that makes sense. I?ll send an updated webrev with a bailout. > > Here is a new webrev: > http://cr.openjdk.java.net/~roland/8055530/webrev.01/ > > Roland. > >>> >>> Thanks, >>> Vladimir >>> >>> On 12/19/14 9:58 AM, Roland Westrelin wrote: >>>> Thanks for looking at this, Vladimir. >>>> >>>>> Why not bailout compilation when you detect such case? You changed only the assert. >>>> >>>> I thought about it. But it seems to me that similar inconsistencies might occur elsewhere during compilation and that we wouldn't necessarily detect them. So why a special case here? >>>> >>>> Roland. >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/19/14 5:50 AM, Roland Westrelin wrote: >>>>>> http://cr.openjdk.java.net/~roland/8055530/webrev.00/ >>>>>> >>>>>> From a core file: >>>>>> >>>>>> method being compiled is sun.nio.cs.ISO_8859_1::newDecoder >>>>>> >>>>>> public java.nio.charset.CharsetDecoder newDecoder(); >>>>>> Code: >>>>>> 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder >>>>>> 3: dup >>>>>> 4: aload_0 >>>>>> 5: aconst_null >>>>>> 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V >>>>>> 9: areturn >>>>>> >>>>>> _exits.control() is a Region node. >>>>>> _gvn.type(ret_phi) is top >>>>>> >>>>>> ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result ab! >>>>> ove the ce >>>>> nter line, which filter turns into top. >>>>>> >>>>>> I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. >>>>>> >>>>>> Roland. >>>>>> >>>> >> > From roland.westrelin at oracle.com Mon Dec 22 17:34:27 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 22 Dec 2014 18:34:27 +0100 Subject: RFR(XS): 8055530: assert(_exits.control()->is_top() || !_gvn.type(ret_phi)->empty()) failed: return value must be well defined In-Reply-To: <549852C8.1020608@oracle.com> References: <5E1E544C-CE71-465D-8162-E485D3908ADE@oracle.com> <549465E3.9070405@oracle.com> <41CA7748-5730-4D7C-BB10-5330600DEC64@oracle.com> <5494696E.3070200@oracle.com> <87E2D6EA-D0D6-49C2-844F-E37FB2D2370D@oracle.com> <549852C8.1020608@oracle.com> Message-ID: Thanks for the review, Vladimir. Roland. > On Dec 22, 2014, at 6:20 PM, Vladimir Kozlov wrote: > > This looks good. > > Thanks, > Vladimir > > On 12/22/14 2:43 AM, Roland Westrelin wrote: >>>> I don't understand how you solved the problem in product build by relaxing the assert. >>> >>> Ok. I thought more about it and that makes sense. I?ll send an updated webrev with a bailout. >> >> Here is a new webrev: >> http://cr.openjdk.java.net/~roland/8055530/webrev.01/ >> >> Roland. >> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/19/14 9:58 AM, Roland Westrelin wrote: >>>>> Thanks for looking at this, Vladimir. >>>>> >>>>>> Why not bailout compilation when you detect such case? You changed only the assert. >>>>> >>>>> I thought about it. But it seems to me that similar inconsistencies might occur elsewhere during compilation and that we wouldn't necessarily detect them. So why a special case here? >>>>> >>>>> Roland. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/19/14 5:50 AM, Roland Westrelin wrote: >>>>>>> http://cr.openjdk.java.net/~roland/8055530/webrev.00/ >>>>>>> >>>>>>> From a core file: >>>>>>> >>>>>>> method being compiled is sun.nio.cs.ISO_8859_1::newDecoder >>>>>>> >>>>>>> public java.nio.charset.CharsetDecoder newDecoder(); >>>>>>> Code: >>>>>>> 0: new #7; //class sun/nio/cs/ISO_8859_1$Decoder >>>>>>> 3: dup >>>>>>> 4: aload_0 >>>>>>> 5: aconst_null >>>>>>> 6: invokespecial #8; //Method sun/nio/cs/ISO_8859_1$Decoder."":(Ljava/nio/charset/Charset;Lsun/nio/cs/ISO_8859_1$1;)V >>>>>>> 9: areturn >>>>>>> >>>>>>> _exits.control() is a Region node. >>>>>>> _gvn.type(ret_phi) is top >>>>>>> >>>>>>> ret_phi has a single input a CheckCastPP from the initialization node. Type of the CheckCastPP is TypeInstPtr sun/nio/cs/ISO_8859_1$Decoder. The type of the Phi when it's created in Parse::build_exits() is set to tf()->range()->field_at(TypeFunc::Parms). Here it's TypeInstPtr sun/nio/cs/UTF_8$Decoder, so not the type from the signature (java.nio.charset.CharsetDecoder) but a subtype. That would be the case because in TypeOopPtr::make_from_klass_common(), we define the type with unique_concrete_subklass() and CharsetDecoder is abstract. So UTF_8$Decoder is the only loaded subclass when the compilation starts and ISO_8859_1$Decoder is loaded during compilation. So this compilation will have to be retried because the assumption in TypeOopPtr::make_from_klass_common() that there's a single subclass will be invalid. When the type of the Phi is computed in do_exits(), UTF_8$Decoder and ISO_8859_1$Decoder are joined which given one is not a subclass of the other gives a result ab! >>>>>> ove the ce >>>>>> nter line, which filter turns into top. >>>>>>> >>>>>>> I could reproduce the assert failure with a test case I wrote and stop the compiler thread, load a class concurrently and restart the compiler thread. >>>>>>> >>>>>>> Roland. >>>>>>> >>>>> >>> >> From vladimir.kozlov at oracle.com Mon Dec 22 17:42:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Dec 2014 09:42:05 -0800 Subject: jdk9/hs-comp/ is locked until we resolve merge with hs/ Message-ID: <549857ED.3020206@oracle.com> We need to do manual merge with additional bugs fixing because of conflicting changes in tests caused by "8066433: Move Whitebox test library to top level repository" I will let you know when we finish merge. Regards, Vladimir From evgeniya.stepanova at oracle.com Mon Dec 22 18:01:19 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Mon, 22 Dec 2014 22:01:19 +0400 Subject: RFR(XS): 8066864: remove ctw-test from testlibrary/ In-Reply-To: <54985103.1070107@oracle.com> References: <452642db-d20f-4a51-85b1-dbe507e89ed1@default> <54985103.1070107@oracle.com> Message-ID: <54985C6F.3020902@oracle.com> Vladimir, thank you for the review! On 22.12.2014 21:12, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/22/14 1:52 AM, Evgeniya Stepanova wrote: >> Hi >> Please review changes for 8066864 >> >> Issue: while applying >> http://cr.openjdk.java.net/~iignatyev/eistepan/8025606/webrev.00/ to >> the repo copying was performed instead of renaming. >> Fix: remove folder remained >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8066864 >> webrev: http://cr.openjdk.java.net/~eistepan/8066864/webrev.00/ >> >> Thank you, >> Evgeniya Stepanova >> -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeniya.stepanova at oracle.com Mon Dec 22 18:01:33 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Mon, 22 Dec 2014 22:01:33 +0400 Subject: RFR(XS): 8066864: remove ctw-test from testlibrary/ In-Reply-To: <54982F9D.6080204@oracle.com> References: <452642db-d20f-4a51-85b1-dbe507e89ed1@default> <54982F9D.6080204@oracle.com> Message-ID: <54985C7D.8060304@oracle.com> Igor, thank you for the review! On 22.12.2014 18:50, Igor Ignatyev wrote: > looks good. > > Igor > > On 12/22/2014 12:52 PM, Evgeniya Stepanova wrote: >> Hi >> Please review changes for 8066864 >> >> Issue: while applying >> http://cr.openjdk.java.net/~iignatyev/eistepan/8025606/webrev.00/ to >> the repo copying was performed instead of renaming. >> Fix: remove folder remained >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8066864 >> webrev: http://cr.openjdk.java.net/~eistepan/8066864/webrev.00/ >> >> Thank you, >> Evgeniya Stepanova >> -- /Evgeniya Stepanova/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Dec 22 22:13:30 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Dec 2014 14:13:30 -0800 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: References: Message-ID: <84D42F52-6D9E-46AF-96BA-3DA5F4567323@oracle.com> Can we keep these on the same line? 44 public class OverloadCompileQueueTest implements Runnable { 49 private static final boolean INTERPRETED 50 = System.getProperty("java.vm.info").startsWith("interpreted "); 51 private static final boolean TIERED_COMPILATION 52 = Helper.WHITE_BOX.getBooleanVMFlag("TieredCompilation"); 53 private static final int TIERED_STOP_AT_LEVEL 54 = Helper.WHITE_BOX.getIntxVMFlag("TieredStopAtLevel").intValue(); 43 public class RandomAllocationTest implements Runnable { 44 private static final long CODE_CACHE_SIZE 45 = Helper.WHITE_BOX.getUintxVMFlag("ReservedCodeCacheSize"); 46 private static final int MAX_BLOB_SIZE = (int) (CODE_CACHE_SIZE >> 7); 47 private static final BlobType[] BLOB_TYPES 48 = BlobType.getAvailable().toArray(new BlobType[0]); It?s 2015 (soon); we really don?t have to stay under 80 characters. Otherwise this looks good. > On Dec 19, 2014, at 2:53 AM, Pavel Chistyakov wrote: > > Hi Christian, > > Yes, here is updated version: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 > Could you please take a look into it? > > -------- > Thanks, > Pavel > > ----- Original Message ----- > From: christian.thalinger at oracle.com > To: igor.ignatyev at oracle.com > Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net > Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests > > >> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev wrote: >> >> Pavel, >> >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >> >>> 45 CLASS_DATA = loadClassData(TestCaseImpl.class.getName()); >>> 95 String className = TestCaseImpl.class.getName(); >> >> these lines will load 'TestCaseImpl' class via default class loader, could you try to avoid it? > > Any update on that? > >> >> Igor >> >> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>> Hi, >>> >>> please take a look into slightly updated webrev: >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>> >>> >>> -------------- >>> Thanks, >>> Pavel >>> >>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>> Looks fine. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>> >>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>> wrote: >>>>> >>>>>> David, thank you for review. >>>>>> Here is updated webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>> >>>>> >>>>> That is excellent -- now we just need a real reviewer. >>>>> >>>>> David >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Dec 22 22:17:55 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Dec 2014 14:17:55 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54947677.7050104@oracle.com> References: <54947677.7050104@oracle.com> Message-ID: 40 public static int[] getAvailableCompilationLevels() { 41 if (System.getProperty("java.vm.info").startsWith("interpreted ")) { 42 return new int[0]; 43 } Wouldn?t it be better to check the UseCompiler flag instead? > On Dec 19, 2014, at 11:03 AM, Dmitrij Pochepko wrote: > > Hi all, > > Please review changes for https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature > > Description: this fix introduce dtrace test, which verify that different combinations of available compile levels(and, in case compile levels allows it, different code heaps as result) doesn't affect callstack shown by dtrace. There is a control class SegmentedCodeCacheDtraceTest.java and class for running via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also present (SegmentedCodeCacheDtraceTestScript.d). A control class is using DtraceRunner.java to run dtrace and then analyzing results using class SegmentedCodeCacheDtraceResultsAnalyzer with DtraceResultsAnalyzer interface. > There is also a small class CompilerUtils.java created for usefull common code. > > webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ > > Additional note: Please note that this path assumes that fix for JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also applied. > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Mon Dec 22 22:31:23 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 23 Dec 2014 01:31:23 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <84D42F52-6D9E-46AF-96BA-3DA5F4567323@oracle.com> References: <84D42F52-6D9E-46AF-96BA-3DA5F4567323@oracle.com> Message-ID: <54989BBB.5080006@oracle.com> Chris, >> It?s 2015 (soon); we really don?t have to stay under 80 characters. I'll argue about 80 characters limitation. we do have to at least try to stay under 80, because there are 2 buffer diff-view, and it's literally impossible to use it in case of more than 80 characters, even now in 2015. I recall the review there it looked like nothing was changed, because length of line was longer than my monitor can include, and I spent some time trying to figured out why the file was shown as modified. so I'd prefer to have good old 80 characters. Igor On 12/23/2014 01:13 AM, Christian Thalinger wrote: > Can we keep these on the same line? > > 44 public class OverloadCompileQueueTest implements Runnable { > > 49 private static final boolean INTERPRETED > 50 = System.getProperty("java.vm.info").startsWith("interpreted "); > 51 private static final boolean TIERED_COMPILATION > 52 = Helper.WHITE_BOX.getBooleanVMFlag("TieredCompilation"); > 53 private static final int TIERED_STOP_AT_LEVEL > 54 = Helper.WHITE_BOX.getIntxVMFlag("TieredStopAtLevel").intValue(); > > > 43 public class RandomAllocationTest implements Runnable { > 44 private static final long CODE_CACHE_SIZE > 45 = Helper.WHITE_BOX.getUintxVMFlag("ReservedCodeCacheSize"); > 46 private static final int MAX_BLOB_SIZE = (int) (CODE_CACHE_SIZE >> 7); > 47 private static final BlobType[] BLOB_TYPES > 48 = BlobType.getAvailable().toArray(new BlobType[0]); > > > It?s 2015 (soon); we really don?t have to stay under 80 characters. > > Otherwise this looks good. > >> On Dec 19, 2014, at 2:53 AM, Pavel Chistyakov >> > wrote: >> >> Hi Christian, >> >> Yes, here is updated version: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >> Could you please take a look into it? >> >> -------- >> Thanks, >> Pavel >> >> ----- Original Message ----- >> From: christian.thalinger at oracle.com >> >> To: igor.ignatyev at oracle.com >> Cc: pavel.chistyakov at oracle.com , >> hotspot-compiler-dev at openjdk.java.net >> >> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >> >> >>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >> > wrote: >>> >>> Pavel, >>> >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>> >>> >>>> 45 CLASS_DATA = loadClassData(TestCaseImpl.class.getName()); >>>> 95 String className = TestCaseImpl.class.getName(); >>> >>> these lines will load 'TestCaseImpl' class via default class loader, >>> could you try to avoid it? >> >> Any update on that? >> >>> >>> Igor >>> >>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>> Hi, >>>> >>>> please take a look into slightly updated webrev: >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>> >>>> >>>> -------------- >>>> Thanks, >>>> Pavel >>>> >>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>> >>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>> wrote: >>>>>> >>>>>>> David, thank you for review. >>>>>>> Here is updated webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>> >>>>>> >>>>>> That is excellent -- now we just need a real reviewer. >>>>>> >>>>>> David >>>>>> >>>> >> > From christian.thalinger at oracle.com Mon Dec 22 22:52:16 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 22 Dec 2014 14:52:16 -0800 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <54989BBB.5080006@oracle.com> References: <84D42F52-6D9E-46AF-96BA-3DA5F4567323@oracle.com> <54989BBB.5080006@oracle.com> Message-ID: <0B354BFC-AF49-47DC-A207-8B34D2380EB5@oracle.com> > On Dec 22, 2014, at 2:31 PM, Igor Ignatyev wrote: > > Chris, > >>> It?s 2015 (soon); we really don?t have to stay under 80 characters. > I'll argue about 80 characters limitation. we do have to at least try to stay under 80, because there are 2 buffer diff-view, and it's literally impossible to use it in case of more than 80 characters, even now in 2015. I recall the review there it looked like nothing was changed, because length of line was longer than my monitor can include, and I spent some time trying to figured out why the file was shown as modified. > > so I'd prefer to have good old 80 characters. http://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_formats_and_character_codes > > Igor > > On 12/23/2014 01:13 AM, Christian Thalinger wrote: >> Can we keep these on the same line? >> >> 44 public class OverloadCompileQueueTest implements Runnable { >> >> 49 private static final boolean INTERPRETED >> 50 = System.getProperty("java.vm.info").startsWith("interpreted "); >> 51 private static final boolean TIERED_COMPILATION >> 52 = Helper.WHITE_BOX.getBooleanVMFlag("TieredCompilation"); >> 53 private static final int TIERED_STOP_AT_LEVEL >> 54 = Helper.WHITE_BOX.getIntxVMFlag("TieredStopAtLevel").intValue(); >> >> >> 43 public class RandomAllocationTest implements Runnable { >> 44 private static final long CODE_CACHE_SIZE >> 45 = Helper.WHITE_BOX.getUintxVMFlag("ReservedCodeCacheSize"); >> 46 private static final int MAX_BLOB_SIZE = (int) (CODE_CACHE_SIZE >> 7); >> 47 private static final BlobType[] BLOB_TYPES >> 48 = BlobType.getAvailable().toArray(new BlobType[0]); >> >> >> It?s 2015 (soon); we really don?t have to stay under 80 characters. >> >> Otherwise this looks good. >> >>> On Dec 19, 2014, at 2:53 AM, Pavel Chistyakov >>> >> wrote: >>> >>> Hi Christian, >>> >>> Yes, here is updated version: >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >>> Could you please take a look into it? >>> >>> -------- >>> Thanks, >>> Pavel >>> >>> ----- Original Message ----- >>> From: christian.thalinger at oracle.com >>> > >>> To: igor.ignatyev at oracle.com > >>> Cc: pavel.chistyakov at oracle.com >, >>> hotspot-compiler-dev at openjdk.java.net >>> > >>> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >>> >>> >>>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >>>> >> wrote: >>>> >>>> Pavel, >>>> >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>>> >>>> >>>>> 45 CLASS_DATA = loadClassData(TestCaseImpl.class.getName()); >>>>> 95 String className = TestCaseImpl.class.getName(); >>>> >>>> these lines will load 'TestCaseImpl' class via default class loader, >>>> could you try to avoid it? >>> >>> Any update on that? >>> >>>> >>>> Igor >>>> >>>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>>> Hi, >>>>> >>>>> please take a look into slightly updated webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>>> >>>>> >>>>> -------------- >>>>> Thanks, >>>>> Pavel >>>>> >>>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>>> Looks fine. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>>> >>>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>>> wrote: >>>>>>> >>>>>>>> David, thank you for review. >>>>>>>> Here is updated webrev: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>>> >>>>>>> >>>>>>> That is excellent -- now we just need a real reviewer. >>>>>>> >>>>>>> David -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Mon Dec 22 23:09:01 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 22 Dec 2014 15:09:01 -0800 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <39B2F20F-B0AE-49CA-9A7D-E67276E248BD@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> <543833F6.5050002@oracle.com> <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> <025487DA-04CA-49BB-885C-39446D0C9BF7@oracle.com> <544F67A4.3060801@oracle.com> <02C11976-5D45-40F7-A852-5BBA274CA963@oracle.com> <39B2F20F-B0AE-49CA-9A7D-E67276E248BD@oracle.com> Message-ID: Looks good to me. igor > On Dec 16, 2014, at 8:50 AM, Roland Westrelin wrote: > > I?ve added some test cases for this change: > > http://cr.openjdk.java.net/~roland/6700100/webrev.02/ > > I still need a second review. > > Roland. From igor.ignatyev at oracle.com Mon Dec 22 23:16:43 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 23 Dec 2014 02:16:43 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <0B354BFC-AF49-47DC-A207-8B34D2380EB5@oracle.com> References: <84D42F52-6D9E-46AF-96BA-3DA5F4567323@oracle.com> <54989BBB.5080006@oracle.com> <0B354BFC-AF49-47DC-A207-8B34D2380EB5@oracle.com> Message-ID: <5498A65B.3040300@oracle.com> are you trying to say that it's too old ? ) I also have a link to some not old document which still enjoins to use 80 characters: http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-136091.html#313 // please ignore red text above Igor On 12/23/2014 01:52 AM, Christian Thalinger wrote: > >> On Dec 22, 2014, at 2:31 PM, Igor Ignatyev > > wrote: >> >> Chris, >> >>>> It?s 2015 (soon); we really don?t have to stay under 80 characters. >> I'll argue about 80 characters limitation. we do have to at least try >> to stay under 80, because there are 2 buffer diff-view, and it's >> literally impossible to use it in case of more than 80 characters, >> even now in 2015. I recall the review there it looked like nothing was >> changed, because length of line was longer than my monitor can >> include, and I spent some time trying to figured out why the file was >> shown as modified. >> >> so I'd prefer to have good old 80 characters. > > http://en.wikipedia.org/wiki/Punched_card#IBM_80-column_punched_card_formats_and_character_codes > >> >> Igor >> >> On 12/23/2014 01:13 AM, Christian Thalinger wrote: >>> Can we keep these on the same line? >>> >>> 44 public class OverloadCompileQueueTest implements Runnable { >>> >>> 49 private static final boolean INTERPRETED >>> 50 = >>> System.getProperty("java.vm.info").startsWith("interpreted "); >>> 51 private static final boolean TIERED_COMPILATION >>> 52 = >>> Helper.WHITE_BOX.getBooleanVMFlag("TieredCompilation"); >>> 53 private static final int TIERED_STOP_AT_LEVEL >>> 54 = >>> Helper.WHITE_BOX.getIntxVMFlag("TieredStopAtLevel").intValue(); >>> >>> >>> 43 public class RandomAllocationTest implements Runnable { >>> 44 private static final long CODE_CACHE_SIZE >>> 45 = >>> Helper.WHITE_BOX.getUintxVMFlag("ReservedCodeCacheSize"); >>> 46 private static final int MAX_BLOB_SIZE = (int) >>> (CODE_CACHE_SIZE >> 7); >>> 47 private static final BlobType[] BLOB_TYPES >>> 48 = BlobType.getAvailable().toArray(new BlobType[0]); >>> >>> >>> It?s 2015 (soon); we really don?t have to stay under 80 characters. >>> >>> Otherwise this looks good. >>> >>>> On Dec 19, 2014, at 2:53 AM, Pavel Chistyakov >>>> >>> > >>>> wrote: >>>> >>>> Hi Christian, >>>> >>>> Yes, here is updated version: >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >>>> Could you please take a look into it? >>>> >>>> -------- >>>> Thanks, >>>> Pavel >>>> >>>> ----- Original Message ----- >>>> From:christian.thalinger at oracle.com >>>> >>>> >>>> To:igor.ignatyev at oracle.com >>>> >>>> Cc:pavel.chistyakov at oracle.com >>>> , >>>> hotspot-compiler-dev at openjdk.java.net >>>> >>>> >>>> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >>>> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >>>> >>>> >>>>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >>>>> >>>>> > wrote: >>>>> >>>>> Pavel, >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>>>> >>>>> >>>>>> 45 CLASS_DATA = >>>>>> loadClassData(TestCaseImpl.class.getName()); >>>>>> 95 String className = TestCaseImpl.class.getName(); >>>>> >>>>> these lines will load 'TestCaseImpl' class via default class loader, >>>>> could you try to avoid it? >>>> >>>> Any update on that? >>>> >>>>> >>>>> Igor >>>>> >>>>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>>>> Hi, >>>>>> >>>>>> please take a look into slightly updated webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>>>> >>>>>> >>>>>> -------------- >>>>>> Thanks, >>>>>> Pavel >>>>>> >>>>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>>>> Looks fine. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>>>> >>>>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> David, thank you for review. >>>>>>>>> Here is updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>>>> >>>>>>>> >>>>>>>> That is excellent -- now we just need a real reviewer. >>>>>>>> >>>>>>>> David > From vladimir.kozlov at oracle.com Tue Dec 23 00:42:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Dec 2014 16:42:37 -0800 Subject: jdk9/hs-comp/ is unlocked In-Reply-To: <549857ED.3020206@oracle.com> References: <549857ED.3020206@oracle.com> Message-ID: <5498BA7D.7070407@oracle.com> Merge is done and hs-comp is open. Thanks, Vladimir On 12/22/14 9:42 AM, Vladimir Kozlov wrote: > We need to do manual merge with additional bugs fixing because of > conflicting changes in tests caused by "8066433: Move Whitebox test > library to top level repository" > > I will let you know when we finish merge. > > Regards, > Vladimir > > From serguei.spitsyn at oracle.com Tue Dec 23 07:27:30 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Dec 2014 23:27:30 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54947677.7050104@oracle.com> References: <54947677.7050104@oracle.com> Message-ID: <54991962.7020806@oracle.com> Hi Dmitry, It looks good in general. Some minor comments are below. test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE 60 private static final String WORKER_CLASS_NAME 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); ... 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, The WORKER_CLASS_NAME can be used at 81. 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() ... 179 List tml 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; ... 235 List mlist 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; The TESTED_METHODS_LIST is used three times. It can be cached at the top and re-used. Thanks, Serguei On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: > Hi all, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: > Test task: DTrace- tests for segmented codecache feature > > Description: this fix introduce dtrace test, which verify that > different combinations of available compile levels(and, in case > compile levels allows it, different code heaps as result) doesn't > affect callstack shown by dtrace. There is a control class > SegmentedCodeCacheDtraceTest.java and class for running via dtrace > SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also > present (SegmentedCodeCacheDtraceTestScript.d). A control class is > using DtraceRunner.java to run dtrace and then analyzing results using > class SegmentedCodeCacheDtraceResultsAnalyzer with > DtraceResultsAnalyzer interface. > There is also a small class CompilerUtils.java created for usefull > common code. > > webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ > > Additional note: Please note that this path assumes that fix for > JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also > applied. > > Thanks, > Dmitrij -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Tue Dec 23 07:37:35 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 23 Dec 2014 11:37:35 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> Message-ID: <54991BBF.2000704@oracle.com> Thank you, Christian! Regards, Filipp. On 12/22/2014 09:01 PM, Christian Thalinger wrote: > Yes, looks good. > >> On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin wrote: >> >> Christian, are you ok with the latest fix version? >> >> Thanks, >> Filipp. >> >> On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: >>> Christian, thank you for review! >>> >>> I've updated tests to reflect WhiteBox movement to top-level repo, >>> added previously missed @bug tag and fixed few small issues: >>> >>> incremental diff: >>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ >>> >>> updated webrev: >>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ >>> >>> Thanks, >>> Filipp. >>> >>> On 12/19/2014 02:19 AM, Christian Thalinger wrote: >>>> Looks good. >>>> >>>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann wrote: >>>>> >>>>> Hi Filipp, >>>>> >>>>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>>>> Tobias, >>>>>> >>>>>> as I wrote you in a private message, until a fix for 8064940 doesn't affect >>>>>> the way options are processed there is no need to update proposed tests. >>>>>> >>>>>> I've filed 8067135 for new tests that will verify actual alignment of code heaps. >>>>> Okay, sounds good. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> Regards, >>>>>> Filipp. >>>>>> >>>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>>>> Hi Tobias, >>>>>>>>> >>>>>>>>> thank you for suggestion. >>>>>>>>> >>>>>>>>> Yes, I think we should take code heap size alignment into account. >>>>>>>>> >>>>>>>>> What alignment policy you're going to implement for 8064940? >>>>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>>>> >>>>>>>>> Maybe instead of checking that values are in >>>>>>>>> (value - page_size, value + page_size) interval we should just check >>>>>>>>> that all values were aligned up to page_size? >>>>>>>> Yes, that's a better solution. However, I don't know how to figure out the >>>>>>>> available page sizes from Java code. >>>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>>>> about to add such method to WB API, but it need to check how well >>>>>>> it is going to work with large pages. >>>>>>> >>>>>>> Thanks, >>>>>>> Filipp. >>>>>>>> Best, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Filipp. >>>>>>>>> >>>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>>>> Hi Filipp, >>>>>>>>>> >>>>>>>>>> the actual size of a code heap is affected by alignment and therefore may be >>>>>>>>>> different to the size set via the command line. For example, on Sparc we >>>>>>>>>> have to >>>>>>>>>> make sure that the code heaps are large page (4MB) aligned to reduce the >>>>>>>>>> number >>>>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>>>> >>>>>>>>>> Maybe we should check if the actual size of the code heap is within >>>>>>>>>> boundaries, >>>>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>>>> >>>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please take a look at CLI tests for segmented code cache (JDK-8059623). >>>>>>>>>>> >>>>>>>>>>> There are three new tests: >>>>>>>>>>> compiler/codecache/cli/ >>>>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>>>> >>>>>>>>>>> All tests consist of several test cases aimed to verify different aspects >>>>>>>>>>> of options' processing. >>>>>>>>>>> >>>>>>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache test, >>>>>>>>>>> but add additional value - these tests actually check final values >>>>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>>>> >>>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>>>> Testing: manual & automated >>>>>>>>>>> >>>>>>>>>>> This change depends on: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve compiler's CLI >>>>>>>>>>> tests >>>>>>>>>>> error reporting >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>>>>>> testlibrary >>>>>>>>>>> for JDK-8059613 >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Filipp. From dmitrij.pochepko at oracle.com Tue Dec 23 08:36:10 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 11:36:10 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: References: <54947677.7050104@oracle.com> Message-ID: <5499297A.2070402@oracle.com> Looks like that. Will fix. Thank you. Dmitrij > 40 public static int[] getAvailableCompilationLevels() { > 41 if (System.getProperty("java.vm.info").startsWith("interpreted ")) { > 42 return new int[0]; > 43 } > > Wouldn?t it be better to check the UseCompiler flag instead? > >> On Dec 19, 2014, at 11:03 AM, Dmitrij Pochepko >> > wrote: >> >> Hi all, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: >> Test task: DTrace- tests for segmented codecache feature >> >> Description: this fix introduce dtrace test, which verify that >> different combinations of available compile levels(and, in case >> compile levels allows it, different code heaps as result) doesn't >> affect callstack shown by dtrace. There is a control class >> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >> using DtraceRunner.java to run dtrace and then analyzing results >> using class SegmentedCodeCacheDtraceResultsAnalyzer with >> DtraceResultsAnalyzer interface. >> There is also a small class CompilerUtils.java created for usefull >> common code. >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >> >> >> Additional note: Please note that this path assumes that fix for >> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also >> applied. >> >> Thanks, >> Dmitrij > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Tue Dec 23 08:37:44 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 11:37:44 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54991962.7020806@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> Message-ID: <549929D8.7050003@oracle.com> Hi, Thank you for catching these issues. I have a question regarding last comment: does it make any difference to change "reading of static member 3 times" to "copying into static member of another class and then read it 3 times"? Thanks, Dmitrij > Hi Dmitry, > > > It looks good in general. > Some minor comments are below. > > test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java > > 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; > A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE > > > test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java > > 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, > A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE > > > 60 private static final String WORKER_CLASS_NAME > 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); > ... > 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, > 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, > The WORKER_CLASS_NAME can be used at 81. > > 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() > ... > 179 List tml > 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > ... > 235 List mlist > 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > The TESTED_METHODS_LIST is used three times. > It can be cached at the top and re-used. > > Thanks, > Serguei > > > > On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >> Hi all, >> >> Please review changes for >> https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: >> Test task: DTrace- tests for segmented codecache feature >> >> Description: this fix introduce dtrace test, which verify that >> different combinations of available compile levels(and, in case >> compile levels allows it, different code heaps as result) doesn't >> affect callstack shown by dtrace. There is a control class >> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >> using DtraceRunner.java to run dtrace and then analyzing results >> using class SegmentedCodeCacheDtraceResultsAnalyzer with >> DtraceResultsAnalyzer interface. >> There is also a small class CompilerUtils.java created for usefull >> common code. >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >> >> Additional note: Please note that this path assumes that fix for >> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also >> applied. >> >> Thanks, >> Dmitrij > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Dec 23 09:10:11 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Dec 2014 01:10:11 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549929D8.7050003@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> Message-ID: <54993173.6030003@oracle.com> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: > Hi, > > Thank you for catching these issues. > I have a question regarding last comment: does it make any difference > to change "reading of static member 3 times" to "copying into static > member of another class and then read it 3 times"? Yes, it does (it is a minor issue though). It is because the class names are pretty big. It would simplify the code and improve readability, right? You already do it two times: 179 List tml 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; ... 235 List mlist 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; My suggestion is to do it once somewhere before the line 74: static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; and then use the mlist in other places where it is needed: 75 String params = MLIST.stream() ... 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), ... 239 for (int i = MLIST.size() - 1; i > -1; i--) { 240 sb.append(MLIST.get(i).getName()).append(delimeter); These lines will go away: 179 List tml 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; ... 235 List mlist 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; Both private static classes are inner classes of the public one. The MLIST will be in a context for the inner classes, and so, needs no prefixing. Thanks, Serguei > > Thanks, > Dmitrij >> Hi Dmitry, >> >> >> It looks good in general. >> Some minor comments are below. >> >> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >> >> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >> >> >> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >> >> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >> >> >> 60 private static final String WORKER_CLASS_NAME >> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >> ... >> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >> The WORKER_CLASS_NAME can be used at 81. >> >> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >> ... >> 179 List tml >> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> ... >> 235 List mlist >> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> The TESTED_METHODS_LIST is used three times. >> It can be cached at the top and re-used. >> >> Thanks, >> Serguei >> >> >> >> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> Please review changes for >>> https://bugs.openjdk.java.net/browse/JDK-8059625 - JEP-JDK-8043304: >>> Test task: DTrace- tests for segmented codecache feature >>> >>> Description: this fix introduce dtrace test, which verify that >>> different combinations of available compile levels(and, in case >>> compile levels allows it, different code heaps as result) doesn't >>> affect callstack shown by dtrace. There is a control class >>> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >>> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >>> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >>> using DtraceRunner.java to run dtrace and then analyzing results >>> using class SegmentedCodeCacheDtraceResultsAnalyzer with >>> DtraceResultsAnalyzer interface. >>> There is also a small class CompilerUtils.java created for usefull >>> common code. >>> >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>> >>> Additional note: Please note that this path assumes that fix for >>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is also >>> applied. >>> >>> Thanks, >>> Dmitrij >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Tue Dec 23 09:11:49 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 23 Dec 2014 13:11:49 +0400 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <548ED9DE.4040701@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> <548B6EA0.1010802@oracle.com> <548ECBB8.7010008@oracle.com> <548ED9DE.4040701@oracle.com> Message-ID: <549931D5.5040606@oracle.com> Hi Dmitrij, following change in BlobType: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 should be pushed as part of the fix for 8066440, right? Thanks, Filipp. On 12/15/2014 04:53 PM, Dmitrij Pochepko wrote: > Hi, > see comments below >> Hi Dmitrij, >> >> For PeakUsageTest I'm still worried that the asserts may fail if class loading >> happens in between and triggers compilation of adapters. > non-nmethods heap is excluded from > testing(CodeCacheUtils.isCodeHeapPredictable is used to filter out heaps > because of this exact reason). >> >> Why did you surround two of the asserts with a try? Like this the assert is >> useless because we ignore failures. > there is no catch block there - it's just finally block to be sure we've > cleaned up memory allocated before, > since assertion can get us out without deallocating memory otherwise. > > Thanks, > Dmitrij >> >> Otherwise it looks good. >> >> Best, >> Tobias >> >> On 12.12.2014 23:39, Dmitrij Pochepko wrote: >>> Hi all, >>> >>> i've corrected diff according to comments. >>> >>> please see corrected version(also modified according to latest commits) >>> >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 >>> >>> a jprt testing job has been created: >>> http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp >>> >>> >>> Thanks, >>> Dmitrij >>>> Hi Dmitrij, >>>> >>>> here are some comments about the tests (not a reviewer). >>>> >>>> UsageThresholdNotExceededTest: >>>> - You can use CodeCacheUtils.MIN_ALLOCATION instead of >>>> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. >>>> - Please add a comment to 'CodeCacheUtils.WB.fullGC()' >>>> >>>> UsageThresholdIncreasedTest: >>>> - Typo "hasn't been hit after allocationg smaller" -> "allocating" >>>> - Maybe you should disable code cache sweeping here as well (as you did for >>>> the >>>> UsageThresholdNotExceededTest) >>>> >>>> UsageThresholdExceededTest: >>>> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold >>>> if the code cache sweeper is enabled and removes nmethods in between. I think >>>> you should disable code cache sweeping. >>>> - Please print information about the counters if the assert is hit in line 66. >>>> >>>> ThresholdNotificationsTest: >>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>> - If not all notifications are received/handled, the test will timeout at line >>>> 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and >>>> print a useful error message if the timeout is reached. >>>> >>>> PoolsIndependenceTest: >>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>> - Typos "event to be recieved ..." -> "received" (3x) >>>> >>>> PeakUsageTest: >>>> - Compilation is not disabled. The asserts may fail because a method is >>>> compiled >>>> in between. Even with compilation disabled, adapters and other non-nmethod >>>> code >>>> may be generated and stored in the non-nmethod code heap. >>>> >>>> ManagerNamesTest: >>>> - Typo: "calls in case on segmented code cache" -> "of segmented" >>>> >>>> GetUsageTest: >>>> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? >>>> >>>> General: >>>> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it >>>> would be easier to understand if you invoke WB.allocateCodeBlob(...) directly. >>>> >>>> Please run the tests on JPRT! >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 04.12.2014 20:13, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> Please review changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test >>>>> task: >>>>> JMX- tests >>>>> and >>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in >>>>> testlibrary for JDK-8059613 >>>>> >>>>> It introduce a number of tests for segmented code cache, mostly testing >>>>> thresholds, usage, >>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>> There is also a small modification for testlibrary(8066440) used in tests. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>> >>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>> >>>>> Additional note: this patch assumes >>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is >>>>> fixed. >>>>> >>>>> Thanks, >>>>> Dmitrij > From roland.westrelin at oracle.com Tue Dec 23 09:27:32 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 23 Dec 2014 10:27:32 +0100 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> <543833F6.5050002@oracle.com> <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> <025487DA-04CA-49BB-885C-39446D0C9BF7@oracle.com> <544F67A4.3060801@oracle.com> <02C11976-5D45-40F7-A852-5BBA274CA963@oracle.com> <39B2F20F-B0AE-49CA-9A7D-E67276E248BD@oracle.com> Message-ID: Thanks for the review, Igor. Roland. > On Dec 23, 2014, at 12:09 AM, Igor Veresov wrote: > > Looks good to me. > > igor > >> On Dec 16, 2014, at 8:50 AM, Roland Westrelin wrote: >> >> I?ve added some test cases for this change: >> >> http://cr.openjdk.java.net/~roland/6700100/webrev.02/ >> >> I still need a second review. >> >> Roland. > From goetz.lindenmaier at sap.com Tue Dec 23 11:26:46 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 23 Dec 2014 11:26:46 +0000 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <54991BBF.2000704@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44EEA@DEWDFEMB12A.global.corp.sap> Hi Filipp, Thanks for pointing me at 8059613. With that I could run the tests. The ppc64 VM does not implement TieredCompilation, thus the tests fail. Could you please apply something as the patch below? Thanks, Goetz diff -r c79a7b921a03 test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java --- a/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 +++ b/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 @@ -170,6 +171,18 @@ } public static void main(String args[]) throws Throwable { + + // Check whether VM supports tiered compilation. + try { + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag(TIERED_COMPILATION, true), + null, + new String[]{ "TieredCompilation is disabled in this release." }, + "", "", ExitCode.OK); + } catch (Throwable e) { + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); + return; + } + for (TestCase testCase : TestCase.values()) { if (testCase.isApplicable()) { System.out.println("Running test case: " + testCase.name()); diff -r c79a7b921a03 test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java --- a/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Sat Dec 13 00:54:22 2014 +0300 +++ b/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Tue Dec 23 12:17:26 2014 +0100 @@ -22,7 +22,9 @@ */ package codeheapsize; +import com.oracle.java.testlibrary.ExitCode; import com.oracle.java.testlibrary.Platform; +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; import common.CodeCacheCLITestBase; import common.CodeCacheCLITestCase; import sun.hotspot.code.BlobType; @@ -75,6 +77,18 @@ } public static void main(String args[]) throws Throwable { + + // Check whether VM supports tiered compilation. + try { + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), + null, + new String[]{ "TieredCompilation is disabled in this release." }, + "", "", ExitCode.OK); + } catch (Throwable e) { + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); + return; + } + new TestCodeHeapSizeOptions().runTestCases(); } } diff -r c79a7b921a03 test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java --- a/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 +++ b/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 @@ -22,6 +22,8 @@ */ package printcodecache; +import com.oracle.java.testlibrary.ExitCode; +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; import common.CodeCacheCLITestBase; import common.CodeCacheCLITestCase; import sun.hotspot.code.BlobType; @@ -68,6 +70,17 @@ } public static void main(String args[]) throws Throwable { + + // Check whether VM supports tiered compilation. + try { + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), + null, + new String[]{ "TieredCompilation is disabled in this release." }, + "", "", ExitCode.OK); + } catch (Throwable e) { + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); + return; + } new TestPrintCodeCacheOption().runTestCases(); } } From dmitrij.pochepko at oracle.com Tue Dec 23 11:35:33 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 14:35:33 +0300 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <549931D5.5040606@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> <548B6EA0.1010802@oracle.com> <548ECBB8.7010008@oracle.com> <548ED9DE.4040701@oracle.com> <549931D5.5040606@oracle.com> Message-ID: <54995385.4060708@oracle.com> Hi, yes, correct. Thanks, Dmtirij > Hi Dmitrij, > > following change in BlobType: > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 > > should be pushed as part of the fix for 8066440, right? > > Thanks, > Filipp. > > On 12/15/2014 04:53 PM, Dmitrij Pochepko wrote: >> Hi, >> see comments below >>> Hi Dmitrij, >>> >>> For PeakUsageTest I'm still worried that the asserts may fail if >>> class loading >>> happens in between and triggers compilation of adapters. >> non-nmethods heap is excluded from >> testing(CodeCacheUtils.isCodeHeapPredictable is used to filter out >> heaps because of this exact reason). >>> >>> Why did you surround two of the asserts with a try? Like this the >>> assert is >>> useless because we ignore failures. >> there is no catch block there - it's just finally block to be sure >> we've cleaned up memory allocated before, >> since assertion can get us out without deallocating memory otherwise. >> >> Thanks, >> Dmitrij >>> >>> Otherwise it looks good. >>> >>> Best, >>> Tobias >>> >>> On 12.12.2014 23:39, Dmitrij Pochepko wrote: >>>> Hi all, >>>> >>>> i've corrected diff according to comments. >>>> >>>> please see corrected version(also modified according to latest >>>> commits) >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 >>>> >>>> a jprt testing job has been created: >>>> http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp >>>> >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi Dmitrij, >>>>> >>>>> here are some comments about the tests (not a reviewer). >>>>> >>>>> UsageThresholdNotExceededTest: >>>>> - You can use CodeCacheUtils.MIN_ALLOCATION instead of >>>>> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. >>>>> - Please add a comment to 'CodeCacheUtils.WB.fullGC()' >>>>> >>>>> UsageThresholdIncreasedTest: >>>>> - Typo "hasn't been hit after allocationg smaller" -> "allocating" >>>>> - Maybe you should disable code cache sweeping here as well (as >>>>> you did for the >>>>> UsageThresholdNotExceededTest) >>>>> >>>>> UsageThresholdExceededTest: >>>>> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the >>>>> usage threshold >>>>> if the code cache sweeper is enabled and removes nmethods in >>>>> between. I think >>>>> you should disable code cache sweeping. >>>>> - Please print information about the counters if the assert is hit >>>>> in line 66. >>>>> >>>>> ThresholdNotificationsTest: >>>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>>> - If not all notifications are received/handled, the test will >>>>> timeout at line >>>>> 87, right? Maybe you can add a timeout value to >>>>> 'Utils.waitForCondition' and >>>>> print a useful error message if the timeout is reached. >>>>> >>>>> PoolsIndependenceTest: >>>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>>> - Typos "event to be recieved ..." -> "received" (3x) >>>>> >>>>> PeakUsageTest: >>>>> - Compilation is not disabled. The asserts may fail because a >>>>> method is compiled >>>>> in between. Even with compilation disabled, adapters and other >>>>> non-nmethod code >>>>> may be generated and stored in the non-nmethod code heap. >>>>> >>>>> ManagerNamesTest: >>>>> - Typo: "calls in case on segmented code cache" -> "of segmented" >>>>> >>>>> GetUsageTest: >>>>> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? >>>>> >>>>> General: >>>>> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In >>>>> my opinion it >>>>> would be easier to understand if you invoke >>>>> WB.allocateCodeBlob(...) directly. >>>>> >>>>> Please run the tests on JPRT! >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 04.12.2014 20:13, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> Please review changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - >>>>>> JEP-JDK-8043304: Test task: >>>>>> JMX- tests >>>>>> and >>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various >>>>>> changes in >>>>>> testlibrary for JDK-8059613 >>>>>> >>>>>> It introduce a number of tests for segmented code cache, mostly >>>>>> testing >>>>>> thresholds, usage, >>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>> There is also a small modification for testlibrary(8066440) used >>>>>> in tests. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>> >>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>> >>>>>> Additional note: this patch assumes >>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be >>>>>> implemented" is fixed. >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >> > From dmitrij.pochepko at oracle.com Tue Dec 23 11:36:30 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 14:36:30 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54993173.6030003@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> Message-ID: <549953BE.50404@oracle.com> Hi, please review updated webrev http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ Thanks, Dmitrij > On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >> Hi, >> >> Thank you for catching these issues. >> I have a question regarding last comment: does it make any difference >> to change "reading of static member 3 times" to "copying into static >> member of another class and then read it 3 times"? > > Yes, it does (it is a minor issue though). > It is because the class names are pretty big. > It would simplify the code and improve readability, right? > > You already do it two times: > 179 List tml > 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > ... > 235 List mlist > 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > > My suggestion is to do it once somewhere before the line 74: > static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > and then use the mlist in other places where it is needed: > > 75 String params = MLIST.stream() > ... > 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), > ... > 239 for (int i = MLIST.size() - 1; i> -1; i--) { > 240 sb.append(MLIST.get(i).getName()).append(delimeter); > These lines will go away: > 179 List tml > 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > ... > 235 List mlist > 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; > > > Both private static classes are inner classes of the public one. > The MLIST will be in a context for the inner classes, and so, needs no > prefixing. > > > Thanks, > Serguei > >> >> Thanks, >> Dmitrij >>> Hi Dmitry, >>> >>> >>> It looks good in general. >>> Some minor comments are below. >>> >>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>> >>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>> >>> >>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>> >>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>> >>> >>> 60 private static final String WORKER_CLASS_NAME >>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>> ... >>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>> The WORKER_CLASS_NAME can be used at 81. >>> >>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>> ... >>> 179 List tml >>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> ... >>> 235 List mlist >>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> The TESTED_METHODS_LIST is used three times. >>> It can be cached at the top and re-used. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>> Hi all, >>>> >>>> Please review changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache >>>> feature >>>> >>>> Description: this fix introduce dtrace test, which verify that >>>> different combinations of available compile levels(and, in case >>>> compile levels allows it, different code heaps as result) doesn't >>>> affect callstack shown by dtrace. There is a control class >>>> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >>>> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >>>> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >>>> using DtraceRunner.java to run dtrace and then analyzing results >>>> using class SegmentedCodeCacheDtraceResultsAnalyzer with >>>> DtraceResultsAnalyzer interface. >>>> There is also a small class CompilerUtils.java created for usefull >>>> common code. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>> >>>> Additional note: Please note that this path assumes that fix for >>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>> also applied. >>>> >>>> Thanks, >>>> Dmitrij >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Tue Dec 23 11:37:04 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 23 Dec 2014 15:37:04 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF44EEA@DEWDFEMB12A.global.corp.sap> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44EEA@DEWDFEMB12A.global.corp.sap> Message-ID: <549953E0.9070209@oracle.com> Thank you for pointing me to this issue. Each test consist of several test cases and for test cases that require TieredCompilation I've only checked that current VM is server one. Apparently it's not enough, so I'll update tests to check that VM is server and TieredCompilation is available. Thanks, Filipp. On 12/23/2014 03:26 PM, Lindenmaier, Goetz wrote: > Hi Filipp, > > Thanks for pointing me at 8059613. With that I could run the tests. > > The ppc64 VM does not implement TieredCompilation, thus the tests fail. > Could you please apply something as the patch below? > > Thanks, > Goetz > > > diff -r c79a7b921a03 test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java > --- a/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 > +++ b/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 > @@ -170,6 +171,18 @@ > } > > public static void main(String args[]) throws Throwable { > + > + // Check whether VM supports tiered compilation. > + try { > + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag(TIERED_COMPILATION, true), > + null, > + new String[]{ "TieredCompilation is disabled in this release." }, > + "", "", ExitCode.OK); > + } catch (Throwable e) { > + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); > + return; > + } > + > for (TestCase testCase : TestCase.values()) { > if (testCase.isApplicable()) { > System.out.println("Running test case: " + testCase.name()); > diff -r c79a7b921a03 test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java > --- a/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Sat Dec 13 00:54:22 2014 +0300 > +++ b/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Tue Dec 23 12:17:26 2014 +0100 > @@ -22,7 +22,9 @@ > */ > package codeheapsize; > > +import com.oracle.java.testlibrary.ExitCode; > import com.oracle.java.testlibrary.Platform; > +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; > import common.CodeCacheCLITestBase; > import common.CodeCacheCLITestCase; > import sun.hotspot.code.BlobType; > @@ -75,6 +77,18 @@ > } > > public static void main(String args[]) throws Throwable { > + > + // Check whether VM supports tiered compilation. > + try { > + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), > + null, > + new String[]{ "TieredCompilation is disabled in this release." }, > + "", "", ExitCode.OK); > + } catch (Throwable e) { > + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); > + return; > + } > + > new TestCodeHeapSizeOptions().runTestCases(); > } > } > diff -r c79a7b921a03 test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java > --- a/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 > +++ b/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 > @@ -22,6 +22,8 @@ > */ > package printcodecache; > > +import com.oracle.java.testlibrary.ExitCode; > +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; > import common.CodeCacheCLITestBase; > import common.CodeCacheCLITestCase; > import sun.hotspot.code.BlobType; > @@ -68,6 +70,17 @@ > } > > public static void main(String args[]) throws Throwable { > + > + // Check whether VM supports tiered compilation. > + try { > + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), > + null, > + new String[]{ "TieredCompilation is disabled in this release." }, > + "", "", ExitCode.OK); > + } catch (Throwable e) { > + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); > + return; > + } > new TestPrintCodeCacheOption().runTestCases(); > } > } From serguei.spitsyn at oracle.com Tue Dec 23 11:46:51 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Dec 2014 03:46:51 -0800 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549953BE.50404@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> Message-ID: <5499562B.5020008@oracle.com> Hi Dmitrij, There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, Otherwise, looks good. Please, consider it reviewed (no need to re-review). Thanks, Serguei On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: > Hi, > please review updated webrev > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ > > Thanks, > Dmitrij >> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> Thank you for catching these issues. >>> I have a question regarding last comment: does it make any >>> difference to change "reading of static member 3 times" to "copying >>> into static member of another class and then read it 3 times"? >> >> Yes, it does (it is a minor issue though). >> It is because the class names are pretty big. >> It would simplify the code and improve readability, right? >> >> You already do it two times: >> 179 List tml >> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> ... >> 235 List mlist >> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> >> My suggestion is to do it once somewhere before the line 74: >> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> and then use the mlist in other places where it is needed: >> >> 75 String params = MLIST.stream() >> ... >> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >> ... >> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >> These lines will go away: >> 179 List tml >> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> ... >> 235 List mlist >> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >> >> >> Both private static classes are inner classes of the public one. >> The MLIST will be in a context for the inner classes, and so, needs >> no prefixing. >> >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> Dmitrij >>>> Hi Dmitry, >>>> >>>> >>>> It looks good in general. >>>> Some minor comments are below. >>>> >>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>> >>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>> >>>> >>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>> >>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>> >>>> >>>> 60 private static final String WORKER_CLASS_NAME >>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>> ... >>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>> The WORKER_CLASS_NAME can be used at 81. >>>> >>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>> ... >>>> 179 List tml >>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> ... >>>> 235 List mlist >>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> The TESTED_METHODS_LIST is used three times. >>>> It can be cached at the top and re-used. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>> Hi all, >>>>> >>>>> Please review changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache >>>>> feature >>>>> >>>>> Description: this fix introduce dtrace test, which verify that >>>>> different combinations of available compile levels(and, in case >>>>> compile levels allows it, different code heaps as result) doesn't >>>>> affect callstack shown by dtrace. There is a control class >>>>> SegmentedCodeCacheDtraceTest.java and class for running via dtrace >>>>> SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script is also >>>>> present (SegmentedCodeCacheDtraceTestScript.d). A control class is >>>>> using DtraceRunner.java to run dtrace and then analyzing results >>>>> using class SegmentedCodeCacheDtraceResultsAnalyzer with >>>>> DtraceResultsAnalyzer interface. >>>>> There is also a small class CompilerUtils.java created for usefull >>>>> common code. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>> >>>>> Additional note: Please note that this path assumes that fix for >>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>> also applied. >>>>> >>>>> Thanks, >>>>> Dmitrij >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Dec 23 11:59:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Dec 2014 21:59:06 +1000 Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class In-Reply-To: References: Message-ID: <5499590A.9040300@oracle.com> On 19/12/2014 3:51 PM, Pavel Chistyakov wrote: > Hi David, > > In case of ByteCodeLoader we'd prefer to load class w/ given name and exact given bytecode. Even if parent loader can load class w/ such name, in general this class can have different bytecode. To prevent this situation we break delegation for our class name. > > Also, if we want to use parent loader we can get its instance and load class using it directly. I don't quite understand why this needs to be done this way so I'm backing out of it - neither reviewing nor opposing. David ----- > ----------- > Thanks, > Pavel > > > ----- Original Message ----- > From: david.holmes at oracle.com > To: vladimir.kozlov at oracle.com, hotspot-dev at openjdk.java.net > Cc: pavel.chistyakov at oracle.com > Sent: Friday, December 12, 2014 2:13:03 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class > > On 12/12/2014 8:04 AM, Vladimir Kozlov wrote: >> Pavel, >> >> I am resending it to whole hotspot so you can get more help/explanations. >> >> Thanks, >> Vladimir >> >> On 12/10/14 4:03 AM, Pavel Chistyakov wrote: >>> Hi David, >>> >>> Thanks for review. >>> >>> The intent was: >>> >>> * be able to get */new/* instance of Class w/ given name and given >>> bytecode for every /*new*/ instance of >>> ByteCodeLoader even if this class was already loaded by parent >>> loader. For this reason, I overrided loadClass to >>> break delegation to parent loader for given className; > > I question why the parent should be able to load the class that is being > "redefined"? If it can't, then breaking delegation is not necessary. If > it can and you break delegation then you may be able to load the other > variants of the class in new classloader instances, but depending on > what you then do with the class you may get loader constraint violations. > > David H. > >>> * make single class definition for ByteCodeLoader instance. Here >>> holder field appears and DCL for it's thread safe >>> initialization. >>> >>> >>> ------------- >>> Pavel >>> >>> On 09.12.2014 23:49, David Chase wrote: >>>> I agree with your changes to loadClass, but I am not sure that this >>>> will allow you to redefine an existing class. My understanding of >>>> how this would work is that it will allow you re-obtain the class >>>> that was already loaded (but not to fail at this). Actually >>>> redefining a class requires use of JVMTI (or so I think). >>>> >>>> Was that your intent? >>>> >>>> David >>>> >>>> >>>> On 2014-12-09, at 11:50 AM, Pavel >>>> Chistyakov wrote: >>>> >>>>> Hi all, >>>>> >>>>> please review changes >>>>> for:https://bugs.openjdk.java.net/browse/JDK-8066497 >>>>> webrev:http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ >>>>> >>>>> >>>>> >>>>> Problem: >>>>> ByteCodeLoader allows one to load class with given name from >>>>> existing bytecode. But if this class is already loaded by e.g. >>>>> system classloader it cannot be redefined using another bytecode >>>>> array because of delegation of loadClass call to parent classloader. >>>>> >>>>> Solution: >>>>> override loadClass to break delegation for given className. >>>>> >>>>> Testing: manual >>>>> >>>>> ------------------- >>>>> Thanks, >>>>> Pavel >>> From filipp.zhinkin at oracle.com Tue Dec 23 12:42:55 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 23 Dec 2014 16:42:55 +0400 Subject: RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613 In-Reply-To: <54995385.4060708@oracle.com> References: <5480B272.3030808@oracle.com> <548AC17F.7020703@oracle.com> <548B6EA0.1010802@oracle.com> <548ECBB8.7010008@oracle.com> <548ED9DE.4040701@oracle.com> <549931D5.5040606@oracle.com> <54995385.4060708@oracle.com> Message-ID: <5499634F.4090304@oracle.com> I've asked because the webrev was uploaded to 8059613/**, so please make sure that it will be pushed along with 8066440. Thanks, Filipp. On 12/23/2014 03:35 PM, Dmitrij Pochepko wrote: > Hi, > yes, correct. > > Thanks, > Dmtirij >> Hi Dmitrij, >> >> following change in BlobType: >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 >> >> should be pushed as part of the fix for 8066440, right? >> >> Thanks, >> Filipp. >> >> On 12/15/2014 04:53 PM, Dmitrij Pochepko wrote: >>> Hi, >>> see comments below >>>> Hi Dmitrij, >>>> >>>> For PeakUsageTest I'm still worried that the asserts may fail if class loading >>>> happens in between and triggers compilation of adapters. >>> non-nmethods heap is excluded from >>> testing(CodeCacheUtils.isCodeHeapPredictable is used to filter out heaps >>> because of this exact reason). >>>> >>>> Why did you surround two of the asserts with a try? Like this the assert is >>>> useless because we ignore failures. >>> there is no catch block there - it's just finally block to be sure we've >>> cleaned up memory allocated before, >>> since assertion can get us out without deallocating memory otherwise. >>> >>> Thanks, >>> Dmitrij >>>> >>>> Otherwise it looks good. >>>> >>>> Best, >>>> Tobias >>>> >>>> On 12.12.2014 23:39, Dmitrij Pochepko wrote: >>>>> Hi all, >>>>> >>>>> i've corrected diff according to comments. >>>>> >>>>> please see corrected version(also modified according to latest commits) >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00 >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03 >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00 >>>>> >>>>> a jprt testing job has been created: >>>>> http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp >>>>> >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> Hi Dmitrij, >>>>>> >>>>>> here are some comments about the tests (not a reviewer). >>>>>> >>>>>> UsageThresholdNotExceededTest: >>>>>> - You can use CodeCacheUtils.MIN_ALLOCATION instead of >>>>>> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH. >>>>>> - Please add a comment to 'CodeCacheUtils.WB.fullGC()' >>>>>> >>>>>> UsageThresholdIncreasedTest: >>>>>> - Typo "hasn't been hit after allocationg smaller" -> "allocating" >>>>>> - Maybe you should disable code cache sweeping here as well (as you did >>>>>> for the >>>>>> UsageThresholdNotExceededTest) >>>>>> >>>>>> UsageThresholdExceededTest: >>>>>> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage >>>>>> threshold >>>>>> if the code cache sweeper is enabled and removes nmethods in between. I >>>>>> think >>>>>> you should disable code cache sweeping. >>>>>> - Please print information about the counters if the assert is hit in >>>>>> line 66. >>>>>> >>>>>> ThresholdNotificationsTest: >>>>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>>>> - If not all notifications are received/handled, the test will timeout at >>>>>> line >>>>>> 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and >>>>>> print a useful error message if the timeout is reached. >>>>>> >>>>>> PoolsIndependenceTest: >>>>>> - Typo "testing of getUsageThreashold()" -> "getUsageThreshold()" >>>>>> - Typos "event to be recieved ..." -> "received" (3x) >>>>>> >>>>>> PeakUsageTest: >>>>>> - Compilation is not disabled. The asserts may fail because a method is >>>>>> compiled >>>>>> in between. Even with compilation disabled, adapters and other >>>>>> non-nmethod code >>>>>> may be generated and stored in the non-nmethod code heap. >>>>>> >>>>>> ManagerNamesTest: >>>>>> - Typo: "calls in case on segmented code cache" -> "of segmented" >>>>>> >>>>>> GetUsageTest: >>>>>> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'? >>>>>> >>>>>> General: >>>>>> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my >>>>>> opinion it >>>>>> would be easier to understand if you invoke WB.allocateCodeBlob(...) >>>>>> directly. >>>>>> >>>>>> Please run the tests on JPRT! >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> On 04.12.2014 20:13, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review changes for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304: Test >>>>>>> task: >>>>>>> JMX- tests >>>>>>> and >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes in >>>>>>> testlibrary for JDK-8059613 >>>>>>> >>>>>>> It introduce a number of tests for segmented code cache, mostly testing >>>>>>> thresholds, usage, >>>>>>> memory notifications using respective MemoryPoolMXBean(s). >>>>>>> There is also a small modification for testlibrary(8066440) used in tests. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/ >>>>>>> >>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02 >>>>>>> >>>>>>> Additional note: this patch assumes >>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 - >>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented" is >>>>>>> fixed. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>> >> > From goetz.lindenmaier at sap.com Tue Dec 23 13:11:39 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 23 Dec 2014 13:11:39 +0000 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <549953E0.9070209@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44EEA@DEWDFEMB12A.global.corp.sap> <549953E0.9070209@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44F44@DEWDFEMB12A.global.corp.sap> Hi Filipp, Maybe there should be Platform.implementsTiered() ? There was a similar problem in 8067823. Does the WhiteBox know about the available compilers somehow? I didn't find anything. Best regards, Goetz. -----Original Message----- From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com] Sent: Dienstag, 23. Dezember 2014 12:37 To: Lindenmaier, Goetz; Christian Thalinger Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests Thank you for pointing me to this issue. Each test consist of several test cases and for test cases that require TieredCompilation I've only checked that current VM is server one. Apparently it's not enough, so I'll update tests to check that VM is server and TieredCompilation is available. Thanks, Filipp. On 12/23/2014 03:26 PM, Lindenmaier, Goetz wrote: > Hi Filipp, > > Thanks for pointing me at 8059613. With that I could run the tests. > > The ppc64 VM does not implement TieredCompilation, thus the tests fail. > Could you please apply something as the patch below? > > Thanks, > Goetz > > > diff -r c79a7b921a03 test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java > --- a/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 > +++ b/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 > @@ -170,6 +171,18 @@ > } > > public static void main(String args[]) throws Throwable { > + > + // Check whether VM supports tiered compilation. > + try { > + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag(TIERED_COMPILATION, true), > + null, > + new String[]{ "TieredCompilation is disabled in this release." }, > + "", "", ExitCode.OK); > + } catch (Throwable e) { > + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); > + return; > + } > + > for (TestCase testCase : TestCase.values()) { > if (testCase.isApplicable()) { > System.out.println("Running test case: " + testCase.name()); > diff -r c79a7b921a03 test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java > --- a/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Sat Dec 13 00:54:22 2014 +0300 > +++ b/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Tue Dec 23 12:17:26 2014 +0100 > @@ -22,7 +22,9 @@ > */ > package codeheapsize; > > +import com.oracle.java.testlibrary.ExitCode; > import com.oracle.java.testlibrary.Platform; > +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; > import common.CodeCacheCLITestBase; > import common.CodeCacheCLITestCase; > import sun.hotspot.code.BlobType; > @@ -75,6 +77,18 @@ > } > > public static void main(String args[]) throws Throwable { > + > + // Check whether VM supports tiered compilation. > + try { > + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), > + null, > + new String[]{ "TieredCompilation is disabled in this release." }, > + "", "", ExitCode.OK); > + } catch (Throwable e) { > + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); > + return; > + } > + > new TestCodeHeapSizeOptions().runTestCases(); > } > } > diff -r c79a7b921a03 test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java > --- a/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 > +++ b/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 > @@ -22,6 +22,8 @@ > */ > package printcodecache; > > +import com.oracle.java.testlibrary.ExitCode; > +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; > import common.CodeCacheCLITestBase; > import common.CodeCacheCLITestCase; > import sun.hotspot.code.BlobType; > @@ -68,6 +70,17 @@ > } > > public static void main(String args[]) throws Throwable { > + > + // Check whether VM supports tiered compilation. > + try { > + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), > + null, > + new String[]{ "TieredCompilation is disabled in this release." }, > + "", "", ExitCode.OK); > + } catch (Throwable e) { > + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); > + return; > + } > new TestPrintCodeCacheOption().runTestCases(); > } > } From dmitrij.pochepko at oracle.com Tue Dec 23 13:35:35 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Tue, 23 Dec 2014 16:35:35 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <5499562B.5020008@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> Message-ID: <54996FA7.3070607@oracle.com> Hi, There is one more issues related to these tests(not directly). Currently, dtrace tests can't be run in jprt, because dtrace require additional previleges for launching user. Perhaps it's just user to be granted previleges in jprt solaris hosts... Not sure about some guard in tests... the only way i know so far is to just try launching dtrace and parse output saying about missing previleges, but it doesn't seem to be good solution. I think test should assume to be launched in correct environment and in case it's failed because of previleges, evaluating engineer starting to work on respective env. issue... Does anybody have some additional concerns? Thanks, Dmitrij > Hi Dmitrij, > > > There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): > > test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java > 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; > > test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java > 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, > > > Otherwise, looks good. > Please, consider it reviewed (no need to re-review). > > Thanks, > Serguei > > > On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >> Hi, >> please review updated webrev >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >> >> Thanks, >> Dmitrij >>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> Thank you for catching these issues. >>>> I have a question regarding last comment: does it make any >>>> difference to change "reading of static member 3 times" to "copying >>>> into static member of another class and then read it 3 times"? >>> >>> Yes, it does (it is a minor issue though). >>> It is because the class names are pretty big. >>> It would simplify the code and improve readability, right? >>> >>> You already do it two times: >>> 179 List tml >>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> ... >>> 235 List mlist >>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> >>> My suggestion is to do it once somewhere before the line 74: >>> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> and then use the mlist in other places where it is needed: >>> >>> 75 String params = MLIST.stream() >>> ... >>> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >>> ... >>> 239 for (int i = MLIST.size() - 1; i> -1; i--) { >>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>> These lines will go away: >>> 179 List tml >>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> ... >>> 235 List mlist >>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>> >>> >>> Both private static classes are inner classes of the public one. >>> The MLIST will be in a context for the inner classes, and so, needs >>> no prefixing. >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi Dmitry, >>>>> >>>>> >>>>> It looks good in general. >>>>> Some minor comments are below. >>>>> >>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>> >>>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>> >>>>> >>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>> >>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>> >>>>> >>>>> 60 private static final String WORKER_CLASS_NAME >>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>> ... >>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>> The WORKER_CLASS_NAME can be used at 81. >>>>> >>>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>> ... >>>>> 179 List tml >>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> ... >>>>> 235 List mlist >>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> The TESTED_METHODS_LIST is used three times. >>>>> It can be cached at the top and re-used. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache >>>>>> feature >>>>>> >>>>>> Description: this fix introduce dtrace test, which verify that >>>>>> different combinations of available compile levels(and, in case >>>>>> compile levels allows it, different code heaps as result) >>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>> class SegmentedCodeCacheDtraceTest.java and class for running via >>>>>> dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d script >>>>>> is also present (SegmentedCodeCacheDtraceTestScript.d). A control >>>>>> class is using DtraceRunner.java to run dtrace and then analyzing >>>>>> results using class SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>> DtraceResultsAnalyzer interface. >>>>>> There is also a small class CompilerUtils.java created for >>>>>> usefull common code. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>> >>>>>> Additional note: Please note that this path assumes that fix for >>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>> also applied. >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipp.zhinkin at oracle.com Tue Dec 23 14:01:22 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 23 Dec 2014 18:01:22 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF44F44@DEWDFEMB12A.global.corp.sap> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44EEA@DEWDFEMB12A.global.corp.sap> <549953E0.9070209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44F44@DEWDFEMB12A.global.corp.sap> Message-ID: <549975B2.20204@oracle.com> Hi Goetz, On 12/23/2014 05:11 PM, Lindenmaier, Goetz wrote: > Hi Filipp, > > Maybe there should be Platform.implementsTiered() ? > There was a similar problem in 8067823. > > Does the WhiteBox know about the available compilers somehow? > I didn't find anything. I was going to run tests with +TieredCompilation and check that TieredCompilation is "false" using WhiteBox::getBooleanVMFlag. I agree that it would be nice to have some more direct approach to check tiered compilation availability, but I didn't find anything expect "sun.management.compiler" property that has "HotSpot 64-Bit Tiered Compilers" on my desktop disregard to TieredCompilation value. I'll dig in that direction and let you know if it is possible to use that property. Thanks, Filipp. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com] > Sent: Dienstag, 23. Dezember 2014 12:37 > To: Lindenmaier, Goetz; Christian Thalinger > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests > > Thank you for pointing me to this issue. > > Each test consist of several test cases and for test cases > that require TieredCompilation I've only checked that current VM is server one. > > Apparently it's not enough, so I'll update tests to check that VM is server and > TieredCompilation is available. > > Thanks, > Filipp. > > On 12/23/2014 03:26 PM, Lindenmaier, Goetz wrote: >> Hi Filipp, >> >> Thanks for pointing me at 8059613. With that I could run the tests. >> >> The ppc64 VM does not implement TieredCompilation, thus the tests fail. >> Could you please apply something as the patch below? >> >> Thanks, >> Goetz >> >> >> diff -r c79a7b921a03 test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java >> --- a/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 >> +++ b/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 >> @@ -170,6 +171,18 @@ >> } >> >> public static void main(String args[]) throws Throwable { >> + >> + // Check whether VM supports tiered compilation. >> + try { >> + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag(TIERED_COMPILATION, true), >> + null, >> + new String[]{ "TieredCompilation is disabled in this release." }, >> + "", "", ExitCode.OK); >> + } catch (Throwable e) { >> + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); >> + return; >> + } >> + >> for (TestCase testCase : TestCase.values()) { >> if (testCase.isApplicable()) { >> System.out.println("Running test case: " + testCase.name()); >> diff -r c79a7b921a03 test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java >> --- a/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Sat Dec 13 00:54:22 2014 +0300 >> +++ b/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Tue Dec 23 12:17:26 2014 +0100 >> @@ -22,7 +22,9 @@ >> */ >> package codeheapsize; >> >> +import com.oracle.java.testlibrary.ExitCode; >> import com.oracle.java.testlibrary.Platform; >> +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; >> import common.CodeCacheCLITestBase; >> import common.CodeCacheCLITestCase; >> import sun.hotspot.code.BlobType; >> @@ -75,6 +77,18 @@ >> } >> >> public static void main(String args[]) throws Throwable { >> + >> + // Check whether VM supports tiered compilation. >> + try { >> + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), >> + null, >> + new String[]{ "TieredCompilation is disabled in this release." }, >> + "", "", ExitCode.OK); >> + } catch (Throwable e) { >> + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); >> + return; >> + } >> + >> new TestCodeHeapSizeOptions().runTestCases(); >> } >> } >> diff -r c79a7b921a03 test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java >> --- a/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 >> +++ b/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 >> @@ -22,6 +22,8 @@ >> */ >> package printcodecache; >> >> +import com.oracle.java.testlibrary.ExitCode; >> +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; >> import common.CodeCacheCLITestBase; >> import common.CodeCacheCLITestCase; >> import sun.hotspot.code.BlobType; >> @@ -68,6 +70,17 @@ >> } >> >> public static void main(String args[]) throws Throwable { >> + >> + // Check whether VM supports tiered compilation. >> + try { >> + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), >> + null, >> + new String[]{ "TieredCompilation is disabled in this release." }, >> + "", "", ExitCode.OK); >> + } catch (Throwable e) { >> + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); >> + return; >> + } >> new TestPrintCodeCacheOption().runTestCases(); >> } >> } From filipp.zhinkin at oracle.com Tue Dec 23 14:10:25 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 23 Dec 2014 18:10:25 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <549975B2.20204@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44EEA@DEWDFEMB12A.global.corp.sap> <549953E0.9070209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44F44@DEWDFEMB12A.global.corp.sap> <549975B2.20204@oracle.com> Message-ID: <549977D1.30302@oracle.com> On 12/23/2014 06:01 PM, Filipp Zhinkin wrote: > Hi Goetz, > > On 12/23/2014 05:11 PM, Lindenmaier, Goetz wrote: >> Hi Filipp, >> >> Maybe there should be Platform.implementsTiered() ? >> There was a similar problem in 8067823. >> >> Does the WhiteBox know about the available compilers somehow? >> I didn't find anything. > I was going to run tests with +TieredCompilation and > check that TieredCompilation is "false" using WhiteBox::getBooleanVMFlag. > > I agree that it would be nice to have some more direct approach > to check tiered compilation availability, but I didn't find anything expect > "sun.management.compiler" property that has "HotSpot 64-Bit Tiered Compilers" > on my desktop disregard to TieredCompilation value. > > I'll dig in that direction and let you know if it is possible to use that > property. Actually, it should work: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 Thanks, Filipp. > > Thanks, > Filipp. >> >> Best regards, >> Goetz. >> >> >> >> >> -----Original Message----- >> From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com] >> Sent: Dienstag, 23. Dezember 2014 12:37 >> To: Lindenmaier, Goetz; Christian Thalinger >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line >> options tests >> >> Thank you for pointing me to this issue. >> >> Each test consist of several test cases and for test cases >> that require TieredCompilation I've only checked that current VM is server one. >> >> Apparently it's not enough, so I'll update tests to check that VM is server and >> TieredCompilation is available. >> >> Thanks, >> Filipp. >> >> On 12/23/2014 03:26 PM, Lindenmaier, Goetz wrote: >>> Hi Filipp, >>> >>> Thanks for pointing me at 8059613. With that I could run the tests. >>> >>> The ppc64 VM does not implement TieredCompilation, thus the tests fail. >>> Could you please apply something as the patch below? >>> >>> Thanks, >>> Goetz >>> >>> >>> diff -r c79a7b921a03 >>> test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java >>> --- a/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Sat Dec >>> 13 00:54:22 2014 +0300 >>> +++ b/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Tue Dec >>> 23 12:17:26 2014 +0100 >>> @@ -170,6 +171,18 @@ >>> } >>> public static void main(String args[]) throws Throwable { >>> + >>> + // Check whether VM supports tiered compilation. >>> + try { >>> + >>> CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag(TIERED_COMPILATION, >>> true), >>> + null, >>> + new String[]{ >>> "TieredCompilation is disabled in this release." }, >>> + "", "", ExitCode.OK); >>> + } catch (Throwable e) { >>> + System.out.println("Skipping the test as TieredCompilation is >>> not implemented in this VM."); >>> + return; >>> + } >>> + >>> for (TestCase testCase : TestCase.values()) { >>> if (testCase.isApplicable()) { >>> System.out.println("Running test case: " + testCase.name()); >>> diff -r c79a7b921a03 >>> test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java >>> --- a/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java >>> Sat Dec 13 00:54:22 2014 +0300 >>> +++ b/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java >>> Tue Dec 23 12:17:26 2014 +0100 >>> @@ -22,7 +22,9 @@ >>> */ >>> package codeheapsize; >>> +import com.oracle.java.testlibrary.ExitCode; >>> import com.oracle.java.testlibrary.Platform; >>> +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; >>> import common.CodeCacheCLITestBase; >>> import common.CodeCacheCLITestCase; >>> import sun.hotspot.code.BlobType; >>> @@ -75,6 +77,18 @@ >>> } >>> public static void main(String args[]) throws Throwable { >>> + >>> + // Check whether VM supports tiered compilation. >>> + try { >>> + >>> CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", >>> true), >>> + null, >>> + new String[]{ >>> "TieredCompilation is disabled in this release." }, >>> + "", "", ExitCode.OK); >>> + } catch (Throwable e) { >>> + System.out.println("Skipping the test as TieredCompilation is >>> not implemented in this VM."); >>> + return; >>> + } >>> + >>> new TestCodeHeapSizeOptions().runTestCases(); >>> } >>> } >>> diff -r c79a7b921a03 >>> test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java >>> --- >>> a/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java >>> Sat Dec 13 00:54:22 2014 +0300 >>> +++ >>> b/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java >>> Tue Dec 23 12:17:26 2014 +0100 >>> @@ -22,6 +22,8 @@ >>> */ >>> package printcodecache; >>> +import com.oracle.java.testlibrary.ExitCode; >>> +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; >>> import common.CodeCacheCLITestBase; >>> import common.CodeCacheCLITestCase; >>> import sun.hotspot.code.BlobType; >>> @@ -68,6 +70,17 @@ >>> } >>> public static void main(String args[]) throws Throwable { >>> + >>> + // Check whether VM supports tiered compilation. >>> + try { >>> + >>> CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", >>> true), >>> + null, >>> + new String[]{ >>> "TieredCompilation is disabled in this release." }, >>> + "", "", ExitCode.OK); >>> + } catch (Throwable e) { >>> + System.out.println("Skipping the test as TieredCompilation is >>> not implemented in this VM."); >>> + return; >>> + } >>> new TestPrintCodeCacheOption().runTestCases(); >>> } >>> } > From goetz.lindenmaier at sap.com Tue Dec 23 14:18:39 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 23 Dec 2014 14:18:39 +0000 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <549975B2.20204@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44EEA@DEWDFEMB12A.global.corp.sap> <549953E0.9070209@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF44F44@DEWDFEMB12A.global.corp.sap> <549975B2.20204@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF44F7C@DEWDFEMB12A.global.corp.sap> That's a good one! With ppc64, it's saying "HotSpot 64-Bit Server Compiler". So we can parse that string for "Tiered". And I guess we need something that tells about the features of the VM and that does not depend on the current settings of the TieredCompilation flag. Well, I was just reading the same file ... yes, it should work. Thanks, Goetz. -----Original Message----- From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com] Sent: Dienstag, 23. Dezember 2014 15:01 To: Lindenmaier, Goetz Cc: Christian Thalinger; hotspot-compiler-dev at openjdk.java.net Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests Hi Goetz, On 12/23/2014 05:11 PM, Lindenmaier, Goetz wrote: > Hi Filipp, > > Maybe there should be Platform.implementsTiered() ? > There was a similar problem in 8067823. > > Does the WhiteBox know about the available compilers somehow? > I didn't find anything. I was going to run tests with +TieredCompilation and check that TieredCompilation is "false" using WhiteBox::getBooleanVMFlag. I agree that it would be nice to have some more direct approach to check tiered compilation availability, but I didn't find anything expect "sun.management.compiler" property that has "HotSpot 64-Bit Tiered Compilers" on my desktop disregard to TieredCompilation value. I'll dig in that direction and let you know if it is possible to use that property. Thanks, Filipp. > > Best regards, > Goetz. > > > > > -----Original Message----- > From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com] > Sent: Dienstag, 23. Dezember 2014 12:37 > To: Lindenmaier, Goetz; Christian Thalinger > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests > > Thank you for pointing me to this issue. > > Each test consist of several test cases and for test cases > that require TieredCompilation I've only checked that current VM is server one. > > Apparently it's not enough, so I'll update tests to check that VM is server and > TieredCompilation is available. > > Thanks, > Filipp. > > On 12/23/2014 03:26 PM, Lindenmaier, Goetz wrote: >> Hi Filipp, >> >> Thanks for pointing me at 8059613. With that I could run the tests. >> >> The ppc64 VM does not implement TieredCompilation, thus the tests fail. >> Could you please apply something as the patch below? >> >> Thanks, >> Goetz >> >> >> diff -r c79a7b921a03 test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java >> --- a/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 >> +++ b/test/compiler/codecache/cli/TestSegmentedCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 >> @@ -170,6 +171,18 @@ >> } >> >> public static void main(String args[]) throws Throwable { >> + >> + // Check whether VM supports tiered compilation. >> + try { >> + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag(TIERED_COMPILATION, true), >> + null, >> + new String[]{ "TieredCompilation is disabled in this release." }, >> + "", "", ExitCode.OK); >> + } catch (Throwable e) { >> + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); >> + return; >> + } >> + >> for (TestCase testCase : TestCase.values()) { >> if (testCase.isApplicable()) { >> System.out.println("Running test case: " + testCase.name()); >> diff -r c79a7b921a03 test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java >> --- a/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Sat Dec 13 00:54:22 2014 +0300 >> +++ b/test/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java Tue Dec 23 12:17:26 2014 +0100 >> @@ -22,7 +22,9 @@ >> */ >> package codeheapsize; >> >> +import com.oracle.java.testlibrary.ExitCode; >> import com.oracle.java.testlibrary.Platform; >> +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; >> import common.CodeCacheCLITestBase; >> import common.CodeCacheCLITestCase; >> import sun.hotspot.code.BlobType; >> @@ -75,6 +77,18 @@ >> } >> >> public static void main(String args[]) throws Throwable { >> + >> + // Check whether VM supports tiered compilation. >> + try { >> + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), >> + null, >> + new String[]{ "TieredCompilation is disabled in this release." }, >> + "", "", ExitCode.OK); >> + } catch (Throwable e) { >> + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); >> + return; >> + } >> + >> new TestCodeHeapSizeOptions().runTestCases(); >> } >> } >> diff -r c79a7b921a03 test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java >> --- a/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Sat Dec 13 00:54:22 2014 +0300 >> +++ b/test/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java Tue Dec 23 12:17:26 2014 +0100 >> @@ -22,6 +22,8 @@ >> */ >> package printcodecache; >> >> +import com.oracle.java.testlibrary.ExitCode; >> +import com.oracle.java.testlibrary.cli.CommandLineOptionTest; >> import common.CodeCacheCLITestBase; >> import common.CodeCacheCLITestCase; >> import sun.hotspot.code.BlobType; >> @@ -68,6 +70,17 @@ >> } >> >> public static void main(String args[]) throws Throwable { >> + >> + // Check whether VM supports tiered compilation. >> + try { >> + CommandLineOptionTest.verifyJVMStartup(CommandLineOptionTest.prepareBooleanFlag("TieredCompilation", true), >> + null, >> + new String[]{ "TieredCompilation is disabled in this release." }, >> + "", "", ExitCode.OK); >> + } catch (Throwable e) { >> + System.out.println("Skipping the test as TieredCompilation is not implemented in this VM."); >> + return; >> + } >> new TestPrintCodeCacheOption().runTestCases(); >> } >> } From filipp.zhinkin at oracle.com Wed Dec 24 14:22:19 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 24 Dec 2014 18:22:19 +0400 Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms Message-ID: <549ACC1B.8090706@oracle.com> Hi all, please review a new c.o.j.t.Platform's method "isTieredSupported" which is aimed to report whether or not JVM supports tiered compilation disregard to TieredCompilation flag's value. Such functionality is required for Segmented Code Cache CLI tests [1] and it would be useful in other cases too ([2] for instance). In order to check if tiered compilation is supported we simply look to "sun.management.compiler"property's valuewhich will contain "Tiered Compilers" substring only when tiered compilation is supported [3]. Bug id: https://bugs.openjdk.java.net/browse/JDK-8068183 Webrev: http://cr.openjdk.java.net/~fzhinkin/8068183/webrev.00/ Testing: manual on localmachine using both client & server JVMs. Thanks, Filipp. [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016717.html [2] https://bugs.openjdk.java.net/browse/JDK-8067823 [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 From filipp.zhinkin at oracle.com Wed Dec 24 14:47:03 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 24 Dec 2014 18:47:03 +0400 Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms In-Reply-To: <549ACC1B.8090706@oracle.com> References: <549ACC1B.8090706@oracle.com> Message-ID: <549AD1E7.9040906@oracle.com> On 12/24/2014 06:22 PM, Filipp Zhinkin wrote: > Hi all, > > please review a new c.o.j.t.Platform's method "isTieredSupported" > which is aimed to report whether or not JVM supports tiered compilation > disregard to TieredCompilation flag's value. > > Such functionality is required for Segmented Code Cache CLI tests [1] > and it would be useful in other cases too ([2] for instance). > > In order to check if tiered compilation is supported we simply look to > "sun.management.compiler"property's valuewhich will contain > "Tiered Compilers" substring only when tiered compilation is supported [3]. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8068183 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8068183/webrev.00/ > Testing: manual on localmachine using both client & server JVMs. And using embedded VM too. > > Thanks, > Filipp. > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016717.html > [2] https://bugs.openjdk.java.net/browse/JDK-8067823 > [3] > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 From vladimir.kozlov at oracle.com Wed Dec 24 15:31:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 24 Dec 2014 07:31:27 -0800 Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms In-Reply-To: <549ACC1B.8090706@oracle.com> References: <549ACC1B.8090706@oracle.com> Message-ID: <549ADC4F.6050904@oracle.com> Looks good. Thanks, Vladimir On 12/24/14 6:22 AM, Filipp Zhinkin wrote: > Hi all, > > please review a new c.o.j.t.Platform's method "isTieredSupported" > which is aimed to report whether or not JVM supports tiered compilation > disregard to TieredCompilation flag's value. > > Such functionality is required for Segmented Code Cache CLI tests [1] > and it would be useful in other cases too ([2] for instance). > > In order to check if tiered compilation is supported we simply look to > "sun.management.compiler"property's valuewhich will contain > "Tiered Compilers" substring only when tiered compilation is supported [3]. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8068183 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8068183/webrev.00/ > Testing: manual on localmachine using both client & server JVMs. > > Thanks, > Filipp. > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016717.html > [2] https://bugs.openjdk.java.net/browse/JDK-8067823 > [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 From filipp.zhinkin at oracle.com Wed Dec 24 15:27:38 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 24 Dec 2014 19:27:38 +0400 Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms In-Reply-To: <549ADC4F.6050904@oracle.com> References: <549ACC1B.8090706@oracle.com> <549ADC4F.6050904@oracle.com> Message-ID: <549ADB6A.40707@oracle.com> Vladimir, thank you for review. Regards, Filipp. On 12/24/2014 07:31 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 12/24/14 6:22 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a new c.o.j.t.Platform's method "isTieredSupported" >> which is aimed to report whether or not JVM supports tiered compilation >> disregard to TieredCompilation flag's value. >> >> Such functionality is required for Segmented Code Cache CLI tests [1] >> and it would be useful in other cases too ([2] for instance). >> >> In order to check if tiered compilation is supported we simply look to >> "sun.management.compiler"property's valuewhich will contain >> "Tiered Compilers" substring only when tiered compilation is supported [3]. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8068183 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8068183/webrev.00/ >> Testing: manual on localmachine using both client & server JVMs. >> >> Thanks, >> Filipp. >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016717.html >> [2] https://bugs.openjdk.java.net/browse/JDK-8067823 >> [3] >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 From igor.ignatyev at oracle.com Wed Dec 24 16:33:20 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 24 Dec 2014 19:33:20 +0300 Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms In-Reply-To: <549AD1E7.9040906@oracle.com> References: <549ACC1B.8090706@oracle.com> <549AD1E7.9040906@oracle.com> Message-ID: <549AEAD0.3040100@oracle.com> Filipp, looks good to me. Thanks Igor On 12/24/2014 05:47 PM, Filipp Zhinkin wrote: > On 12/24/2014 06:22 PM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a new c.o.j.t.Platform's method "isTieredSupported" >> which is aimed to report whether or not JVM supports tiered compilation >> disregard to TieredCompilation flag's value. >> >> Such functionality is required for Segmented Code Cache CLI tests [1] >> and it would be useful in other cases too ([2] for instance). >> >> In order to check if tiered compilation is supported we simply look to >> "sun.management.compiler"property's valuewhich will contain >> "Tiered Compilers" substring only when tiered compilation is supported >> [3]. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8068183 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8068183/webrev.00/ >> Testing: manual on localmachine using both client & server JVMs. > And using embedded VM too. >> >> Thanks, >> Filipp. >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016717.html >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8067823 >> [3] >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 >> > From filipp.zhinkin at oracle.com Wed Dec 24 16:27:49 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 24 Dec 2014 20:27:49 +0400 Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms In-Reply-To: <549AEAD0.3040100@oracle.com> References: <549ACC1B.8090706@oracle.com> <549AD1E7.9040906@oracle.com> <549AEAD0.3040100@oracle.com> Message-ID: <549AE985.10000@oracle.com> Igor, thank you for review. Regards, Filipp. On 12/24/2014 08:33 PM, Igor Ignatyev wrote: > Filipp, > > looks good to me. > > Thanks > Igor > > On 12/24/2014 05:47 PM, Filipp Zhinkin wrote: >> On 12/24/2014 06:22 PM, Filipp Zhinkin wrote: >>> Hi all, >>> >>> please review a new c.o.j.t.Platform's method "isTieredSupported" >>> which is aimed to report whether or not JVM supports tiered compilation >>> disregard to TieredCompilation flag's value. >>> >>> Such functionality is required for Segmented Code Cache CLI tests [1] >>> and it would be useful in other cases too ([2] for instance). >>> >>> In order to check if tiered compilation is supported we simply look to >>> "sun.management.compiler"property's valuewhich will contain >>> "Tiered Compilers" substring only when tiered compilation is supported >>> [3]. >>> >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8068183 >>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8068183/webrev.00/ >>> Testing: manual on localmachine using both client & server JVMs. >> And using embedded VM too. >>> >>> Thanks, >>> Filipp. >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016717.html >>> >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8067823 >>> [3] >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 >>> >>> >> From filipp.zhinkin at oracle.com Wed Dec 24 16:33:49 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Wed, 24 Dec 2014 20:33:49 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <54991BBF.2000704@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> Message-ID: <549AEAED.9070307@oracle.com> Hi all, please take a look at updated tests. This time an issue with server JVMs that don't support tiered compilation was resolved. incremental diff: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02.inc/ new webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02/ testing: JPRT & local (using server embedded JVM which does not support tiered comp). This change is also depends on https://bugs.openjdk.java.net/browse/JDK-8068183. Thanks, Filipp. On 12/23/2014 11:37 AM, Filipp Zhinkin wrote: > Thank you, Christian! > > Regards, > Filipp. > > On 12/22/2014 09:01 PM, Christian Thalinger wrote: >> Yes, looks good. >> >>> On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin wrote: >>> >>> Christian, are you ok with the latest fix version? >>> >>> Thanks, >>> Filipp. >>> >>> On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: >>>> Christian, thank you for review! >>>> >>>> I've updated tests to reflect WhiteBox movement to top-level repo, >>>> added previously missed @bug tag and fixed few small issues: >>>> >>>> incremental diff: >>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ >>>> >>>> updated webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/19/2014 02:19 AM, Christian Thalinger wrote: >>>>> Looks good. >>>>> >>>>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann >>>>>> wrote: >>>>>> >>>>>> Hi Filipp, >>>>>> >>>>>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>>>>> Tobias, >>>>>>> >>>>>>> as I wrote you in a private message, until a fix for 8064940 doesn't affect >>>>>>> the way options are processed there is no need to update proposed tests. >>>>>>> >>>>>>> I've filed 8067135 for new tests that will verify actual alignment of >>>>>>> code heaps. >>>>>> Okay, sounds good. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> Regards, >>>>>>> Filipp. >>>>>>> >>>>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>>>>> Hi Tobias, >>>>>>>>>> >>>>>>>>>> thank you for suggestion. >>>>>>>>>> >>>>>>>>>> Yes, I think we should take code heap size alignment into account. >>>>>>>>>> >>>>>>>>>> What alignment policy you're going to implement for 8064940? >>>>>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>>>>> >>>>>>>>>> Maybe instead of checking that values are in >>>>>>>>>> (value - page_size, value + page_size) interval we should just check >>>>>>>>>> that all values were aligned up to page_size? >>>>>>>>> Yes, that's a better solution. However, I don't know how to figure out >>>>>>>>> the >>>>>>>>> available page sizes from Java code. >>>>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>>>>> about to add such method to WB API, but it need to check how well >>>>>>>> it is going to work with large pages. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Filipp. >>>>>>>>> Best, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Filipp. >>>>>>>>>> >>>>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>>>>> Hi Filipp, >>>>>>>>>>> >>>>>>>>>>> the actual size of a code heap is affected by alignment and >>>>>>>>>>> therefore may be >>>>>>>>>>> different to the size set via the command line. For example, on >>>>>>>>>>> Sparc we >>>>>>>>>>> have to >>>>>>>>>>> make sure that the code heaps are large page (4MB) aligned to reduce >>>>>>>>>>> the >>>>>>>>>>> number >>>>>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>>>>> >>>>>>>>>>> Maybe we should check if the actual size of the code heap is within >>>>>>>>>>> boundaries, >>>>>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>>>>> >>>>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please take a look at CLI tests for segmented code cache >>>>>>>>>>>> (JDK-8059623). >>>>>>>>>>>> >>>>>>>>>>>> There are three new tests: >>>>>>>>>>>> compiler/codecache/cli/ >>>>>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>>>>> >>>>>>>>>>>> All tests consist of several test cases aimed to verify different >>>>>>>>>>>> aspects >>>>>>>>>>>> of options' processing. >>>>>>>>>>>> >>>>>>>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache >>>>>>>>>>>> test, >>>>>>>>>>>> but add additional value - these tests actually check final values >>>>>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>>>>> >>>>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>>>>> Testing: manual & automated >>>>>>>>>>>> >>>>>>>>>>>> This change depends on: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve >>>>>>>>>>>> compiler's CLI >>>>>>>>>>>> tests >>>>>>>>>>>> error reporting >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>>>>>>> testlibrary >>>>>>>>>>>> for JDK-8059613 >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Filipp. > From dmitrij.pochepko at oracle.com Wed Dec 24 20:09:01 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 24 Dec 2014 23:09:01 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <54996FA7.3070607@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> Message-ID: <549B1D5D.8030908@oracle.com> Hi, i've placed a guard which skips test in case dtrace exits with non-zero code. http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ Thanks, Dmitrij > Hi, > > There is one more issues related to these tests(not directly). > Currently, dtrace tests can't be run in jprt, because dtrace require > additional previleges for launching user. > Perhaps it's just user to be granted previleges in jprt solaris hosts... > Not sure about some guard in tests... the only way i know so far is to > just try launching dtrace and parse output > saying about missing previleges, but it doesn't seem to be good solution. > I think test should assume to be launched in correct environment and > in case it's failed because of previleges, evaluating engineer > starting to work on respective env. issue... > Does anybody have some additional concerns? > > Thanks, > Dmitrij > >> Hi Dmitrij, >> >> >> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >> >> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >> 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >> >> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >> >> >> Otherwise, looks good. >> Please, consider it reviewed (no need to re-review). >> >> Thanks, >> Serguei >> >> >> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>> Hi, >>> please review updated webrev >>> >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>> >>> Thanks, >>> Dmitrij >>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> Thank you for catching these issues. >>>>> I have a question regarding last comment: does it make any >>>>> difference to change "reading of static member 3 times" to >>>>> "copying into static member of another class and then read it 3 >>>>> times"? >>>> >>>> Yes, it does (it is a minor issue though). >>>> It is because the class names are pretty big. >>>> It would simplify the code and improve readability, right? >>>> >>>> You already do it two times: >>>> 179 List tml >>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> ... >>>> 235 List mlist >>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> >>>> My suggestion is to do it once somewhere before the line 74: >>>> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> and then use the mlist in other places where it is needed: >>>> >>>> 75 String params = MLIST.stream() >>>> ... >>>> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >>>> ... >>>> 239 for (int i = MLIST.size() - 1; i> -1; i--) { >>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>> These lines will go away: >>>> 179 List tml >>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> ... >>>> 235 List mlist >>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>> >>>> >>>> Both private static classes are inner classes of the public one. >>>> The MLIST will be in a context for the inner classes, and so, needs >>>> no prefixing. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> Hi Dmitry, >>>>>> >>>>>> >>>>>> It looks good in general. >>>>>> Some minor comments are below. >>>>>> >>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>> >>>>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>> >>>>>> >>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>> >>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>> >>>>>> >>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>> ... >>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>> >>>>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>> ... >>>>>> 179 List tml >>>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> The TESTED_METHODS_LIST is used three times. >>>>>> It can be cached at the top and re-used. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review changes for >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>> codecache feature >>>>>>> >>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>> different combinations of available compile levels(and, in case >>>>>>> compile levels allows it, different code heaps as result) >>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>> analyzing results using class >>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>> DtraceResultsAnalyzer interface. >>>>>>> There is also a small class CompilerUtils.java created for >>>>>>> usefull common code. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>> >>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>> also applied. >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu Dec 25 09:42:49 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 12:42:49 +0300 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <549AEAED.9070307@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <549AEAED.9070307@oracle.com> Message-ID: <549BDC19.6020204@oracle.com> Filipp, looks good to me. Thanks, Igor On 12/24/2014 07:33 PM, Filipp Zhinkin wrote: > Hi all, > > please take a look at updated tests. > This time an issue with server JVMs that don't support tiered > compilation was resolved. > > incremental diff: > http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02.inc/ > new webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02/ > testing: JPRT & local (using server embedded JVM which does not support > tiered comp). > > This change is also depends on > https://bugs.openjdk.java.net/browse/JDK-8068183. > > Thanks, > Filipp. > > On 12/23/2014 11:37 AM, Filipp Zhinkin wrote: >> Thank you, Christian! >> >> Regards, >> Filipp. >> >> On 12/22/2014 09:01 PM, Christian Thalinger wrote: >>> Yes, looks good. >>> >>>> On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin >>>> wrote: >>>> >>>> Christian, are you ok with the latest fix version? >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: >>>>> Christian, thank you for review! >>>>> >>>>> I've updated tests to reflect WhiteBox movement to top-level repo, >>>>> added previously missed @bug tag and fixed few small issues: >>>>> >>>>> incremental diff: >>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ >>>>> >>>>> updated webrev: >>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 12/19/2014 02:19 AM, Christian Thalinger wrote: >>>>>> Looks good. >>>>>> >>>>>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann >>>>>>> wrote: >>>>>>> >>>>>>> Hi Filipp, >>>>>>> >>>>>>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>>>>>> Tobias, >>>>>>>> >>>>>>>> as I wrote you in a private message, until a fix for 8064940 >>>>>>>> doesn't affect >>>>>>>> the way options are processed there is no need to update >>>>>>>> proposed tests. >>>>>>>> >>>>>>>> I've filed 8067135 for new tests that will verify actual >>>>>>>> alignment of code heaps. >>>>>>> Okay, sounds good. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> Regards, >>>>>>>> Filipp. >>>>>>>> >>>>>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>>>>>> Hi Tobias, >>>>>>>>>>> >>>>>>>>>>> thank you for suggestion. >>>>>>>>>>> >>>>>>>>>>> Yes, I think we should take code heap size alignment into >>>>>>>>>>> account. >>>>>>>>>>> >>>>>>>>>>> What alignment policy you're going to implement for 8064940? >>>>>>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>>>>>> >>>>>>>>>>> Maybe instead of checking that values are in >>>>>>>>>>> (value - page_size, value + page_size) interval we should >>>>>>>>>>> just check >>>>>>>>>>> that all values were aligned up to page_size? >>>>>>>>>> Yes, that's a better solution. However, I don't know how to >>>>>>>>>> figure out the >>>>>>>>>> available page sizes from Java code. >>>>>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>>>>>> about to add such method to WB API, but it need to check how well >>>>>>>>> it is going to work with large pages. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Filipp. >>>>>>>>>> Best, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Filipp. >>>>>>>>>>> >>>>>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi Filipp, >>>>>>>>>>>> >>>>>>>>>>>> the actual size of a code heap is affected by alignment and >>>>>>>>>>>> therefore may be >>>>>>>>>>>> different to the size set via the command line. For example, >>>>>>>>>>>> on Sparc we >>>>>>>>>>>> have to >>>>>>>>>>>> make sure that the code heaps are large page (4MB) aligned >>>>>>>>>>>> to reduce the >>>>>>>>>>>> number >>>>>>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>>>>>> >>>>>>>>>>>> Maybe we should check if the actual size of the code heap is >>>>>>>>>>>> within >>>>>>>>>>>> boundaries, >>>>>>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>>>>>> >>>>>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> please take a look at CLI tests for segmented code cache >>>>>>>>>>>>> (JDK-8059623). >>>>>>>>>>>>> >>>>>>>>>>>>> There are three new tests: >>>>>>>>>>>>> compiler/codecache/cli/ >>>>>>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>>>>>> >>>>>>>>>>>>> All tests consist of several test cases aimed to verify >>>>>>>>>>>>> different aspects >>>>>>>>>>>>> of options' processing. >>>>>>>>>>>>> >>>>>>>>>>>>> These tests partially overlapped with >>>>>>>>>>>>> c/c/CheckSegmentedCodeCache test, >>>>>>>>>>>>> but add additional value - these tests actually check final >>>>>>>>>>>>> values >>>>>>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>>>>>> Testing: manual & automated >>>>>>>>>>>>> >>>>>>>>>>>>> This change depends on: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve >>>>>>>>>>>>> compiler's CLI >>>>>>>>>>>>> tests >>>>>>>>>>>>> error reporting >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various >>>>>>>>>>>>> changes in >>>>>>>>>>>>> testlibrary >>>>>>>>>>>>> for JDK-8059613 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Filipp. >> > From filipp.zhinkin at oracle.com Thu Dec 25 09:37:55 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 13:37:55 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <549BDC19.6020204@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <549AEAED.9070307@oracle.com> <549BDC19.6020204@oracle.com> Message-ID: <549BDAF3.7040808@oracle.com> Thank you, Igor! Regards, Filipp. On 12/25/2014 01:42 PM, Igor Ignatyev wrote: > Filipp, > > looks good to me. > > Thanks, > Igor > > On 12/24/2014 07:33 PM, Filipp Zhinkin wrote: >> Hi all, >> >> please take a look at updated tests. >> This time an issue with server JVMs that don't support tiered >> compilation was resolved. >> >> incremental diff: >> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02.inc/ >> new webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02/ >> testing: JPRT & local (using server embedded JVM which does not support >> tiered comp). >> >> This change is also depends on >> https://bugs.openjdk.java.net/browse/JDK-8068183. >> >> Thanks, >> Filipp. >> >> On 12/23/2014 11:37 AM, Filipp Zhinkin wrote: >>> Thank you, Christian! >>> >>> Regards, >>> Filipp. >>> >>> On 12/22/2014 09:01 PM, Christian Thalinger wrote: >>>> Yes, looks good. >>>> >>>>> On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin >>>>> wrote: >>>>> >>>>> Christian, are you ok with the latest fix version? >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: >>>>>> Christian, thank you for review! >>>>>> >>>>>> I've updated tests to reflect WhiteBox movement to top-level repo, >>>>>> added previously missed @bug tag and fixed few small issues: >>>>>> >>>>>> incremental diff: >>>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ >>>>>> >>>>>> updated webrev: >>>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Filipp. >>>>>> >>>>>> On 12/19/2014 02:19 AM, Christian Thalinger wrote: >>>>>>> Looks good. >>>>>>> >>>>>>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Filipp, >>>>>>>> >>>>>>>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>>>>>>> Tobias, >>>>>>>>> >>>>>>>>> as I wrote you in a private message, until a fix for 8064940 >>>>>>>>> doesn't affect >>>>>>>>> the way options are processed there is no need to update >>>>>>>>> proposed tests. >>>>>>>>> >>>>>>>>> I've filed 8067135 for new tests that will verify actual >>>>>>>>> alignment of code heaps. >>>>>>>> Okay, sounds good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Filipp. >>>>>>>>> >>>>>>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>>>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>>>>>>> Hi Tobias, >>>>>>>>>>>> >>>>>>>>>>>> thank you for suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Yes, I think we should take code heap size alignment into >>>>>>>>>>>> account. >>>>>>>>>>>> >>>>>>>>>>>> What alignment policy you're going to implement for 8064940? >>>>>>>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>>>>>>> >>>>>>>>>>>> Maybe instead of checking that values are in >>>>>>>>>>>> (value - page_size, value + page_size) interval we should >>>>>>>>>>>> just check >>>>>>>>>>>> that all values were aligned up to page_size? >>>>>>>>>>> Yes, that's a better solution. However, I don't know how to >>>>>>>>>>> figure out the >>>>>>>>>>> available page sizes from Java code. >>>>>>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>>>>>>> about to add such method to WB API, but it need to check how well >>>>>>>>>> it is going to work with large pages. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Filipp. >>>>>>>>>>> Best, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Filipp. >>>>>>>>>>>> >>>>>>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>>>>>>> Hi Filipp, >>>>>>>>>>>>> >>>>>>>>>>>>> the actual size of a code heap is affected by alignment and >>>>>>>>>>>>> therefore may be >>>>>>>>>>>>> different to the size set via the command line. For example, >>>>>>>>>>>>> on Sparc we >>>>>>>>>>>>> have to >>>>>>>>>>>>> make sure that the code heaps are large page (4MB) aligned >>>>>>>>>>>>> to reduce the >>>>>>>>>>>>> number >>>>>>>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>>>>>>> >>>>>>>>>>>>> Maybe we should check if the actual size of the code heap is >>>>>>>>>>>>> within >>>>>>>>>>>>> boundaries, >>>>>>>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Tobias >>>>>>>>>>>>> >>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>>>>>>> >>>>>>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> please take a look at CLI tests for segmented code cache >>>>>>>>>>>>>> (JDK-8059623). >>>>>>>>>>>>>> >>>>>>>>>>>>>> There are three new tests: >>>>>>>>>>>>>> compiler/codecache/cli/ >>>>>>>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>>>>>>> >>>>>>>>>>>>>> All tests consist of several test cases aimed to verify >>>>>>>>>>>>>> different aspects >>>>>>>>>>>>>> of options' processing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> These tests partially overlapped with >>>>>>>>>>>>>> c/c/CheckSegmentedCodeCache test, >>>>>>>>>>>>>> but add additional value - these tests actually check final >>>>>>>>>>>>>> values >>>>>>>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>>>>>>> Testing: manual & automated >>>>>>>>>>>>>> >>>>>>>>>>>>>> This change depends on: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve >>>>>>>>>>>>>> compiler's CLI >>>>>>>>>>>>>> tests >>>>>>>>>>>>>> error reporting >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various >>>>>>>>>>>>>> changes in >>>>>>>>>>>>>> testlibrary >>>>>>>>>>>>>> for JDK-8059613 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Filipp. >>> >> From igor.ignatyev at oracle.com Thu Dec 25 09:46:28 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 12:46:28 +0300 Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class In-Reply-To: <54872854.90806@oracle.com> References: <54872854.90806@oracle.com> Message-ID: <549BDCF4.20906@oracle.com> Looks good to me. Igor On 12/09/2014 07:50 PM, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066497 > webrev: > http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ > > > Problem: > ByteCodeLoader allows one to load class with given name from existing > bytecode. But if this class is already loaded by e.g. system classloader > it cannot be redefined using another bytecode array because of > delegation of loadClass call to parent classloader. > > Solution: > override loadClass to break delegation for given className. > > Testing: manual > > ------------------- > Thanks, > Pavel From filipp.zhinkin at oracle.com Thu Dec 25 09:51:40 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 13:51:40 +0400 Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class In-Reply-To: <54872854.90806@oracle.com> References: <54872854.90806@oracle.com> Message-ID: <549BDE2C.7090703@oracle.com> Hi Pavel, the change looks good. Regards, Filipp. On 12/09/2014 08:50 PM, Pavel Chistyakov wrote: > Hi all, > > please review changes for: https://bugs.openjdk.java.net/browse/JDK-8066497 > webrev: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ > > > Problem: > ByteCodeLoader allows one to load class with given name from existing > bytecode. But if this class is already loaded by e.g. system classloader it > cannot be redefined using another bytecode array because of delegation of > loadClass call to parent classloader. > > Solution: > override loadClass to break delegation for given className. > > Testing: manual > > ------------------- > Thanks, > Pavel From filipp.zhinkin at oracle.com Thu Dec 25 09:57:55 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 13:57:55 +0400 Subject: RFR: 8067295 - Need to port Utils chagnes... 8067307: Need custom classloaders... 8067291: Need additional vm checks... In-Reply-To: <548B5603.5030902@oracle.com> References: <548B5603.5030902@oracle.com> Message-ID: <549BDFA3.1020904@oracle.com> Hi Dmitrij, all three changes looks good. Thanks, Filipp. On 12/13/2014 12:54 AM, Dmitrij Pochepko wrote: > Hi, > > Please review changes for > https://bugs.openjdk.java.net/browse/JDK-8067291 - Need additional vm checks > in jdk/test/lib/testlibrary/jdk/testlibrary/Platform, checking which vm is run > https://bugs.openjdk.java.net/browse/JDK-8067295 - Need to port Utils chagnes > from JDK-8059613 into jdk workspace > https://bugs.openjdk.java.net/browse/JDK-8067307 - Need custom > classloaders(parent-last and filtering one) for JDK-8066625 in testlibrary > > Description: A number of small testlibrary changes needed for further test > development, 2 of 3 is porn from respective hotspot changes > 3rd one (JDK-8067307) introduce 2 classloaders for testlibrary. 1st is > FilterClassLoader - loads classes using target classloader in case > class name meets provided condition, and using parent otherwise. 2nd is > ParentLastURLClassLoader which loads classes using provided URL[] with > fallback to parent, > > Webrevs: > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067291/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067295/webrev.00/ > http://cr.openjdk.java.net/~iignatyev/dpochepk/8067307/webrev.00/ > > Thanks, > Dmitrij From igor.ignatyev at oracle.com Thu Dec 25 10:05:27 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 13:05:27 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549B1D5D.8030908@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> Message-ID: <549BE167.8090305@oracle.com> I'd prefer to check privileges by running dtrace against dtrace; and do it in DtraceRunner::dtraceAvailable, smth like > result = false; > dtrace = getDtracePath(); > if ($dtrace) { > $dtrace $dtrace > result = $? == 0; > } > return $result; Igor On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: > Hi, > > i've placed a guard which skips test in case dtrace exits with non-zero > code. > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ > > Thanks, > Dmitrij >> Hi, >> >> There is one more issues related to these tests(not directly). >> Currently, dtrace tests can't be run in jprt, because dtrace require >> additional previleges for launching user. >> Perhaps it's just user to be granted previleges in jprt solaris hosts... >> Not sure about some guard in tests... the only way i know so far is to >> just try launching dtrace and parse output >> saying about missing previleges, but it doesn't seem to be good solution. >> I think test should assume to be launched in correct environment and >> in case it's failed because of previleges, evaluating engineer >> starting to work on respective env. issue... >> Does anybody have some additional concerns? >> >> Thanks, >> Dmitrij >> >>> Hi Dmitrij, >>> >>> >>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>> >>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>> 42 public static final String PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>> >>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>> >>> >>> Otherwise, looks good. >>> Please, consider it reviewed (no need to re-review). >>> >>> Thanks, >>> Serguei >>> >>> >>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>> Hi, >>>> please review updated webrev >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>> >>>> Thanks, >>>> Dmitrij >>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> Thank you for catching these issues. >>>>>> I have a question regarding last comment: does it make any >>>>>> difference to change "reading of static member 3 times" to >>>>>> "copying into static member of another class and then read it 3 >>>>>> times"? >>>>> >>>>> Yes, it does (it is a minor issue though). >>>>> It is because the class names are pretty big. >>>>> It would simplify the code and improve readability, right? >>>>> >>>>> You already do it two times: >>>>> 179 List tml >>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> ... >>>>> 235 List mlist >>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> >>>>> My suggestion is to do it once somewhere before the line 74: >>>>> static final List MLIST = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> and then use the mlist in other places where it is needed: >>>>> >>>>> 75 String params = MLIST.stream() >>>>> ... >>>>> 182 d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), >>>>> ... >>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>> These lines will go away: >>>>> 179 List tml >>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> ... >>>>> 235 List mlist >>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>> >>>>> >>>>> Both private static classes are inner classes of the public one. >>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>> no prefixing. >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> >>>>>>> It looks good in general. >>>>>>> Some minor comments are below. >>>>>>> >>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>> >>>>>>> 42 public static final String PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>> >>>>>>> >>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>> >>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>> >>>>>>> >>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>> ... >>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>> >>>>>>> 75 String params = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>> ... >>>>>>> 179 List tml >>>>>>> 180 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> ... >>>>>>> 235 List mlist >>>>>>> 236 = SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>> It can be cached at the top and re-used. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review changes for >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>> codecache feature >>>>>>>> >>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>> different combinations of available compile levels(and, in case >>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>> analyzing results using class >>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>> usefull common code. >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>> >>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>> also applied. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>> >>>>>> >>>>> >>>> >>> >> > From pavel.chistyakov at oracle.com Thu Dec 25 10:02:04 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Thu, 25 Dec 2014 13:02:04 +0300 Subject: RFR (XS): 8066497: Update c.o.j.t.ByteCodeLoader to be able really reload given class In-Reply-To: <549BDCF4.20906@oracle.com> References: <54872854.90806@oracle.com> <549BDCF4.20906@oracle.com> Message-ID: <549BE09C.1000209@oracle.com> Hi Igor, Filipp, Thank you for review. ------------ Regards, Pavel On 25.12.2014 12:46, Igor Ignatyev wrote: > Looks good to me. > > Igor > > On 12/09/2014 07:50 PM, Pavel Chistyakov wrote: >> Hi all, >> >> please review changes for: >> https://bugs.openjdk.java.net/browse/JDK-8066497 >> webrev: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8066497/webrev.00/ >> >> >> Problem: >> ByteCodeLoader allows one to load class with given name from existing >> bytecode. But if this class is already loaded by e.g. system classloader >> it cannot be redefined using another bytecode array because of >> delegation of loadClass call to parent classloader. >> >> Solution: >> override loadClass to break delegation for given className. >> >> Testing: manual >> >> ------------------- >> Thanks, >> Pavel From filipp.zhinkin at oracle.com Thu Dec 25 10:25:17 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 14:25:17 +0400 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BE167.8090305@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> Message-ID: <549BE60D.2060501@oracle.com> Hi Dmitrij, DtraceRunner::runDtrace prints warning in case of non-zero exit code. It means that the test will pass even if traced JVM crashed. I can name several issues that were found accidentally, because tests didn't care about a crash. Are there any other sane reasons for DTrace to return non-zero exit code except lack of privileges? Igor's suggestion will prevent us from running DTrace without required privileges, so I'd prefer to see the test failure instead of a warning in case of non-zero exit code returned by DTrace. Also, please add @bug to the test. Thanks, Filipp. On 12/25/2014 02:05 PM, Igor Ignatyev wrote: > I'd prefer to check privileges by running dtrace against dtrace; > and do it in DtraceRunner::dtraceAvailable, smth like > >> result = false; >> dtrace = getDtracePath(); >> if ($dtrace) { >> $dtrace $dtrace >> result = $? == 0; >> } >> return $result; > > > Igor > > On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >> Hi, >> >> i've placed a guard which skips test in case dtrace exits with non-zero >> code. >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >> >> Thanks, >> Dmitrij >>> Hi, >>> >>> There is one more issues related to these tests(not directly). >>> Currently, dtrace tests can't be run in jprt, because dtrace require >>> additional previleges for launching user. >>> Perhaps it's just user to be granted previleges in jprt solaris hosts... >>> Not sure about some guard in tests... the only way i know so far is to >>> just try launching dtrace and parse output >>> saying about missing previleges, but it doesn't seem to be good solution. >>> I think test should assume to be launched in correct environment and >>> in case it's failed because of previleges, evaluating engineer >>> starting to work on respective env. issue... >>> Does anybody have some additional concerns? >>> >>> Thanks, >>> Dmitrij >>> >>>> Hi Dmitrij, >>>> >>>> >>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>> >>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>> 42 public static final String >>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>> >>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>> >>>> >>>> Otherwise, looks good. >>>> Please, consider it reviewed (no need to re-review). >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> please review updated webrev >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thank you for catching these issues. >>>>>>> I have a question regarding last comment: does it make any >>>>>>> difference to change "reading of static member 3 times" to >>>>>>> "copying into static member of another class and then read it 3 >>>>>>> times"? >>>>>> >>>>>> Yes, it does (it is a minor issue though). >>>>>> It is because the class names are pretty big. >>>>>> It would simplify the code and improve readability, right? >>>>>> >>>>>> You already do it two times: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>> static final List MLIST = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> and then use the mlist in other places where it is needed: >>>>>> >>>>>> 75 String params = MLIST.stream() >>>>>> ... >>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>> MethodData(MLIST.get(i).getName(), >>>>>> ... >>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>> These lines will go away: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> >>>>>> Both private static classes are inner classes of the public one. >>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>> no prefixing. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> >>>>>>>> It looks good in general. >>>>>>>> Some minor comments are below. >>>>>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>> >>>>>>>> 42 public static final String >>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>> >>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>> ... >>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>> >>>>>>>> 75 String params = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>> ... >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>> It can be cached at the top and re-used. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review changes for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>> codecache feature >>>>>>>>> >>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>> analyzing results using class >>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>> usefull common code. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>> >>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>> also applied. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From dmitrij.pochepko at oracle.com Thu Dec 25 12:06:49 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 25 Dec 2014 15:06:49 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BE167.8090305@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> Message-ID: <549BFDD9.5060309@oracle.com> v.$next > I'd prefer to check privileges by running dtrace against dtrace; > and do it in DtraceRunner::dtraceAvailable, smth like > >> result = false; >> dtrace = getDtracePath(); >> if ($dtrace) { >> $dtrace $dtrace >> result = $? == 0; >> } >> return $result; > > > Igor > > On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >> Hi, >> >> i've placed a guard which skips test in case dtrace exits with non-zero >> code. >> >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >> >> Thanks, >> Dmitrij >>> Hi, >>> >>> There is one more issues related to these tests(not directly). >>> Currently, dtrace tests can't be run in jprt, because dtrace require >>> additional previleges for launching user. >>> Perhaps it's just user to be granted previleges in jprt solaris >>> hosts... >>> Not sure about some guard in tests... the only way i know so far is to >>> just try launching dtrace and parse output >>> saying about missing previleges, but it doesn't seem to be good >>> solution. >>> I think test should assume to be launched in correct environment and >>> in case it's failed because of previleges, evaluating engineer >>> starting to work on respective env. issue... >>> Does anybody have some additional concerns? >>> >>> Thanks, >>> Dmitrij >>> >>>> Hi Dmitrij, >>>> >>>> >>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>> >>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>> 42 public static final String >>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>> >>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>> 85 >>>> DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>> >>>> >>>> Otherwise, looks good. >>>> Please, consider it reviewed (no need to re-review). >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> please review updated webrev >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thank you for catching these issues. >>>>>>> I have a question regarding last comment: does it make any >>>>>>> difference to change "reading of static member 3 times" to >>>>>>> "copying into static member of another class and then read it 3 >>>>>>> times"? >>>>>> >>>>>> Yes, it does (it is a minor issue though). >>>>>> It is because the class names are pretty big. >>>>>> It would simplify the code and improve readability, right? >>>>>> >>>>>> You already do it two times: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>> static final List MLIST = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> and then use the mlist in other places where it is needed: >>>>>> >>>>>> 75 String params = MLIST.stream() >>>>>> ... >>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>> MethodData(MLIST.get(i).getName(), >>>>>> ... >>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>> 240 >>>>>> sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>> These lines will go away: >>>>>> 179 List tml >>>>>> 180 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> ... >>>>>> 235 List mlist >>>>>> 236 = >>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>> >>>>>> >>>>>> Both private static classes are inner classes of the public one. >>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>> no prefixing. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> Hi Dmitry, >>>>>>>> >>>>>>>> >>>>>>>> It looks good in general. >>>>>>>> Some minor comments are below. >>>>>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>> >>>>>>>> >>>>>>>> 42 public static final String >>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>> >>>>>>>> 84 >>>>>>>> DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>> >>>>>>>> >>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>> 61 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>> ... >>>>>>>> 80 >>>>>>>> runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>>> 81 >>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>> >>>>>>>> 75 String params = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>> ... >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>> It can be cached at the top and re-used. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review changes for >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>> codecache feature >>>>>>>>> >>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>> analyzing results using class >>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>> usefull common code. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>> >>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>> also applied. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- diff -r 89977bee2ddd test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,305 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import com.oracle.java.testlibrary.Asserts; +import com.oracle.java.testlibrary.JDKToolFinder; +import com.oracle.java.testlibrary.OutputAnalyzer; +import com.oracle.java.testlibrary.Utils; +import com.oracle.java.testlibrary.dtrace.DtraceResultsAnalyzer; +import com.oracle.java.testlibrary.dtrace.DtraceRunner; +import java.io.IOException; +import java.lang.reflect.Executable; +import java.nio.file.Files; +import java.nio.file.Paths; +import java.util.Arrays; +import java.util.Collections; +import java.util.HashMap; +import java.util.HashSet; +import java.util.List; +import java.util.Map; +import java.util.Random; +import java.util.Set; +import java.util.regex.Matcher; +import java.util.regex.Pattern; +import java.util.stream.Collectors; + +/* + * @test SegmentedCodeCacheDtraceTest + * @requires os.family=="solaris" + * @library /testlibrary /compiler/testlibrary + * @build SegmentedCodeCacheDtraceTestWorker + * @run main ClassFileInstaller sun.hotspot.WhiteBox + * sun.hotspot.WhiteBox$WhiteBoxPermission + * @run main/othervm/timeout=600 -Xbootclasspath/a:. -XX:+TieredCompilation + * -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI + * SegmentedCodeCacheDtraceTest + * @summary testing of dtrace for segmented code cache + */ +public class SegmentedCodeCacheDtraceTest { + + private static final String WORKER_CLASS_NAME + = SegmentedCodeCacheDtraceTestWorker.class.getName(); + private static final String JAVA_OPTS = " -XX:+DTraceMethodProbes " + + "-Xbootclasspath/a:" + System.getProperty("test.classes") + " " + + "-XX:+UnlockDiagnosticVMOptions " + + "-XX:+WhiteBoxAPI -XX:+SegmentedCodeCache " + + "-XX:CompileCommand=compileonly," + + WORKER_CLASS_NAME + "::* " + + " -classpath " + System.getProperty("test.class.path") + " " + + String.join(" ", Utils.getTestJavaOpts()); + private static final String DTRACE_SCRIPT + = "SegmentedCodeCacheDtraceTestScript.d"; + private static final List MLIST = + SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; + private static final int WORKER_METHODS_COUNT = MLIST.size(); + + private void runTest(TestCombination tc) { + String params = MLIST.stream() + .map(Executable::getName) + .map(x -> tc.data.get(x).compileLevel + " " + tc.data.get(x).isInlined) + .collect(Collectors.joining(" ")); + DtraceRunner runner = new DtraceRunner(); + runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, + WORKER_CLASS_NAME, params, Paths.get(System.getProperty("test.src"), + DTRACE_SCRIPT).toString(), + DtraceRunner.PERMIT_DESTRUCTIVE_ACTIONS_DTRACE_OPTION, + new SegmentedCodeCacheDtraceResultsAnalyzer()); + } + + private static TestCombination generateUniqueCombination( + int[] availableLevels, Set combinations) { + int len = availableLevels.length; + /* first, check if we're out of combinations. */ + int maxCombinationsCount + = (1 << WORKER_METHODS_COUNT) + * (int) Math.pow(len, WORKER_METHODS_COUNT); + if (combinations.size() == maxCombinationsCount) { + return null; + } + Random r = Utils.getRandomInstance(); + while (combinations.size() < maxCombinationsCount) { + int levels[] = new int[WORKER_METHODS_COUNT]; + boolean inlines[] = new boolean[WORKER_METHODS_COUNT]; + for (int i = 0; i < WORKER_METHODS_COUNT; i++) { + levels[i] = availableLevels[r.nextInt(len)]; + inlines[i] = r.nextBoolean(); + } + TestCombination tc = new TestCombination(levels, inlines); + if (combinations.add(tc)) { + return tc; + } + } + return null; + } + + public static void main(String args[]) { + int iterations + = Integer.getInteger("com.oracle.java.testlibrary.iterations", 1); + if (!DtraceRunner.dtraceAvailable()) { + System.out.println("INFO: There is no dtrace avaiable. Skipping."); + return; + } + int[] availableLevels = CompilerUtils.getAvailableCompilationLevels(); + // adding one more entry(zero) for interpeter + availableLevels + = Arrays.copyOf(availableLevels, availableLevels.length + 1); + Set combinations = new HashSet<>(); + for (int i = 0; i < iterations; i++) { + TestCombination tc + = generateUniqueCombination(availableLevels, combinations); + if (tc == null) { + System.out.println("INFO: no more combinations available"); + return; + } else { + System.out.println("INFO: Running testcase for: " + tc); + new SegmentedCodeCacheDtraceTest().runTest(tc); + } + } + } + + private static class MethodData { + + public final int compileLevel; + public final boolean isInlined; + public final String name; + + public MethodData(String name, int compileLevel, boolean isInlined) { + this.name = name; + this.compileLevel = compileLevel; + this.isInlined = isInlined; + } + + @Override + public boolean equals(Object o) { + if (o == null || !(o instanceof MethodData)) { + return false; + } + MethodData md = (MethodData) o; + return md.compileLevel == compileLevel + && md.isInlined == isInlined + && md.name.equals(name); + } + + @Override + public int hashCode() { + return 100 * name.hashCode() + 10 * compileLevel + (isInlined ? 1 : 0); + } + + @Override + public String toString() { + return name + " " + compileLevel + " " + isInlined; + } + } + + private static class TestCombination { + + private final Map data; + + public TestCombination(int compLevels[], boolean inlines[]) { + Map d = new HashMap<>(); + for (int i = 0; i < MLIST.size(); i++) { + d.put(MLIST.get(i).getName(), new MethodData(MLIST.get(i).getName(), + compLevels[i], inlines[i])); + } + data = Collections.unmodifiableMap(d); + } + + @Override + public boolean equals(Object o) { + if (o == null || !(o instanceof TestCombination)) { + return false; + } + TestCombination second = (TestCombination) o; + return second.data.equals(data); + } + + @Override + public int hashCode() { + int sum = 0; + for (MethodData md : data.values()) { + sum += md.hashCode(); + } + return sum; + } + + private String getMethodDescString(MethodData md) { + return (md == null) + ? null + : String.format("Method %s compilation level %d and %s", + md.name, md.compileLevel, + md.isInlined ? "inlined" : "not inlined"); + } + + @Override + public String toString() { + return data.values().stream().map(m -> getMethodDescString(m)) + .collect(Collectors.joining(Utils.NEW_LINE, + "Combination: ", "")); + } + } + + private class SegmentedCodeCacheDtraceResultsAnalyzer + implements DtraceResultsAnalyzer { + + private static final int EXPECTED_MATCH_COUNT = 2; + + private final Pattern checkPattern; + + public SegmentedCodeCacheDtraceResultsAnalyzer() { + String workerClassRegExp = "\\s*" + WORKER_CLASS_NAME + "\\."; + String delimeter = "\\(\\)V\\*?" + workerClassRegExp; + String suffix = "test\\(\\)V\\*?" + workerClassRegExp + + "main\\(\\[Ljava\\/lang\\/String;\\)V"; + StringBuilder sb = new StringBuilder(workerClassRegExp); + // method order is important, so, going from list tail to head, + // accoring to call order representation in stacktrace + for (int i = MLIST.size() - 1; i > -1; i--) { + sb.append(MLIST.get(i).getName()).append(delimeter); + } + sb.append(suffix); + checkPattern = Pattern.compile(sb.toString()); + /* such pattern match should pass on a stacktrace like + CPU ID FUNCTION:NAME + 0 53573 __1cNSharedRuntimeTdtrace_method_entry6FpnKJavaThread_pnGMethod__i_:method-entry ustack: + + libjvm.so`__1cNSharedRuntimeTdtrace_method_entry6FpnKJavaThread_pnGMethod__i_+0x39c + SegmentedCodeCacheDtraceTestWorker.baz()V* + SegmentedCodeCacheDtraceTestWorker.bar()V + SegmentedCodeCacheDtraceTestWorker.foo()V* + SegmentedCodeCacheDtraceTestWorker.test()V + SegmentedCodeCacheDtraceTestWorker.main([Ljava/lang/String;)V + 0xffffffff6b0004b8 + libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x94c + libjvm.so`__1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_ArgumentPusher_pnGThread__v_+0xa64 + libjvm.so`jni_CallStaticVoidMethod+0x508 + libjli.so`JavaMain+0x584 + libc.so.1`_lwp_start + jstack: + + libjvm.so`__1cNSharedRuntimeTdtrace_method_entry6FpnKJavaThread_pnGMethod__i_+0x39c + SegmentedCodeCacheDtraceTestWorker.baz()V* + SegmentedCodeCacheDtraceTestWorker.bar()V + SegmentedCodeCacheDtraceTestWorker.foo()V* + SegmentedCodeCacheDtraceTestWorker.test()V + SegmentedCodeCacheDtraceTestWorker.main([Ljava/lang/String;)V + 0xffffffff6b0004b8 + libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x94c + libjvm.so`__1cRjni_invoke_static6FpnHJNIEnv__pnJJavaValue_pnI_jobject_nLJNICallType_pnK_jmethodID_pnSJNI_ArgumentPusher_pnGThread__v_+0xa64 + libjvm.so`jni_CallStaticVoidMethod+0x508 + libjli.so`JavaMain+0x584 + libc.so.1`_lwp_start + */ + } + + protected List loadLog(String dtraceOutFile) throws IOException { + return Files.readAllLines(Paths.get(dtraceOutFile)); + } + + @Override + public void analyze(OutputAnalyzer oa, String dtraceOutFilePath) { + List dOut; + try { + dOut = loadLog(dtraceOutFilePath); + } catch (IOException e) { + throw new Error("Can't load log", e); + } + StringBuilder allDtraceOutput = new StringBuilder(); + for (String entry : dOut) { + allDtraceOutput.append(entry); + } + int matchCount = getMatchCount(allDtraceOutput.toString()); + Asserts.assertEQ(matchCount, EXPECTED_MATCH_COUNT, + "Unexpected output match amount. expected: " + + EXPECTED_MATCH_COUNT + " but found " + matchCount); + } + + protected int getMatchCount(String source) { + Matcher m = checkPattern.matcher(source); + int matchCount = 0; + while (m.find()) { + matchCount++; + } + return matchCount; + } + } +} diff -r 89977bee2ddd test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestScript.d --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestScript.d Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,33 @@ +#!/usr/sbin/dtrace -s + +/* + Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + + This code is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License version 2 only, as + published by the Free Software Foundation. + + This code is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + version 2 for more details (a copy is included in the LICENSE file that + accompanied this code). + + You should have received a copy of the GNU General Public License version + 2 along with this work; if not, write to the Free Software Foundation, + Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + + Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + or visit www.oracle.com if you need additional information or have any + questions. +*/ + +hotspot$target:::method-entry +/ copyinstr(arg3, arg4) == "baz" / +{ + printf("ustack:\n"); + ustack(50, 500); + printf("jstack:\n"); + jstack(); +} diff -r 89977bee2ddd test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestWorker.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTestWorker.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,113 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import com.oracle.java.testlibrary.Utils; +import java.lang.reflect.Executable; +import java.util.ArrayList; +import java.util.Arrays; +import java.util.Collections; +import java.util.List; +import sun.hotspot.WhiteBox; + +public class SegmentedCodeCacheDtraceTestWorker { + + private static final String METHOD1_NAME = "foo"; + private static final String METHOD2_NAME = "bar"; + private static final String METHOD3_NAME = "baz"; + public static final List TESTED_METHODS_LIST; + private final WhiteBox wb; + private final int compLevels[]; + + static { + List methods = new ArrayList<>(); + try { + // method order is important. Need to place methods in call order, + // to be able to verify results later + methods.add(SegmentedCodeCacheDtraceTestWorker.class.getMethod(METHOD1_NAME)); + methods.add(SegmentedCodeCacheDtraceTestWorker.class.getMethod(METHOD2_NAME)); + methods.add(SegmentedCodeCacheDtraceTestWorker.class.getMethod(METHOD3_NAME)); + } catch (NoSuchMethodException e) { + throw new Error("TESTBUG: no expected method found", e); + } + TESTED_METHODS_LIST = Collections.unmodifiableList(methods); + } + + protected static final boolean BACKGROUND_COMPILATION + = WhiteBox.getWhiteBox().getBooleanVMFlag("BackgroundCompilation"); + + public static void main(String[] args) { + if (args.length != 2 * TESTED_METHODS_LIST.size()) { + throw new Error("Usage: java " + + " " + + " "); + } else { + int compLevels[] = new int[TESTED_METHODS_LIST.size()]; + boolean inlines[] = new boolean[TESTED_METHODS_LIST.size()]; + for (int i = 0; i < TESTED_METHODS_LIST.size(); i++) { + compLevels[i] = Integer.parseInt(args[2 * i]); + inlines[i] = Boolean.parseBoolean(args[2 * i + 1]); + } + new SegmentedCodeCacheDtraceTestWorker(compLevels, inlines).test(); + } + } + + public SegmentedCodeCacheDtraceTestWorker(int compLevels[], boolean inlines[]) { + wb = WhiteBox.getWhiteBox(); + this.compLevels = Arrays.copyOf(compLevels, compLevels.length); + for (int i = 0; i < compLevels.length; i++) { + if (inlines[i]) { + wb.testSetForceInlineMethod(TESTED_METHODS_LIST.get(i), true); + } else { + wb.testSetDontInlineMethod(TESTED_METHODS_LIST.get(i), true); + } + } + } + + private void waitForCompilation(Executable executable, int compLevel) { + if (compLevel > 0) { + Utils.waitForCondition(() -> wb.isMethodCompiled(executable)); + } + } + + protected void test() { + for (int i = 0; i < TESTED_METHODS_LIST.size(); i++) { + Executable method = TESTED_METHODS_LIST.get(i); + int compLevel = compLevels[i]; + wb.enqueueMethodForCompilation(method, compLevel); + waitForCompilation(method, compLevel); + } + foo(); + } + + public static void foo() { + bar(); + } + + public static void bar() { + baz(); + } + + public static void baz() { + System.out.println("Reached baz method"); + } +} diff -r 89977bee2ddd test/compiler/testlibrary/CompilerUtils.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/compiler/testlibrary/CompilerUtils.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,61 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +import com.oracle.java.testlibrary.Asserts; +import com.oracle.java.testlibrary.Platform; +import java.util.stream.IntStream; +import sun.hotspot.WhiteBox; + +public class CompilerUtils { + + private CompilerUtils() { + // to prevent from instantiation + } + + /** + * Returns available compilation levels + * + * @return int array with compilation levels + */ + public static int[] getAvailableCompilationLevels() { + if (!WhiteBox.getWhiteBox().getBooleanVMFlag("UseCompiler")) { + return new int[0]; + } + if (WhiteBox.getWhiteBox().getBooleanVMFlag("TieredCompilation")) { + Long flagValue = WhiteBox.getWhiteBox() + .getIntxVMFlag("TieredStopAtLevel"); + int maxLevel = flagValue.intValue(); + Asserts.assertEQ(new Long(maxLevel), flagValue, + "TieredStopAtLevel has value out of int capacity"); + return IntStream.rangeClosed(1, maxLevel).toArray(); + } else { + if (Platform.isServer()) { + return new int[]{4}; + } + if (Platform.isClient() || Platform.isMinimal()) { + return new int[]{1}; + } + } + return new int[0]; + } +} diff -r 89977bee2ddd test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceResultsAnalyzer.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceResultsAnalyzer.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,29 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ +package com.oracle.java.testlibrary.dtrace; + +import com.oracle.java.testlibrary.OutputAnalyzer; + +public interface DtraceResultsAnalyzer { + public void analyze(OutputAnalyzer oa, String logFilePath); +} diff -r 89977bee2ddd test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java Thu Dec 25 15:06:23 2014 +0300 @@ -0,0 +1,122 @@ +/* + * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ +package com.oracle.java.testlibrary.dtrace; + +import com.oracle.java.testlibrary.Asserts; +import com.oracle.java.testlibrary.OutputAnalyzer; +import java.io.File; +import java.io.IOException; +import java.util.ArrayList; +import java.util.List; + +public class DtraceRunner { + + private static final String DTRACE_DEFAULT_PATH = "/usr/sbin/dtrace"; + private static final String DTRACE_PATH_PROPERTY + = "com.oracle.test.dtrace.path"; + private static final String OUTPUT_FILE_DTRACE_OPTION = "o"; + private static final String RUN_COMMAND_DTRACE_OPTION = "c"; + private static final String RUN_SCRIPT_DTRACE_OPTION = "s"; + private static final String ALLOW_ZERO_PROBE_DESCRIPTION_DTRACE_OPTION = "Z"; + private static final String DTRACE_OPTION_PREFIX = "-"; + public static final String PERMIT_DESTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; + public static final String DTRACE_OUT_LOG = "dtrace.out"; + + private final String dtraceExecutable; + + public DtraceRunner() { + dtraceExecutable = getDtracePath(); + } + + private List getLaunchCmd(String java, String javaOpts, + String execClass, String testArgs, String dtraceScript, + String dtraceAddOpts) { + Asserts.assertTrue(!java.matches("\\s"), "Current dtrace implementation" + + " can't handle whitespaces in application path"); + List result = new ArrayList<>(); + result.add(dtraceExecutable); + result.add(DTRACE_OPTION_PREFIX + System.getProperty("sun.arch.data.model")); + result.add(DTRACE_OPTION_PREFIX + + ALLOW_ZERO_PROBE_DESCRIPTION_DTRACE_OPTION + + ((dtraceAddOpts == null) ? "" : dtraceAddOpts) + + RUN_SCRIPT_DTRACE_OPTION); // run_script should be last one + result.add(dtraceScript); + result.add(DTRACE_OPTION_PREFIX + OUTPUT_FILE_DTRACE_OPTION); + result.add(DTRACE_OUT_LOG); + result.add(DTRACE_OPTION_PREFIX + RUN_COMMAND_DTRACE_OPTION); + result.add(java + " " + javaOpts + " " + execClass + " " + testArgs); + return result; + } + + private void backupLogFile(File file) { + if (file.exists()) { + file.renameTo(new File(file.getPath() + ".bak")); + } + } + + public void runDtrace(String java, String javaOpts, String execClass, + String testArgs, String dtraceScript, String dtraceAddOpts, + DtraceResultsAnalyzer analyzer) { + backupLogFile(new File(DTRACE_OUT_LOG)); + ProcessBuilder pbuilder = new ProcessBuilder( + getLaunchCmd(java, javaOpts, execClass, testArgs, + dtraceScript, dtraceAddOpts)); + OutputAnalyzer oa; + try { + oa = new OutputAnalyzer(pbuilder.start()); + } catch (IOException e) { + throw new Error("TESTBUG: Can't start process", e); + } + analyzer.analyze(oa, DTRACE_OUT_LOG); + } + + public static boolean dtraceAvailable() { + String path = getDtracePath(); + if (path == null) { + return false; + } + // now we'll launch dtrace to trace itself just to be sure it works + // and have all additional previleges set + ProcessBuilder pbuilder = new ProcessBuilder(path, path); + try { + Process proc = pbuilder.start(); + proc.waitFor(); + if (proc.exitValue() != 0) { + return false; + } + } catch (IOException | InterruptedException e) { + return false; + } + return true; + } + + private static String getDtracePath() { + String propPath = System.getProperty(DTRACE_PATH_PROPERTY); + if (propPath != null && new File(propPath).exists()) { + return propPath; + } else if (new File(DTRACE_DEFAULT_PATH).exists()) { + return DTRACE_DEFAULT_PATH; + } + return null; + } +} From dmitrij.pochepko at oracle.com Thu Dec 25 12:19:06 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 25 Dec 2014 15:19:06 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BE60D.2060501@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> Message-ID: <549C00BA.6040106@oracle.com> Hi, new webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 I've added @bug tag and moved process guard to DtraceRunner::dtraceAvailable Thanks, Dmitrij > Hi Dmitrij, > > DtraceRunner::runDtrace prints warning in case of non-zero exit code. > It means that the test will pass even if traced JVM crashed. > > I can name several issues that were found accidentally, because tests > didn't care about a crash. > > Are there any other sane reasons for DTrace to return non-zero exit code > except lack of privileges? > Igor's suggestion will prevent us from running DTrace without required > privileges, so I'd prefer to see the test failure instead of a warning > in case > of non-zero exit code returned by DTrace. > > Also, please add @bug to the test. > > Thanks, > Filipp. > > On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >> I'd prefer to check privileges by running dtrace against dtrace; >> and do it in DtraceRunner::dtraceAvailable, smth like >> >>> result = false; >>> dtrace = getDtracePath(); >>> if ($dtrace) { >>> $dtrace $dtrace >>> result = $? == 0; >>> } >>> return $result; >> >> >> Igor >> >> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> i've placed a guard which skips test in case dtrace exits with non-zero >>> code. >>> >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>> >>> Thanks, >>> Dmitrij >>>> Hi, >>>> >>>> There is one more issues related to these tests(not directly). >>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>> additional previleges for launching user. >>>> Perhaps it's just user to be granted previleges in jprt solaris >>>> hosts... >>>> Not sure about some guard in tests... the only way i know so far is to >>>> just try launching dtrace and parse output >>>> saying about missing previleges, but it doesn't seem to be good >>>> solution. >>>> I think test should assume to be launched in correct environment and >>>> in case it's failed because of previleges, evaluating engineer >>>> starting to work on respective env. issue... >>>> Does anybody have some additional concerns? >>>> >>>> Thanks, >>>> Dmitrij >>>> >>>>> Hi Dmitrij, >>>>> >>>>> >>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>> >>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>> 42 public static final String >>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>> >>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>> >>>>> >>>>> Otherwise, looks good. >>>>> Please, consider it reviewed (no need to re-review). >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> please review updated webrev >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Thank you for catching these issues. >>>>>>>> I have a question regarding last comment: does it make any >>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>> times"? >>>>>>> >>>>>>> Yes, it does (it is a minor issue though). >>>>>>> It is because the class names are pretty big. >>>>>>> It would simplify the code and improve readability, right? >>>>>>> >>>>>>> You already do it two times: >>>>>>> 179 List tml >>>>>>> 180 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> ... >>>>>>> 235 List mlist >>>>>>> 236 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> >>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>> static final List MLIST = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> and then use the mlist in other places where it is needed: >>>>>>> >>>>>>> 75 String params = MLIST.stream() >>>>>>> ... >>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>> ... >>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>> These lines will go away: >>>>>>> 179 List tml >>>>>>> 180 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> ... >>>>>>> 235 List mlist >>>>>>> 236 = >>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>> >>>>>>> >>>>>>> Both private static classes are inner classes of the public one. >>>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>>> no prefixing. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> >>>>>>>>> It looks good in general. >>>>>>>>> Some minor comments are below. >>>>>>>>> >>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>> >>>>>>>>> >>>>>>>>> 42 public static final String >>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>> >>>>>>>>> >>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>> >>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>> >>>>>>>>> >>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>> 61 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>> ... >>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>> JAVA_OPTS, >>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>> >>>>>>>>> 75 String params = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>> ... >>>>>>>>> 179 List tml >>>>>>>>> 180 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> ... >>>>>>>>> 235 List mlist >>>>>>>>> 236 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>> It can be cached at the top and re-used. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review changes for >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>> codecache feature >>>>>>>>>> >>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>> analyzing results using class >>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>> usefull common code. >>>>>>>>>> >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>> also applied. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From igor.ignatyev at oracle.com Thu Dec 25 12:19:13 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 15:19:13 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C00BA.6040106@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> Message-ID: <549C00C1.2020001@oracle.com> looks good to me. Thanks, Igor On 12/25/2014 03:19 PM, Dmitrij Pochepko wrote: > Hi, > > new webrev: > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 > I've added @bug tag > and moved process guard to DtraceRunner::dtraceAvailable > > Thanks, > Dmitrij >> Hi Dmitrij, >> >> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >> It means that the test will pass even if traced JVM crashed. >> >> I can name several issues that were found accidentally, because tests >> didn't care about a crash. >> >> Are there any other sane reasons for DTrace to return non-zero exit code >> except lack of privileges? >> Igor's suggestion will prevent us from running DTrace without required >> privileges, so I'd prefer to see the test failure instead of a warning >> in case >> of non-zero exit code returned by DTrace. >> >> Also, please add @bug to the test. >> >> Thanks, >> Filipp. >> >> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>> I'd prefer to check privileges by running dtrace against dtrace; >>> and do it in DtraceRunner::dtraceAvailable, smth like >>> >>>> result = false; >>>> dtrace = getDtracePath(); >>>> if ($dtrace) { >>>> $dtrace $dtrace >>>> result = $? == 0; >>>> } >>>> return $result; >>> >>> >>> Igor >>> >>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> i've placed a guard which skips test in case dtrace exits with non-zero >>>> code. >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi, >>>>> >>>>> There is one more issues related to these tests(not directly). >>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>> additional previleges for launching user. >>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>> hosts... >>>>> Not sure about some guard in tests... the only way i know so far is to >>>>> just try launching dtrace and parse output >>>>> saying about missing previleges, but it doesn't seem to be good >>>>> solution. >>>>> I think test should assume to be launched in correct environment and >>>>> in case it's failed because of previleges, evaluating engineer >>>>> starting to work on respective env. issue... >>>>> Does anybody have some additional concerns? >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>> >>>>>> Hi Dmitrij, >>>>>> >>>>>> >>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>> >>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>> 42 public static final String >>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>> >>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>> >>>>>> >>>>>> Otherwise, looks good. >>>>>> Please, consider it reviewed (no need to re-review). >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> please review updated webrev >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Thank you for catching these issues. >>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>> times"? >>>>>>>> >>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>> It is because the class names are pretty big. >>>>>>>> It would simplify the code and improve readability, right? >>>>>>>> >>>>>>>> You already do it two times: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>> static final List MLIST = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>> >>>>>>>> 75 String params = MLIST.stream() >>>>>>>> ... >>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>> ... >>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>> These lines will go away: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> >>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>>>> no prefixing. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It looks good in general. >>>>>>>>>> Some minor comments are below. >>>>>>>>>> >>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 42 public static final String >>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>> >>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>> 61 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>> ... >>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>> JAVA_OPTS, >>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>> >>>>>>>>>> 75 String params = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>> ... >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review changes for >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>> codecache feature >>>>>>>>>>> >>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>> analyzing results using class >>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>> usefull common code. >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>> also applied. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From filipp.zhinkin at oracle.com Thu Dec 25 12:12:45 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 16:12:45 +0400 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C00BA.6040106@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> Message-ID: <549BFF3D.2060905@oracle.com> Dmitrij, I believe that it should be "@bug 8015774". Now DtraceRunner::runDtrace isn't checking exit code at all. I think that it should assert on zero exit code. Thanks, Filipp. On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: > Hi, > > new webrev: http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 > I've added @bug tag > and moved process guard to DtraceRunner::dtraceAvailable > > Thanks, > Dmitrij >> Hi Dmitrij, >> >> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >> It means that the test will pass even if traced JVM crashed. >> >> I can name several issues that were found accidentally, because tests >> didn't care about a crash. >> >> Are there any other sane reasons for DTrace to return non-zero exit code >> except lack of privileges? >> Igor's suggestion will prevent us from running DTrace without required >> privileges, so I'd prefer to see the test failure instead of a warning in case >> of non-zero exit code returned by DTrace. >> >> Also, please add @bug to the test. >> >> Thanks, >> Filipp. >> >> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>> I'd prefer to check privileges by running dtrace against dtrace; >>> and do it in DtraceRunner::dtraceAvailable, smth like >>> >>>> result = false; >>>> dtrace = getDtracePath(); >>>> if ($dtrace) { >>>> $dtrace $dtrace >>>> result = $? == 0; >>>> } >>>> return $result; >>> >>> >>> Igor >>> >>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> i've placed a guard which skips test in case dtrace exits with non-zero >>>> code. >>>> >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi, >>>>> >>>>> There is one more issues related to these tests(not directly). >>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>> additional previleges for launching user. >>>>> Perhaps it's just user to be granted previleges in jprt solaris hosts... >>>>> Not sure about some guard in tests... the only way i know so far is to >>>>> just try launching dtrace and parse output >>>>> saying about missing previleges, but it doesn't seem to be good solution. >>>>> I think test should assume to be launched in correct environment and >>>>> in case it's failed because of previleges, evaluating engineer >>>>> starting to work on respective env. issue... >>>>> Does anybody have some additional concerns? >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>> >>>>>> Hi Dmitrij, >>>>>> >>>>>> >>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>> >>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>> 42 public static final String >>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>> >>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>> >>>>>> >>>>>> Otherwise, looks good. >>>>>> Please, consider it reviewed (no need to re-review). >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> please review updated webrev >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Thank you for catching these issues. >>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>> times"? >>>>>>>> >>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>> It is because the class names are pretty big. >>>>>>>> It would simplify the code and improve readability, right? >>>>>>>> >>>>>>>> You already do it two times: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>> static final List MLIST = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>> >>>>>>>> 75 String params = MLIST.stream() >>>>>>>> ... >>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>> ... >>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>> These lines will go away: >>>>>>>> 179 List tml >>>>>>>> 180 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> ... >>>>>>>> 235 List mlist >>>>>>>> 236 = >>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>> >>>>>>>> >>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>> The MLIST will be in a context for the inner classes, and so, needs >>>>>>>> no prefixing. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>>>> Hi Dmitry, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It looks good in general. >>>>>>>>>> Some minor comments are below. >>>>>>>>>> >>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>> >>>>>>>>>> 42 public static final String >>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>> >>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>> 61 = SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>> ... >>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), JAVA_OPTS, >>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), params, >>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>> >>>>>>>>>> 75 String params = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>> ... >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review changes for >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>> codecache feature >>>>>>>>>>> >>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>> script is also present (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>> analyzing results using class >>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>> usefull common code. >>>>>>>>>>> >>>>>>>>>>> webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Additional note: Please note that this path assumes that fix for >>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>> also applied. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From igor.ignatyev at oracle.com Thu Dec 25 12:22:52 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 15:22:52 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549BFF3D.2060905@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> <549BFF3D.2060905@oracle.com> Message-ID: <549C019C.4070803@oracle.com> On 12/25/2014 03:12 PM, Filipp Zhinkin wrote: > Dmitrij, > > I believe that it should be "@bug 8015774". agree > > Now DtraceRunner::runDtrace isn't checking exit code at all. > I think that it should assert on zero exit code. no, it shouldn't it should be a part of custom implementation of DtraceResultsAnalyzer::analyze. Dima, could you please add exit code check into SegmentedCodeCacheDtraceTest.SegmentedCodeCacheDtraceResultsAnalyzer::analyze > > Thanks, > Filipp. > > On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: >> Hi, >> >> new webrev: >> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 >> I've added @bug tag >> and moved process guard to DtraceRunner::dtraceAvailable >> >> Thanks, >> Dmitrij >>> Hi Dmitrij, >>> >>> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >>> It means that the test will pass even if traced JVM crashed. >>> >>> I can name several issues that were found accidentally, because tests >>> didn't care about a crash. >>> >>> Are there any other sane reasons for DTrace to return non-zero exit code >>> except lack of privileges? >>> Igor's suggestion will prevent us from running DTrace without required >>> privileges, so I'd prefer to see the test failure instead of a >>> warning in case >>> of non-zero exit code returned by DTrace. >>> >>> Also, please add @bug to the test. >>> >>> Thanks, >>> Filipp. >>> >>> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>>> I'd prefer to check privileges by running dtrace against dtrace; >>>> and do it in DtraceRunner::dtraceAvailable, smth like >>>> >>>>> result = false; >>>>> dtrace = getDtracePath(); >>>>> if ($dtrace) { >>>>> $dtrace $dtrace >>>>> result = $? == 0; >>>>> } >>>>> return $result; >>>> >>>> >>>> Igor >>>> >>>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> i've placed a guard which skips test in case dtrace exits with >>>>> non-zero >>>>> code. >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>>> >>>>> Thanks, >>>>> Dmitrij >>>>>> Hi, >>>>>> >>>>>> There is one more issues related to these tests(not directly). >>>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>>> additional previleges for launching user. >>>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>>> hosts... >>>>>> Not sure about some guard in tests... the only way i know so far >>>>>> is to >>>>>> just try launching dtrace and parse output >>>>>> saying about missing previleges, but it doesn't seem to be good >>>>>> solution. >>>>>> I think test should assume to be launched in correct environment and >>>>>> in case it's failed because of previleges, evaluating engineer >>>>>> starting to work on respective env. issue... >>>>>> Does anybody have some additional concerns? >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>> >>>>>>> Hi Dmitrij, >>>>>>> >>>>>>> >>>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>>> >>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>> >>>>>>> 42 public static final String >>>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>> >>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>> >>>>>>> >>>>>>> Otherwise, looks good. >>>>>>> Please, consider it reviewed (no need to re-review). >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi, >>>>>>>> please review updated webrev >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Thank you for catching these issues. >>>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>>> times"? >>>>>>>>> >>>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>>> It is because the class names are pretty big. >>>>>>>>> It would simplify the code and improve readability, right? >>>>>>>>> >>>>>>>>> You already do it two times: >>>>>>>>> 179 List tml >>>>>>>>> 180 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> ... >>>>>>>>> 235 List mlist >>>>>>>>> 236 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> >>>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>>> static final List MLIST = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>>> >>>>>>>>> 75 String params = MLIST.stream() >>>>>>>>> ... >>>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>>> ... >>>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>>> These lines will go away: >>>>>>>>> 179 List tml >>>>>>>>> 180 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> ... >>>>>>>>> 235 List mlist >>>>>>>>> 236 = >>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>> >>>>>>>>> >>>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>>> The MLIST will be in a context for the inner classes, and so, >>>>>>>>> needs >>>>>>>>> no prefixing. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It looks good in general. >>>>>>>>>>> Some minor comments are below. >>>>>>>>>>> >>>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 42 public static final String >>>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>>> >>>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>>> 61 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>>> ... >>>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>>> JAVA_OPTS, >>>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), >>>>>>>>>>> params, >>>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>>> >>>>>>>>>>> 75 String params = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>>> ... >>>>>>>>>>> 179 List tml >>>>>>>>>>> 180 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> ... >>>>>>>>>>> 235 List mlist >>>>>>>>>>> 236 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review changes for >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>>> codecache feature >>>>>>>>>>>> >>>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>>> script is also present >>>>>>>>>>>> (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>>> analyzing results using class >>>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>>> usefull common code. >>>>>>>>>>>> >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Additional note: Please note that this path assumes that fix >>>>>>>>>>>> for >>>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>>> also applied. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dmitrij >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From dmitrij.pochepko at oracle.com Thu Dec 25 13:04:52 2014 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 25 Dec 2014 16:04:52 +0300 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C019C.4070803@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> <549BFF3D.2060905@oracle.com> <549C019C.4070803@oracle.com> Message-ID: <549C0B74.6000900@oracle.com> Hi, please take a look at fixed version http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.04 Thanks, Dmitrij > > On 12/25/2014 03:12 PM, Filipp Zhinkin wrote: >> Dmitrij, >> >> I believe that it should be "@bug 8015774". > agree >> >> Now DtraceRunner::runDtrace isn't checking exit code at all. >> I think that it should assert on zero exit code. > no, it shouldn't it should be a part of custom implementation of > DtraceResultsAnalyzer::analyze. > > Dima, could you please add exit code check into > SegmentedCodeCacheDtraceTest.SegmentedCodeCacheDtraceResultsAnalyzer::analyze > >> >> Thanks, >> Filipp. >> >> On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: >>> Hi, >>> >>> new webrev: >>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 >>> I've added @bug tag >>> and moved process guard to DtraceRunner::dtraceAvailable >>> >>> Thanks, >>> Dmitrij >>>> Hi Dmitrij, >>>> >>>> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >>>> It means that the test will pass even if traced JVM crashed. >>>> >>>> I can name several issues that were found accidentally, because tests >>>> didn't care about a crash. >>>> >>>> Are there any other sane reasons for DTrace to return non-zero exit >>>> code >>>> except lack of privileges? >>>> Igor's suggestion will prevent us from running DTrace without required >>>> privileges, so I'd prefer to see the test failure instead of a >>>> warning in case >>>> of non-zero exit code returned by DTrace. >>>> >>>> Also, please add @bug to the test. >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>>>> I'd prefer to check privileges by running dtrace against dtrace; >>>>> and do it in DtraceRunner::dtraceAvailable, smth like >>>>> >>>>>> result = false; >>>>>> dtrace = getDtracePath(); >>>>>> if ($dtrace) { >>>>>> $dtrace $dtrace >>>>>> result = $? == 0; >>>>>> } >>>>>> return $result; >>>>> >>>>> >>>>> Igor >>>>> >>>>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> i've placed a guard which skips test in case dtrace exits with >>>>>> non-zero >>>>>> code. >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>>>>> Hi, >>>>>>> >>>>>>> There is one more issues related to these tests(not directly). >>>>>>> Currently, dtrace tests can't be run in jprt, because dtrace >>>>>>> require >>>>>>> additional previleges for launching user. >>>>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>>>> hosts... >>>>>>> Not sure about some guard in tests... the only way i know so far >>>>>>> is to >>>>>>> just try launching dtrace and parse output >>>>>>> saying about missing previleges, but it doesn't seem to be good >>>>>>> solution. >>>>>>> I think test should assume to be launched in correct environment >>>>>>> and >>>>>>> in case it's failed because of previleges, evaluating engineer >>>>>>> starting to work on respective env. issue... >>>>>>> Does anybody have some additional concerns? >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>> >>>>>>>> Hi Dmitrij, >>>>>>>> >>>>>>>> >>>>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>>>> >>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>> >>>>>>>> >>>>>>>> 42 public static final String >>>>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>> >>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>> >>>>>>>> >>>>>>>> Otherwise, looks good. >>>>>>>> Please, consider it reviewed (no need to re-review). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>>>> Hi, >>>>>>>>> please review updated webrev >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dmitrij >>>>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Thank you for catching these issues. >>>>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>>>> times"? >>>>>>>>>> >>>>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>>>> It is because the class names are pretty big. >>>>>>>>>> It would simplify the code and improve readability, right? >>>>>>>>>> >>>>>>>>>> You already do it two times: >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> >>>>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>>>> static final List MLIST = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>>>> >>>>>>>>>> 75 String params = MLIST.stream() >>>>>>>>>> ... >>>>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>>>> ... >>>>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>>>> These lines will go away: >>>>>>>>>> 179 List tml >>>>>>>>>> 180 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> ... >>>>>>>>>> 235 List mlist >>>>>>>>>> 236 = >>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>>>> The MLIST will be in a context for the inner classes, and so, >>>>>>>>>> needs >>>>>>>>>> no prefixing. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Dmitrij >>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It looks good in general. >>>>>>>>>>>> Some minor comments are below. >>>>>>>>>>>> >>>>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 42 public static final String >>>>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>>>> 61 = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>>>> ... >>>>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>>>> JAVA_OPTS, >>>>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), >>>>>>>>>>>> params, >>>>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>>>> >>>>>>>>>>>> 75 String params = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> 179 List tml >>>>>>>>>>>> 180 = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>> ... >>>>>>>>>>>> 235 List mlist >>>>>>>>>>>> 236 = >>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>>>> codecache feature >>>>>>>>>>>>> >>>>>>>>>>>>> Description: this fix introduce dtrace test, which verify >>>>>>>>>>>>> that >>>>>>>>>>>>> different combinations of available compile levels(and, in >>>>>>>>>>>>> case >>>>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A >>>>>>>>>>>>> dtrace d >>>>>>>>>>>>> script is also present >>>>>>>>>>>>> (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and >>>>>>>>>>>>> then >>>>>>>>>>>>> analyzing results using class >>>>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>>>> usefull common code. >>>>>>>>>>>>> >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Additional note: Please note that this path assumes that fix >>>>>>>>>>>>> for >>>>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for >>>>>>>>>>>>> JDK-8059613 is >>>>>>>>>>>>> also applied. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Dmitrij >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> From filipp.zhinkin at oracle.com Thu Dec 25 13:05:12 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Thu, 25 Dec 2014 17:05:12 +0400 Subject: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature In-Reply-To: <549C0B74.6000900@oracle.com> References: <54947677.7050104@oracle.com> <54991962.7020806@oracle.com> <549929D8.7050003@oracle.com> <54993173.6030003@oracle.com> <549953BE.50404@oracle.com> <5499562B.5020008@oracle.com> <54996FA7.3070607@oracle.com> <549B1D5D.8030908@oracle.com> <549BE167.8090305@oracle.com> <549BE60D.2060501@oracle.com> <549C00BA.6040106@oracle.com> <549BFF3D.2060905@oracle.com> <549C019C.4070803@oracle.com> <549C0B74.6000900@oracle.com> Message-ID: <549C0B88.9080408@oracle.com> Looks good. Thanks, Filipp. On 12/25/2014 05:04 PM, Dmitrij Pochepko wrote: > Hi, > > please take a look at fixed version > > http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.04 > > Thanks, > Dmitrij >> >> On 12/25/2014 03:12 PM, Filipp Zhinkin wrote: >>> Dmitrij, >>> >>> I believe that it should be "@bug 8015774". >> agree >>> >>> Now DtraceRunner::runDtrace isn't checking exit code at all. >>> I think that it should assert on zero exit code. >> no, it shouldn't it should be a part of custom implementation of >> DtraceResultsAnalyzer::analyze. >> >> Dima, could you please add exit code check into >> SegmentedCodeCacheDtraceTest.SegmentedCodeCacheDtraceResultsAnalyzer::analyze >> >>> >>> Thanks, >>> Filipp. >>> >>> On 12/25/2014 04:19 PM, Dmitrij Pochepko wrote: >>>> Hi, >>>> >>>> new webrev: >>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.03 >>>> I've added @bug tag >>>> and moved process guard to DtraceRunner::dtraceAvailable >>>> >>>> Thanks, >>>> Dmitrij >>>>> Hi Dmitrij, >>>>> >>>>> DtraceRunner::runDtrace prints warning in case of non-zero exit code. >>>>> It means that the test will pass even if traced JVM crashed. >>>>> >>>>> I can name several issues that were found accidentally, because tests >>>>> didn't care about a crash. >>>>> >>>>> Are there any other sane reasons for DTrace to return non-zero exit code >>>>> except lack of privileges? >>>>> Igor's suggestion will prevent us from running DTrace without required >>>>> privileges, so I'd prefer to see the test failure instead of a >>>>> warning in case >>>>> of non-zero exit code returned by DTrace. >>>>> >>>>> Also, please add @bug to the test. >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 12/25/2014 02:05 PM, Igor Ignatyev wrote: >>>>>> I'd prefer to check privileges by running dtrace against dtrace; >>>>>> and do it in DtraceRunner::dtraceAvailable, smth like >>>>>> >>>>>>> result = false; >>>>>>> dtrace = getDtracePath(); >>>>>>> if ($dtrace) { >>>>>>> $dtrace $dtrace >>>>>>> result = $? == 0; >>>>>>> } >>>>>>> return $result; >>>>>> >>>>>> >>>>>> Igor >>>>>> >>>>>> On 12/24/2014 11:09 PM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> i've placed a guard which skips test in case dtrace exits with >>>>>>> non-zero >>>>>>> code. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>>>>> Hi, >>>>>>>> >>>>>>>> There is one more issues related to these tests(not directly). >>>>>>>> Currently, dtrace tests can't be run in jprt, because dtrace require >>>>>>>> additional previleges for launching user. >>>>>>>> Perhaps it's just user to be granted previleges in jprt solaris >>>>>>>> hosts... >>>>>>>> Not sure about some guard in tests... the only way i know so far >>>>>>>> is to >>>>>>>> just try launching dtrace and parse output >>>>>>>> saying about missing previleges, but it doesn't seem to be good >>>>>>>> solution. >>>>>>>> I think test should assume to be launched in correct environment and >>>>>>>> in case it's failed because of previleges, evaluating engineer >>>>>>>> starting to work on respective env. issue... >>>>>>>> Does anybody have some additional concerns? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij >>>>>>>> >>>>>>>>> Hi Dmitrij, >>>>>>>>> >>>>>>>>> >>>>>>>>> There is still a typo in spelling (DESCTRUCTIVE => DESTRUCTIVE): >>>>>>>>> >>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>> >>>>>>>>> 42 public static final String >>>>>>>>> PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>> >>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>> 85 DtraceRunner.PERMIT_DESCTRUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>> >>>>>>>>> >>>>>>>>> Otherwise, looks good. >>>>>>>>> Please, consider it reviewed (no need to re-review). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/23/14 3:36 AM, Dmitrij Pochepko wrote: >>>>>>>>>> Hi, >>>>>>>>>> please review updated webrev >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Dmitrij >>>>>>>>>>> On 12/23/14 12:37 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for catching these issues. >>>>>>>>>>>> I have a question regarding last comment: does it make any >>>>>>>>>>>> difference to change "reading of static member 3 times" to >>>>>>>>>>>> "copying into static member of another class and then read it 3 >>>>>>>>>>>> times"? >>>>>>>>>>> >>>>>>>>>>> Yes, it does (it is a minor issue though). >>>>>>>>>>> It is because the class names are pretty big. >>>>>>>>>>> It would simplify the code and improve readability, right? >>>>>>>>>>> >>>>>>>>>>> You already do it two times: >>>>>>>>>>> 179 List tml >>>>>>>>>>> 180 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> ... >>>>>>>>>>> 235 List mlist >>>>>>>>>>> 236 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> >>>>>>>>>>> My suggestion is to do it once somewhere before the line 74: >>>>>>>>>>> static final List MLIST = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> and then use the mlist in other places where it is needed: >>>>>>>>>>> >>>>>>>>>>> 75 String params = MLIST.stream() >>>>>>>>>>> ... >>>>>>>>>>> 182 d.put(MLIST.get(i).getName(), new >>>>>>>>>>> MethodData(MLIST.get(i).getName(), >>>>>>>>>>> ... >>>>>>>>>>> 239 for (int i = MLIST.size() - 1; i > -1; i--) { >>>>>>>>>>> 240 sb.append(MLIST.get(i).getName()).append(delimeter); >>>>>>>>>>> These lines will go away: >>>>>>>>>>> 179 List tml >>>>>>>>>>> 180 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> ... >>>>>>>>>>> 235 List mlist >>>>>>>>>>> 236 = >>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Both private static classes are inner classes of the public one. >>>>>>>>>>> The MLIST will be in a context for the inner classes, and so, >>>>>>>>>>> needs >>>>>>>>>>> no prefixing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Dmitrij >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It looks good in general. >>>>>>>>>>>>> Some minor comments are below. >>>>>>>>>>>>> >>>>>>>>>>>>> test/testlibrary/com/oracle/java/testlibrary/dtrace/DtraceRunner.java >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 42 public static final String >>>>>>>>>>>>> PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION = "w"; >>>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> test/compiler/codecache/dtrace/SegmentedCodeCacheDtraceTest.java >>>>>>>>>>>>> >>>>>>>>>>>>> 84 DtraceRunner.PERMIT_DESCTUCTIVE_ACTIONS_DTRACE_OPTION, >>>>>>>>>>>>> A typo in the constant name: DESCTUCTIVE => DESTRUCTIVE >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 60 private static final String WORKER_CLASS_NAME >>>>>>>>>>>>> 61 = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.class.getName(); >>>>>>>>>>>>> ... >>>>>>>>>>>>> 80 runner.runDtrace(JDKToolFinder.getTestJDKTool("java"), >>>>>>>>>>>>> JAVA_OPTS, >>>>>>>>>>>>> 81 SegmentedCodeCacheDtraceTestWorker.class.getName(), >>>>>>>>>>>>> params, >>>>>>>>>>>>> The WORKER_CLASS_NAME can be used at 81. >>>>>>>>>>>>> >>>>>>>>>>>>> 75 String params = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST.stream() >>>>>>>>>>>>> ... >>>>>>>>>>>>> 179 List tml >>>>>>>>>>>>> 180 = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>>> ... >>>>>>>>>>>>> 235 List mlist >>>>>>>>>>>>> 236 = >>>>>>>>>>>>> SegmentedCodeCacheDtraceTestWorker.TESTED_METHODS_LIST; >>>>>>>>>>>>> The TESTED_METHODS_LIST is used three times. >>>>>>>>>>>>> It can be cached at the top and re-used. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 12/19/14 11:03 AM, Dmitrij Pochepko wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review changes for >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059625 - >>>>>>>>>>>>>> JEP-JDK-8043304: Test task: DTrace- tests for segmented >>>>>>>>>>>>>> codecache feature >>>>>>>>>>>>>> >>>>>>>>>>>>>> Description: this fix introduce dtrace test, which verify that >>>>>>>>>>>>>> different combinations of available compile levels(and, in case >>>>>>>>>>>>>> compile levels allows it, different code heaps as result) >>>>>>>>>>>>>> doesn't affect callstack shown by dtrace. There is a control >>>>>>>>>>>>>> class SegmentedCodeCacheDtraceTest.java and class for running >>>>>>>>>>>>>> via dtrace SegmentedCodeCacheDtraceTestWorker.java. A dtrace d >>>>>>>>>>>>>> script is also present >>>>>>>>>>>>>> (SegmentedCodeCacheDtraceTestScript.d). A >>>>>>>>>>>>>> control class is using DtraceRunner.java to run dtrace and then >>>>>>>>>>>>>> analyzing results using class >>>>>>>>>>>>>> SegmentedCodeCacheDtraceResultsAnalyzer with >>>>>>>>>>>>>> DtraceResultsAnalyzer interface. >>>>>>>>>>>>>> There is also a small class CompilerUtils.java created for >>>>>>>>>>>>>> usefull common code. >>>>>>>>>>>>>> >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059625/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Additional note: Please note that this path assumes that fix >>>>>>>>>>>>>> for >>>>>>>>>>>>>> JDK-8066440 - Various changes in testlibrary for JDK-8059613 is >>>>>>>>>>>>>> also applied. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Dmitrij >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> > From goetz.lindenmaier at sap.com Mon Dec 29 08:54:19 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Dec 2014 08:54:19 +0000 Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms In-Reply-To: <549ACC1B.8090706@oracle.com> References: <549ACC1B.8090706@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF52DBF@DEWDFEMB12A.global.corp.sap> Hi Filipp, Sorry I'm late, but this is good! Thanks, Goetz. -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Filipp Zhinkin Sent: Wednesday, December 24, 2014 3:22 PM To: hotspot-compiler-dev at openjdk.java.net Subject: [9] RFR (S): 8068183: Add isTieredSupported method to c.o.j.t.Platforms Hi all, please review a new c.o.j.t.Platform's method "isTieredSupported" which is aimed to report whether or not JVM supports tiered compilation disregard to TieredCompilation flag's value. Such functionality is required for Segmented Code Cache CLI tests [1] and it would be useful in other cases too ([2] for instance). In order to check if tiered compilation is supported we simply look to "sun.management.compiler"property's valuewhich will contain "Tiered Compilers" substring only when tiered compilation is supported [3]. Bug id: https://bugs.openjdk.java.net/browse/JDK-8068183 Webrev: http://cr.openjdk.java.net/~fzhinkin/8068183/webrev.00/ Testing: manual on localmachine using both client & server JVMs. Thanks, Filipp. [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016717.html [2] https://bugs.openjdk.java.net/browse/JDK-8067823 [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/7f062b70a344/src/share/vm/prims/jvm.cpp#l366 From goetz.lindenmaier at sap.com Mon Dec 29 08:58:21 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 29 Dec 2014 08:58:21 +0000 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <549AEAED.9070307@oracle.com> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <549AEAED.9070307@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF53DE3@DEWDFEMB12A.global.corp.sap> Looks good and works fine on ppc, Thanks a lot! Goetz. -----Original Message----- From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com] Sent: Wednesday, December 24, 2014 5:34 PM To: hotspot-compiler-dev at openjdk.java.net Cc: Christian Thalinger; Lindenmaier, Goetz Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests Hi all, please take a look at updated tests. This time an issue with server JVMs that don't support tiered compilation was resolved. incremental diff: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02.inc/ new webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02/ testing: JPRT & local (using server embedded JVM which does not support tiered comp). This change is also depends on https://bugs.openjdk.java.net/browse/JDK-8068183. Thanks, Filipp. On 12/23/2014 11:37 AM, Filipp Zhinkin wrote: > Thank you, Christian! > > Regards, > Filipp. > > On 12/22/2014 09:01 PM, Christian Thalinger wrote: >> Yes, looks good. >> >>> On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin wrote: >>> >>> Christian, are you ok with the latest fix version? >>> >>> Thanks, >>> Filipp. >>> >>> On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: >>>> Christian, thank you for review! >>>> >>>> I've updated tests to reflect WhiteBox movement to top-level repo, >>>> added previously missed @bug tag and fixed few small issues: >>>> >>>> incremental diff: >>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ >>>> >>>> updated webrev: >>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/19/2014 02:19 AM, Christian Thalinger wrote: >>>>> Looks good. >>>>> >>>>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann >>>>>> wrote: >>>>>> >>>>>> Hi Filipp, >>>>>> >>>>>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>>>>> Tobias, >>>>>>> >>>>>>> as I wrote you in a private message, until a fix for 8064940 doesn't affect >>>>>>> the way options are processed there is no need to update proposed tests. >>>>>>> >>>>>>> I've filed 8067135 for new tests that will verify actual alignment of >>>>>>> code heaps. >>>>>> Okay, sounds good. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> Regards, >>>>>>> Filipp. >>>>>>> >>>>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>>>>> Hi Tobias, >>>>>>>>>> >>>>>>>>>> thank you for suggestion. >>>>>>>>>> >>>>>>>>>> Yes, I think we should take code heap size alignment into account. >>>>>>>>>> >>>>>>>>>> What alignment policy you're going to implement for 8064940? >>>>>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>>>>> >>>>>>>>>> Maybe instead of checking that values are in >>>>>>>>>> (value - page_size, value + page_size) interval we should just check >>>>>>>>>> that all values were aligned up to page_size? >>>>>>>>> Yes, that's a better solution. However, I don't know how to figure out >>>>>>>>> the >>>>>>>>> available page sizes from Java code. >>>>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>>>>> about to add such method to WB API, but it need to check how well >>>>>>>> it is going to work with large pages. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Filipp. >>>>>>>>> Best, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Filipp. >>>>>>>>>> >>>>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>>>>> Hi Filipp, >>>>>>>>>>> >>>>>>>>>>> the actual size of a code heap is affected by alignment and >>>>>>>>>>> therefore may be >>>>>>>>>>> different to the size set via the command line. For example, on >>>>>>>>>>> Sparc we >>>>>>>>>>> have to >>>>>>>>>>> make sure that the code heaps are large page (4MB) aligned to reduce >>>>>>>>>>> the >>>>>>>>>>> number >>>>>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>>>>> >>>>>>>>>>> Maybe we should check if the actual size of the code heap is within >>>>>>>>>>> boundaries, >>>>>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>>>>> >>>>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please take a look at CLI tests for segmented code cache >>>>>>>>>>>> (JDK-8059623). >>>>>>>>>>>> >>>>>>>>>>>> There are three new tests: >>>>>>>>>>>> compiler/codecache/cli/ >>>>>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>>>>> >>>>>>>>>>>> All tests consist of several test cases aimed to verify different >>>>>>>>>>>> aspects >>>>>>>>>>>> of options' processing. >>>>>>>>>>>> >>>>>>>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache >>>>>>>>>>>> test, >>>>>>>>>>>> but add additional value - these tests actually check final values >>>>>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>>>>> >>>>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>>>>> Testing: manual & automated >>>>>>>>>>>> >>>>>>>>>>>> This change depends on: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve >>>>>>>>>>>> compiler's CLI >>>>>>>>>>>> tests >>>>>>>>>>>> error reporting >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>>>>>>> testlibrary >>>>>>>>>>>> for JDK-8059613 >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Filipp. > From filipp.zhinkin at oracle.com Mon Dec 29 09:54:04 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 29 Dec 2014 13:54:04 +0400 Subject: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF53DE3@DEWDFEMB12A.global.corp.sap> References: <5481E60D.9020309@oracle.com> <5485635C.6020501@oracle.com> <548598C2.30808@oracle.com> <5485B1CB.5050300@oracle.com> <5485B31C.6070001@oracle.com> <54883AAF.2060603@oracle.com> <54883F17.4060904@oracle.com> <5493FEE4.9070503@oracle.com> <54983368.7030303@oracle.com> <1A9FCC82-8D8B-41CC-BA00-85152E751923@oracle.com> <54991BBF.2000704@oracle.com> <549AEAED.9070307@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF53DE3@DEWDFEMB12A.global.corp.sap> Message-ID: <54A124BC.7090504@oracle.com> Thank you, Goetz! Regards, Filipp. On 12/29/2014 12:58 PM, Lindenmaier, Goetz wrote: > Looks good and works fine on ppc, > > Thanks a lot! > Goetz. > > -----Original Message----- > From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com] > Sent: Wednesday, December 24, 2014 5:34 PM > To: hotspot-compiler-dev at openjdk.java.net > Cc: Christian Thalinger; Lindenmaier, Goetz > Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests > > Hi all, > > please take a look at updated tests. > This time an issue with server JVMs that don't support tiered compilation was > resolved. > > incremental diff: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02.inc/ > new webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02/ > testing: JPRT & local (using server embedded JVM which does not support tiered > comp). > > This change is also depends on https://bugs.openjdk.java.net/browse/JDK-8068183. > > Thanks, > Filipp. > > On 12/23/2014 11:37 AM, Filipp Zhinkin wrote: >> Thank you, Christian! >> >> Regards, >> Filipp. >> >> On 12/22/2014 09:01 PM, Christian Thalinger wrote: >>> Yes, looks good. >>> >>>> On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin wrote: >>>> >>>> Christian, are you ok with the latest fix version? >>>> >>>> Thanks, >>>> Filipp. >>>> >>>> On 12/19/2014 02:33 PM, Filipp Zhinkin wrote: >>>>> Christian, thank you for review! >>>>> >>>>> I've updated tests to reflect WhiteBox movement to top-level repo, >>>>> added previously missed @bug tag and fixed few small issues: >>>>> >>>>> incremental diff: >>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/ >>>>> >>>>> updated webrev: >>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/ >>>>> >>>>> Thanks, >>>>> Filipp. >>>>> >>>>> On 12/19/2014 02:19 AM, Christian Thalinger wrote: >>>>>> Looks good. >>>>>> >>>>>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann >>>>>>> wrote: >>>>>>> >>>>>>> Hi Filipp, >>>>>>> >>>>>>> On 10.12.2014 13:21, Filipp Zhinkin wrote: >>>>>>>> Tobias, >>>>>>>> >>>>>>>> as I wrote you in a private message, until a fix for 8064940 doesn't affect >>>>>>>> the way options are processed there is no need to update proposed tests. >>>>>>>> >>>>>>>> I've filed 8067135 for new tests that will verify actual alignment of >>>>>>>> code heaps. >>>>>>> Okay, sounds good. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>> Regards, >>>>>>>> Filipp. >>>>>>>> >>>>>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote: >>>>>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote: >>>>>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote: >>>>>>>>>>> Hi Tobias, >>>>>>>>>>> >>>>>>>>>>> thank you for suggestion. >>>>>>>>>>> >>>>>>>>>>> Yes, I think we should take code heap size alignment into account. >>>>>>>>>>> >>>>>>>>>>> What alignment policy you're going to implement for 8064940? >>>>>>>>>> My current fix just large-page-aligns the code heap sizes. >>>>>>>>>> >>>>>>>>>>> Maybe instead of checking that values are in >>>>>>>>>>> (value - page_size, value + page_size) interval we should just check >>>>>>>>>>> that all values were aligned up to page_size? >>>>>>>>>> Yes, that's a better solution. However, I don't know how to figure out >>>>>>>>>> the >>>>>>>>>> available page sizes from Java code. >>>>>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list >>>>>>>>> about to add such method to WB API, but it need to check how well >>>>>>>>> it is going to work with large pages. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Filipp. >>>>>>>>>> Best, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Filipp. >>>>>>>>>>> >>>>>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote: >>>>>>>>>>>> Hi Filipp, >>>>>>>>>>>> >>>>>>>>>>>> the actual size of a code heap is affected by alignment and >>>>>>>>>>>> therefore may be >>>>>>>>>>>> different to the size set via the command line. For example, on >>>>>>>>>>>> Sparc we >>>>>>>>>>>> have to >>>>>>>>>>>> make sure that the code heaps are large page (4MB) aligned to reduce >>>>>>>>>>>> the >>>>>>>>>>>> number >>>>>>>>>>>> of ITLB misses (will be introduced with [1]). >>>>>>>>>>>> >>>>>>>>>>>> Maybe we should check if the actual size of the code heap is within >>>>>>>>>>>> boundaries, >>>>>>>>>>>> i.e., within the specified size +- (large) page size. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940 >>>>>>>>>>>> >>>>>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> please take a look at CLI tests for segmented code cache >>>>>>>>>>>>> (JDK-8059623). >>>>>>>>>>>>> >>>>>>>>>>>>> There are three new tests: >>>>>>>>>>>>> compiler/codecache/cli/ >>>>>>>>>>>>> codeheapsize/TestCodeHeapSizeOptions >>>>>>>>>>>>> printcodecache/TestPrintCodeCacheOption >>>>>>>>>>>>> TestSegmentedCodeCacheOption >>>>>>>>>>>>> >>>>>>>>>>>>> All tests consist of several test cases aimed to verify different >>>>>>>>>>>>> aspects >>>>>>>>>>>>> of options' processing. >>>>>>>>>>>>> >>>>>>>>>>>>> These tests partially overlapped with c/c/CheckSegmentedCodeCache >>>>>>>>>>>>> test, >>>>>>>>>>>>> but add additional value - these tests actually check final values >>>>>>>>>>>>> of tested options and verifies PrintCodeCache output. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623 >>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/ >>>>>>>>>>>>> Testing: manual & automated >>>>>>>>>>>>> >>>>>>>>>>>>> This change depends on: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve >>>>>>>>>>>>> compiler's CLI >>>>>>>>>>>>> tests >>>>>>>>>>>>> error reporting >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various changes in >>>>>>>>>>>>> testlibrary >>>>>>>>>>>>> for JDK-8059613 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> Filipp. From filipp.zhinkin at oracle.com Mon Dec 29 16:26:52 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 29 Dec 2014 08:26:52 -0800 (PST) Subject: [9] RFR (S): 8068272: Extend WhiteBox API with methods that check monitor state and force safepoint Message-ID: Hi all, please review new methods added to WhiteBox which aimed to - check if a monitor associated with a java object is an inflated one; - force safepoint synchronization (and cause monitor's deflation). These methods are required to solve several issues in compiler/rtm tests [1]. Bug id: https://bugs.openjdk.java.net/browse/JDK-8068272 Webrev: http://cr.openjdk.java.net/~fzhinkin/8068272/webrev.00/ Testing: on local machine. Thanks, Filipp. [1] https://bugs.openjdk.java.net/browse/JDK-8050486 From filipp.zhinkin at oracle.com Mon Dec 29 16:35:26 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 29 Dec 2014 08:35:26 -0800 (PST) Subject: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization Message-ID: Hi all, please review a fix for JDK-8050486. Following issues cause compiler/rtm/ tests failures when safepoint sync happened in the middle of test run: - monitors that expected to be inflated are deflated; - monitors that expected to be lightweight stack-locks are inflated. In order to solve the first issue inflation-forcing algorithm was modified to wait forever on a monitor that should be inflated. The second issue is resolved by explicit monitor state checks that force deflation in case when monitor is inflated, but it should not. This fix depends on 8068272: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016744.html Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 Webrev: http://cr.openjdk.java.net/~fzhinkin/8050486/webrev.00/ Testing: on host w/ HSW CPU, JPRT, automated on hosts w/ HSW CPU. Thanks, Filipp. From pavel.chistyakov at oracle.com Mon Dec 29 17:19:33 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Mon, 29 Dec 2014 20:19:33 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: References: Message-ID: <54A18D25.7010903@oracle.com> Hi all, webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.04/ We need small update in compileBroker.cpp:255 for testing overload compile queue. 255 assert (_num_allocated_tasks < 10000, "Leaking compilation tasks?"); This assert fails during test if we lock compilation and trying to enqueue a lot of methods for compilation. The suggestion is to change condition like this: 255 assert (WhiteBoxAPI || WhiteBox::compilation_locked || _num_allocated_tasks < 10000, "Leaking compilation tasks?"); Checking only WhiteBox::compilation_locked flag is not enough, because even after compilation is unlocked we can fall into situation when _num_allocated_tasks will be greater than 10000 and test fails. ------------- Thanks, Pavel On 19.12.2014 13:53, Pavel Chistyakov wrote: > Hi Christian, > > Yes, here is updated version: http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 > Could you please take a look into it? > > -------- > Thanks, > Pavel > > ----- Original Message ----- > From: christian.thalinger at oracle.com > To: igor.ignatyev at oracle.com > Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net > Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests > > >> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev wrote: >> >> Pavel, >> >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >> >>> 45 CLASS_DATA = loadClassData(TestCaseImpl.class.getName()); >>> 95 String className = TestCaseImpl.class.getName(); >> these lines will load 'TestCaseImpl' class via default class loader, could you try to avoid it? > Any update on that? > >> Igor >> >> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>> Hi, >>> >>> please take a look into slightly updated webrev: >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>> >>> >>> -------------- >>> Thanks, >>> Pavel >>> >>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>> Looks fine. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>> wrote: >>>>> >>>>>> David, thank you for review. >>>>>> Here is updated webrev: >>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>> >>>>> That is excellent -- now we just need a real reviewer. >>>>> >>>>> David >>>>> From vladimir.kozlov at oracle.com Mon Dec 29 19:00:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Dec 2014 11:00:30 -0800 Subject: [9] RFR (S): 8068272: Extend WhiteBox API with methods that check monitor state and force safepoint In-Reply-To: References: Message-ID: <54A1A4CE.70301@oracle.com> Looks good. Thanks, Vladimir On 12/29/14 8:26 AM, Filipp Zhinkin wrote: > Hi all, > > please review new methods added to WhiteBox which aimed to > - check if a monitor associated with a java object is an inflated one; > - force safepoint synchronization (and cause monitor's deflation). > > These methods are required to solve several issues in compiler/rtm tests [1]. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8068272 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8068272/webrev.00/ > Testing: on local machine. > > Thanks, > Filipp. > > [1] https://bugs.openjdk.java.net/browse/JDK-8050486 > From vladimir.kozlov at oracle.com Mon Dec 29 19:37:28 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Dec 2014 11:37:28 -0800 Subject: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization In-Reply-To: References: Message-ID: <54A1AD78.5050908@oracle.com> Filipp, I don't understand how you expect progress in lines 78-83 in AbortProvoker.java when second thread keeps lock of 'monitor'. synchronized (monitor) at the line 78 should wait until second thread release it so you will never reach line 83. I would suggest to lunch third thread to inflate monitor and use main thread to see the state. Thanks, Vladimir On 12/29/14 8:35 AM, Filipp Zhinkin wrote: > Hi all, > > please review a fix for JDK-8050486. > > Following issues cause compiler/rtm/ tests failures > when safepoint sync happened in the middle of test run: > - monitors that expected to be inflated are deflated; > - monitors that expected to be lightweight stack-locks are inflated. > > In order to solve the first issue inflation-forcing algorithm > was modified to wait forever on a monitor that should be inflated. > > The second issue is resolved by explicit monitor state checks that > force deflation in case when monitor is inflated, but it should not. > > This fix depends on 8068272: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016744.html > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8050486/webrev.00/ > Testing: on host w/ HSW CPU, JPRT, automated on hosts w/ HSW CPU. > > Thanks, > Filipp. > From igor.ignatyev at oracle.com Mon Dec 29 20:04:50 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 29 Dec 2014 23:04:50 +0300 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <54A18D25.7010903@oracle.com> References: <54A18D25.7010903@oracle.com> Message-ID: <54A1B3E2.4020107@oracle.com> On 12/29/2014 08:19 PM, Pavel Chistyakov wrote: > Hi all, > > webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.04/ > > > We need small update in compileBroker.cpp:255 for testing overload > compile queue. > > 255 assert (_num_allocated_tasks < 10000, "Leaking compilation > tasks?"); > > This assert fails during test if we lock compilation and trying to > enqueue a lot of methods for compilation. > > The suggestion is to change condition like this: > > 255 assert (WhiteBoxAPI || WhiteBox::compilation_locked || > _num_allocated_tasks < 10000, "Leaking compilation tasks?"); > > Checking only WhiteBox::compilation_locked flag is not enough, because > even after compilation is unlocked we can fall into situation when > _num_allocated_tasks will be greater than 10000 and test fails. then, I'd prefer to have just WhiteBoxAPI || _num_allocated_tasks ... > > ------------- > Thanks, > Pavel > > On 19.12.2014 13:53, Pavel Chistyakov wrote: >> Hi Christian, >> >> Yes, here is updated version: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >> Could you please take a look into it? >> >> -------- >> Thanks, >> Pavel >> >> ----- Original Message ----- >> From: christian.thalinger at oracle.com >> To: igor.ignatyev at oracle.com >> Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net >> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >> >> >>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >>> wrote: >>> >>> Pavel, >>> >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>> >>> >>>> 45 CLASS_DATA = >>>> loadClassData(TestCaseImpl.class.getName()); >>>> 95 String className = TestCaseImpl.class.getName(); >>> these lines will load 'TestCaseImpl' class via default class loader, >>> could you try to avoid it? >> Any update on that? >> >>> Igor >>> >>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>> Hi, >>>> >>>> please take a look into slightly updated webrev: >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>> >>>> >>>> >>>> -------------- >>>> Thanks, >>>> Pavel >>>> >>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>> wrote: >>>>>> >>>>>>> David, thank you for review. >>>>>>> Here is updated webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>> >>>>>>> >>>>>> That is excellent -- now we just need a real reviewer. >>>>>> >>>>>> David >>>>>> > From vladimir.kozlov at oracle.com Mon Dec 29 20:09:58 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Dec 2014 12:09:58 -0800 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: <54A18D25.7010903@oracle.com> References: <54A18D25.7010903@oracle.com> Message-ID: <54A1B516.5050207@oracle.com> On 12/29/14 9:19 AM, Pavel Chistyakov wrote: > Hi all, > > webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.04/ > > > We need small update in compileBroker.cpp:255 for testing overload > compile queue. > > 255 assert (_num_allocated_tasks < 10000, "Leaking compilation > tasks?"); > > This assert fails during test if we lock compilation and trying to > enqueue a lot of methods for compilation. The change seems reasonable. Could you explain the logic which put methods on queue? JVM don't add a method compilation task if such task already exist. How you bypass that check? > > The suggestion is to change condition like this: > > 255 assert (WhiteBoxAPI || WhiteBox::compilation_locked || > _num_allocated_tasks < 10000, "Leaking compilation tasks?"); > > Checking only WhiteBox::compilation_locked flag is not enough, because > even after compilation is unlocked we can fall into situation when > _num_allocated_tasks will be greater than 10000 and test fails. Why check WhiteBox::compilation_locked then? Should WhiteBoxAPI check be enough? Thanks, Vladimir > > ------------- > Thanks, > Pavel > > On 19.12.2014 13:53, Pavel Chistyakov wrote: >> Hi Christian, >> >> Yes, here is updated version: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >> Could you please take a look into it? >> >> -------- >> Thanks, >> Pavel >> >> ----- Original Message ----- >> From: christian.thalinger at oracle.com >> To: igor.ignatyev at oracle.com >> Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net >> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >> >> >>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >>> wrote: >>> >>> Pavel, >>> >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>> >>> >>>> 45 CLASS_DATA = >>>> loadClassData(TestCaseImpl.class.getName()); >>>> 95 String className = TestCaseImpl.class.getName(); >>> these lines will load 'TestCaseImpl' class via default class loader, >>> could you try to avoid it? >> Any update on that? >> >>> Igor >>> >>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>> Hi, >>>> >>>> please take a look into slightly updated webrev: >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>> >>>> >>>> >>>> -------------- >>>> Thanks, >>>> Pavel >>>> >>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>> wrote: >>>>>> >>>>>>> David, thank you for review. >>>>>>> Here is updated webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>> >>>>>>> >>>>>> That is excellent -- now we just need a real reviewer. >>>>>> >>>>>> David >>>>>> > From filipp.zhinkin at oracle.com Mon Dec 29 20:21:13 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 29 Dec 2014 12:21:13 -0800 (PST) Subject: [9] RFR (S): 8068272: Extend WhiteBox API with methods that check monitor state and force safepoint Message-ID: <7417a38e-6cdb-4404-bd0e-9952401bdc23@default> Vladimir, thank you for review. Regards, Filipp. ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Monday, December 29, 2014 10:00:38 PM GMT +03:00 Iraq Subject: Re: [9] RFR (S): 8068272: Extend WhiteBox API with methods that check monitor state and force safepoint Looks good. Thanks, Vladimir On 12/29/14 8:26 AM, Filipp Zhinkin wrote: > Hi all, > > please review new methods added to WhiteBox which aimed to > - check if a monitor associated with a java object is an inflated one; > - force safepoint synchronization (and cause monitor's deflation). > > These methods are required to solve several issues in compiler/rtm tests [1]. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8068272 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8068272/webrev.00/ > Testing: on local machine. > > Thanks, > Filipp. > > [1] https://bugs.openjdk.java.net/browse/JDK-8050486 > From filipp.zhinkin at oracle.com Mon Dec 29 20:27:08 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 29 Dec 2014 12:27:08 -0800 (PST) Subject: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization Message-ID: Hi Vladimir, thank you for looking at it. The second thread (which is started in line 75) enters the monitor first. It is guaranteed by a barrier. When the barrier passed, the second thread calls wait() on the monitor and thus inflate and release it. The first thread then may enter the monitor in line 78. Thanks, Filipp. ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Monday, December 29, 2014 10:37:16 PM GMT +03:00 Iraq Subject: Re: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization Filipp, I don't understand how you expect progress in lines 78-83 in AbortProvoker.java when second thread keeps lock of 'monitor'. synchronized (monitor) at the line 78 should wait until second thread release it so you will never reach line 83. I would suggest to lunch third thread to inflate monitor and use main thread to see the state. Thanks, Vladimir On 12/29/14 8:35 AM, Filipp Zhinkin wrote: > Hi all, > > please review a fix for JDK-8050486. > > Following issues cause compiler/rtm/ tests failures > when safepoint sync happened in the middle of test run: > - monitors that expected to be inflated are deflated; > - monitors that expected to be lightweight stack-locks are inflated. > > In order to solve the first issue inflation-forcing algorithm > was modified to wait forever on a monitor that should be inflated. > > The second issue is resolved by explicit monitor state checks that > force deflation in case when monitor is inflated, but it should not. > > This fix depends on 8068272: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016744.html > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8050486/webrev.00/ > Testing: on host w/ HSW CPU, JPRT, automated on hosts w/ HSW CPU. > > Thanks, > Filipp. > From vladimir.kozlov at oracle.com Mon Dec 29 22:11:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Dec 2014 14:11:54 -0800 Subject: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization In-Reply-To: References: Message-ID: <54A1D1AA.60008@oracle.com> On 12/29/14 12:27 PM, Filipp Zhinkin wrote: > Hi Vladimir, > > thank you for looking at it. > > The second thread (which is started in line 75) enters the monitor first. > It is guaranteed by a barrier. > > When the barrier passed, the second thread calls wait() on the monitor > and thus inflate and release it. > > The first thread then may enter the monitor in line 78. Got it. Reviewed. Thanks, Vladimir > > Thanks, > Filipp. > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Monday, December 29, 2014 10:37:16 PM GMT +03:00 Iraq > Subject: Re: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization > > Filipp, > > I don't understand how you expect progress in lines 78-83 in > AbortProvoker.java when second thread keeps lock of 'monitor'. > synchronized (monitor) at the line 78 should wait until second thread > release it so you will never reach line 83. > > I would suggest to lunch third thread to inflate monitor and use main > thread to see the state. > > Thanks, > Vladimir > > On 12/29/14 8:35 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a fix for JDK-8050486. >> >> Following issues cause compiler/rtm/ tests failures >> when safepoint sync happened in the middle of test run: >> - monitors that expected to be inflated are deflated; >> - monitors that expected to be lightweight stack-locks are inflated. >> >> In order to solve the first issue inflation-forcing algorithm >> was modified to wait forever on a monitor that should be inflated. >> >> The second issue is resolved by explicit monitor state checks that >> force deflation in case when monitor is inflated, but it should not. >> >> This fix depends on 8068272: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016744.html >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8050486/webrev.00/ >> Testing: on host w/ HSW CPU, JPRT, automated on hosts w/ HSW CPU. >> >> Thanks, >> Filipp. >> From filipp.zhinkin at oracle.com Tue Dec 30 05:34:20 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Mon, 29 Dec 2014 21:34:20 -0800 (PST) Subject: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization Message-ID: <4a846394-678e-406b-b29c-84eccb66fd83@default> Vladimir, thank you for review! Regards, Filipp. ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Tuesday, December 30, 2014 1:12:06 AM GMT +03:00 Iraq Subject: Re: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization On 12/29/14 12:27 PM, Filipp Zhinkin wrote: > Hi Vladimir, > > thank you for looking at it. > > The second thread (which is started in line 75) enters the monitor first. > It is guaranteed by a barrier. > > When the barrier passed, the second thread calls wait() on the monitor > and thus inflate and release it. > > The first thread then may enter the monitor in line 78. Got it. Reviewed. Thanks, Vladimir > > Thanks, > Filipp. > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Monday, December 29, 2014 10:37:16 PM GMT +03:00 Iraq > Subject: Re: [9] RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization > > Filipp, > > I don't understand how you expect progress in lines 78-83 in > AbortProvoker.java when second thread keeps lock of 'monitor'. > synchronized (monitor) at the line 78 should wait until second thread > release it so you will never reach line 83. > > I would suggest to lunch third thread to inflate monitor and use main > thread to see the state. > > Thanks, > Vladimir > > On 12/29/14 8:35 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a fix for JDK-8050486. >> >> Following issues cause compiler/rtm/ tests failures >> when safepoint sync happened in the middle of test run: >> - monitors that expected to be inflated are deflated; >> - monitors that expected to be lightweight stack-locks are inflated. >> >> In order to solve the first issue inflation-forcing algorithm >> was modified to wait forever on a monitor that should be inflated. >> >> The second issue is resolved by explicit monitor state checks that >> force deflation in case when monitor is inflated, but it should not. >> >> This fix depends on 8068272: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-December/016744.html >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8050486/webrev.00/ >> Testing: on host w/ HSW CPU, JPRT, automated on hosts w/ HSW CPU. >> >> Thanks, >> Filipp. >> From filipp.zhinkin at oracle.com Tue Dec 30 08:42:11 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 30 Dec 2014 00:42:11 -0800 (PST) Subject: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases Message-ID: Hi all, please review a fix for 8068269. A few RTM tests assert on non-zero locks count in PrintPreciseRTMLockingStatistics entries, but at the same time these tests use RTMTotalCountIncrRate > 1. If RTMTotalCountIncrRate > 1, then locks count will be incremented only when (rdtsc() & (RTMTotalCountIncrRate - 1) == 0) (*). We may never met condition (*) during a short test run and in such case test will fail. An there is one more rare case: when we didn't met (*) and there were no transactional execution abortions. In such case counters will contain zero, JVM will consider it unused and won't print it out. To fix these issues assertions on non-zero locks count were removed for cases where RTMTotalCountIncrRate > 1 and in order to avoid issue with zero counters affected test is now forcing one transactional execution abort. Bug id: https://bugs.openjdk.java.net/browse/JDK-8068269 Webrev: http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.01/ Testing: manual & automaed on host w/ HSW CPU, JPRT Thanks, Filipp. From pavel.chistyakov at oracle.com Tue Dec 30 10:07:14 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Tue, 30 Dec 2014 02:07:14 -0800 (PST) Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests Message-ID: Hi Vladimir, Igor, thank you for review. Vladimir: This situation appear in OverloadCompileQueueTest. We try to enqueue method for compilation using WhiteBox, but for every call we use new classloader -> new class -> new method instance. See OverloadCompileQueueTest.run and Helper$TestCase.get methods for details. Igor: ok, I changed condition to only check WhiteBoxAPI and _num_allocated_tasks. Please, take a look into updated webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.05/ ----------------- Thanks, Pavel ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Monday, December 29, 2014 11:09:30 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests On 12/29/14 9:19 AM, Pavel Chistyakov wrote: > Hi all, > > webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.04/ > > > We need small update in compileBroker.cpp:255 for testing overload > compile queue. > > 255 assert (_num_allocated_tasks < 10000, "Leaking compilation > tasks?"); > > This assert fails during test if we lock compilation and trying to > enqueue a lot of methods for compilation. The change seems reasonable. Could you explain the logic which put methods on queue? JVM don't add a method compilation task if such task already exist. How you bypass that check? > > The suggestion is to change condition like this: > > 255 assert (WhiteBoxAPI || WhiteBox::compilation_locked || > _num_allocated_tasks < 10000, "Leaking compilation tasks?"); > > Checking only WhiteBox::compilation_locked flag is not enough, because > even after compilation is unlocked we can fall into situation when > _num_allocated_tasks will be greater than 10000 and test fails. Why check WhiteBox::compilation_locked then? Should WhiteBoxAPI check be enough? Thanks, Vladimir > > ------------- > Thanks, > Pavel > > On 19.12.2014 13:53, Pavel Chistyakov wrote: >> Hi Christian, >> >> Yes, here is updated version: >> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >> Could you please take a look into it? >> >> -------- >> Thanks, >> Pavel >> >> ----- Original Message ----- >> From: christian.thalinger at oracle.com >> To: igor.ignatyev at oracle.com >> Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net >> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >> >> >>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >>> wrote: >>> >>> Pavel, >>> >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>> >>> >>>> 45 CLASS_DATA = >>>> loadClassData(TestCaseImpl.class.getName()); >>>> 95 String className = TestCaseImpl.class.getName(); >>> these lines will load 'TestCaseImpl' class via default class loader, >>> could you try to avoid it? >> Any update on that? >> >>> Igor >>> >>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>> Hi, >>>> >>>> please take a look into slightly updated webrev: >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>> >>>> >>>> >>>> -------------- >>>> Thanks, >>>> Pavel >>>> >>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>> Looks fine. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>> wrote: >>>>>> >>>>>>> David, thank you for review. >>>>>>> Here is updated webrev: >>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>> >>>>>>> >>>>>> That is excellent -- now we just need a real reviewer. >>>>>> >>>>>> David >>>>>> > From filipp.zhinkin at oracle.com Tue Dec 30 12:07:55 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 30 Dec 2014 04:07:55 -0800 (PST) Subject: [9] RFR (M): 8059342 : Add test to cover JDK-8030976 Message-ID: <54732963-052a-4982-9761-1c697b76562b@default> Hi all, please review a new test on 8030976 (unstable_if trap). The test simply execute a method with an "if" only one of whose branches is always taken. After that compilation log is analyzed in order to find expected trap for appropriate bci. In order to obtain correct bci number the tested method is constructed using asmlib. Bug-id: https://bugs.openjdk.java.net/browse/JDK-8059342 Webrev: http://cr.openjdk.java.net/~fzhinkin/8059342/webrev.00/ Testing: JPRT, manual & automated Thanks, Filipp. From filipp.zhinkin at oracle.com Tue Dec 30 16:52:51 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 30 Dec 2014 08:52:51 -0800 (PST) Subject: [9] RFR (S): 8049355: compiler/rtm/locking/TestRTMLockingThreshold test may fail if transaction was aborted by interrupt Message-ID: Hi all, please take a look at a fix for 8049355. A few RTM tests verify that method was recompiled if abort ratio was pretty low. These tests also verify that before it happened, certain amount of lock attempts was done. In order to guarantee low abort ratio these tests force abort at every Nth iteration (every even iter, actually) or only once at all. However, abort may happened on iteration when we're not trying to force abort (due to CPU interrupt, VMM call, etc.) and amount of lock attempts may differ from expected value. To avoid such issue tests were updated to not force abort first L / 2 iterations and during last L / 2 iterations force it always (L == RTMLockingThreshold value). Bug id: https://bugs.openjdk.java.net/browse/JDK-8049355 Webrev: http://cr.openjdk.java.net/~fzhinkin/8049355/webrev.00/ Testing: manual & automated on host w/ HSW CPU, JPRT Thanks, Filipp. From vladimir.kozlov at oracle.com Tue Dec 30 17:25:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Dec 2014 09:25:25 -0800 Subject: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases In-Reply-To: References: Message-ID: <54A2E005.9010400@oracle.com> Please, add comment that abort is caused by jni call to addressSize(). I thought we have intrinsic for that method and abort will not happen. And if we add such intrinsic the test will fail. Thanks, Vladimir On 12/30/14 12:42 AM, Filipp Zhinkin wrote: > Hi all, > > please review a fix for 8068269. > A few RTM tests assert on non-zero locks count in > PrintPreciseRTMLockingStatistics entries, but at the same time > these tests use RTMTotalCountIncrRate > 1. > > If RTMTotalCountIncrRate > 1, then locks count will be incremented > only when (rdtsc() & (RTMTotalCountIncrRate - 1) == 0) (*). > > We may never met condition (*) during a short test run and > in such case test will fail. > > An there is one more rare case: when we didn't met (*) and > there were no transactional execution abortions. > In such case counters will contain zero, JVM will consider > it unused and won't print it out. > > To fix these issues assertions on non-zero locks count > were removed for cases where RTMTotalCountIncrRate > 1 > and in order to avoid issue with zero counters affected > test is now forcing one transactional execution abort. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8068269 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.01/ > Testing: manual & automaed on host w/ HSW CPU, JPRT > > Thanks, > Filipp. > From vladimir.kozlov at oracle.com Tue Dec 30 17:28:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Dec 2014 09:28:25 -0800 Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests In-Reply-To: References: Message-ID: <54A2E0B9.2090603@oracle.com> On 12/30/14 2:07 AM, Pavel Chistyakov wrote: > Hi Vladimir, Igor, > > thank you for review. > > Vladimir: This situation appear in OverloadCompileQueueTest. We try to enqueue method for compilation using WhiteBox, but for every call we use new classloader -> new class -> new method instance. See OverloadCompileQueueTest.run and Helper$TestCase.get methods for details. Thank you for explanation. Our tests definitely lack of comments. > > Igor: ok, I changed condition to only check WhiteBoxAPI and _num_allocated_tasks. > > > Please, take a look into updated webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.05/ Looks good. Thanks, Vladimir > > ----------------- > Thanks, > Pavel > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Monday, December 29, 2014 11:09:30 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests > > On 12/29/14 9:19 AM, Pavel Chistyakov wrote: >> Hi all, >> >> webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.04/ >> >> >> We need small update in compileBroker.cpp:255 for testing overload >> compile queue. >> >> 255 assert (_num_allocated_tasks < 10000, "Leaking compilation >> tasks?"); >> >> This assert fails during test if we lock compilation and trying to >> enqueue a lot of methods for compilation. > > The change seems reasonable. > > Could you explain the logic which put methods on queue? > JVM don't add a method compilation task if such task already exist. How > you bypass that check? > >> >> The suggestion is to change condition like this: >> >> 255 assert (WhiteBoxAPI || WhiteBox::compilation_locked || >> _num_allocated_tasks < 10000, "Leaking compilation tasks?"); >> >> Checking only WhiteBox::compilation_locked flag is not enough, because >> even after compilation is unlocked we can fall into situation when >> _num_allocated_tasks will be greater than 10000 and test fails. > > Why check WhiteBox::compilation_locked then? Should WhiteBoxAPI check be > enough? > > Thanks, > Vladimir > >> >> ------------- >> Thanks, >> Pavel >> >> On 19.12.2014 13:53, Pavel Chistyakov wrote: >>> Hi Christian, >>> >>> Yes, here is updated version: >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >>> Could you please take a look into it? >>> >>> -------- >>> Thanks, >>> Pavel >>> >>> ----- Original Message ----- >>> From: christian.thalinger at oracle.com >>> To: igor.ignatyev at oracle.com >>> Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net >>> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >>> >>> >>>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >>>> wrote: >>>> >>>> Pavel, >>>> >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>>> >>>> >>>>> 45 CLASS_DATA = >>>>> loadClassData(TestCaseImpl.class.getName()); >>>>> 95 String className = TestCaseImpl.class.getName(); >>>> these lines will load 'TestCaseImpl' class via default class loader, >>>> could you try to avoid it? >>> Any update on that? >>> >>>> Igor >>>> >>>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>>> Hi, >>>>> >>>>> please take a look into slightly updated webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>>> >>>>> >>>>> >>>>> -------------- >>>>> Thanks, >>>>> Pavel >>>>> >>>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>>> Looks fine. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>>> wrote: >>>>>>> >>>>>>>> David, thank you for review. >>>>>>>> Here is updated webrev: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>>> >>>>>>>> >>>>>>> That is excellent -- now we just need a real reviewer. >>>>>>> >>>>>>> David >>>>>>> >> From vladimir.kozlov at oracle.com Tue Dec 30 17:33:07 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Dec 2014 09:33:07 -0800 Subject: [9] RFR (S): 8049355: compiler/rtm/locking/TestRTMLockingThreshold test may fail if transaction was aborted by interrupt In-Reply-To: References: Message-ID: <54A2E1D3.4090000@oracle.com> Looks good. Thanks, Vladimir On 12/30/14 8:52 AM, Filipp Zhinkin wrote: > Hi all, > > please take a look at a fix for 8049355. > > A few RTM tests verify that method was recompiled if > abort ratio was pretty low. These tests also verify that > before it happened, certain amount of lock attempts was done. > > In order to guarantee low abort ratio these tests force abort > at every Nth iteration (every even iter, actually) > or only once at all. > > However, abort may happened on iteration when we're not trying > to force abort (due to CPU interrupt, VMM call, etc.) and amount > of lock attempts may differ from expected value. > > To avoid such issue tests were updated to not force abort first > L / 2 iterations and during last L / 2 iterations force it always > (L == RTMLockingThreshold value). > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8049355 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8049355/webrev.00/ > Testing: manual & automated on host w/ HSW CPU, JPRT > > Thanks, > Filipp. > From filipp.zhinkin at oracle.com Tue Dec 30 18:14:52 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 30 Dec 2014 10:14:52 -0800 (PST) Subject: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases Message-ID: <08c71851-3ac3-4b45-bd50-571392a8a5d4@default> Hi Vladimir, I've added appropriate comment: http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.02/ Well, if such intrinsic will be added, then we can replace Unsafe::addressSize by any other native method call. Thanks, Filipp. ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Tuesday, December 30, 2014 8:25:57 PM GMT +03:00 Iraq Subject: Re: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases Please, add comment that abort is caused by jni call to addressSize(). I thought we have intrinsic for that method and abort will not happen. And if we add such intrinsic the test will fail. Thanks, Vladimir On 12/30/14 12:42 AM, Filipp Zhinkin wrote: > Hi all, > > please review a fix for 8068269. > A few RTM tests assert on non-zero locks count in > PrintPreciseRTMLockingStatistics entries, but at the same time > these tests use RTMTotalCountIncrRate > 1. > > If RTMTotalCountIncrRate > 1, then locks count will be incremented > only when (rdtsc() & (RTMTotalCountIncrRate - 1) == 0) (*). > > We may never met condition (*) during a short test run and > in such case test will fail. > > An there is one more rare case: when we didn't met (*) and > there were no transactional execution abortions. > In such case counters will contain zero, JVM will consider > it unused and won't print it out. > > To fix these issues assertions on non-zero locks count > were removed for cases where RTMTotalCountIncrRate > 1 > and in order to avoid issue with zero counters affected > test is now forcing one transactional execution abort. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8068269 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.01/ > Testing: manual & automaed on host w/ HSW CPU, JPRT > > Thanks, > Filipp. > From filipp.zhinkin at oracle.com Tue Dec 30 18:15:45 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 30 Dec 2014 10:15:45 -0800 (PST) Subject: [9] RFR (S): 8049355: compiler/rtm/locking/TestRTMLockingThreshold test may fail if transaction was aborted by interrupt Message-ID: <829c8334-2d93-47c7-a374-509b96f4002f@default> Thank you for review, Vladimir. Regards, Filipp. ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Tuesday, December 30, 2014 8:33:57 PM GMT +03:00 Iraq Subject: Re: [9] RFR (S): 8049355: compiler/rtm/locking/TestRTMLockingThreshold test may fail if transaction was aborted by interrupt Looks good. Thanks, Vladimir On 12/30/14 8:52 AM, Filipp Zhinkin wrote: > Hi all, > > please take a look at a fix for 8049355. > > A few RTM tests verify that method was recompiled if > abort ratio was pretty low. These tests also verify that > before it happened, certain amount of lock attempts was done. > > In order to guarantee low abort ratio these tests force abort > at every Nth iteration (every even iter, actually) > or only once at all. > > However, abort may happened on iteration when we're not trying > to force abort (due to CPU interrupt, VMM call, etc.) and amount > of lock attempts may differ from expected value. > > To avoid such issue tests were updated to not force abort first > L / 2 iterations and during last L / 2 iterations force it always > (L == RTMLockingThreshold value). > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8049355 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8049355/webrev.00/ > Testing: manual & automated on host w/ HSW CPU, JPRT > > Thanks, > Filipp. > From vladimir.kozlov at oracle.com Tue Dec 30 18:42:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Dec 2014 10:42:33 -0800 Subject: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases In-Reply-To: <08c71851-3ac3-4b45-bd50-571392a8a5d4@default> References: <08c71851-3ac3-4b45-bd50-571392a8a5d4@default> Message-ID: <54A2F219.1050205@oracle.com> Good. Thanks, Vladimir On 12/30/14 10:14 AM, Filipp Zhinkin wrote: > Hi Vladimir, > > I've added appropriate comment: > http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.02/ > > Well, if such intrinsic will be added, > then we can replace Unsafe::addressSize by any > other native method call. > > Thanks, > Filipp. > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Tuesday, December 30, 2014 8:25:57 PM GMT +03:00 Iraq > Subject: Re: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases > > Please, add comment that abort is caused by jni call to addressSize(). I thought we have intrinsic for that method and > abort will not happen. And if we add such intrinsic the test will fail. > > Thanks, > Vladimir > > On 12/30/14 12:42 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a fix for 8068269. >> A few RTM tests assert on non-zero locks count in >> PrintPreciseRTMLockingStatistics entries, but at the same time >> these tests use RTMTotalCountIncrRate > 1. >> >> If RTMTotalCountIncrRate > 1, then locks count will be incremented >> only when (rdtsc() & (RTMTotalCountIncrRate - 1) == 0) (*). >> >> We may never met condition (*) during a short test run and >> in such case test will fail. >> >> An there is one more rare case: when we didn't met (*) and >> there were no transactional execution abortions. >> In such case counters will contain zero, JVM will consider >> it unused and won't print it out. >> >> To fix these issues assertions on non-zero locks count >> were removed for cases where RTMTotalCountIncrRate > 1 >> and in order to avoid issue with zero counters affected >> test is now forcing one transactional execution abort. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8068269 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.01/ >> Testing: manual & automaed on host w/ HSW CPU, JPRT >> >> Thanks, >> Filipp. >> From pavel.chistyakov at oracle.com Tue Dec 30 18:56:25 2014 From: pavel.chistyakov at oracle.com (Pavel Chistyakov) Date: Tue, 30 Dec 2014 10:56:25 -0800 (PST) Subject: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests Message-ID: <0c8f0208-9742-402e-85c0-a0a952449226@default> Vladimir, thank you for review. We'll try to write more comments. ----------- Regards, Pavel ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Tuesday, December 30, 2014 8:28:43 PM GMT +04:00 Abu Dhabi / Muscat Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests On 12/30/14 2:07 AM, Pavel Chistyakov wrote: > Hi Vladimir, Igor, > > thank you for review. > > Vladimir: This situation appear in OverloadCompileQueueTest. We try to enqueue method for compilation using WhiteBox, but for every call we use new classloader -> new class -> new method instance. See OverloadCompileQueueTest.run and Helper$TestCase.get methods for details. Thank you for explanation. Our tests definitely lack of comments. > > Igor: ok, I changed condition to only check WhiteBoxAPI and _num_allocated_tasks. > > > Please, take a look into updated webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.05/ Looks good. Thanks, Vladimir > > ----------------- > Thanks, > Pavel > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Monday, December 29, 2014 11:09:30 PM GMT +04:00 Abu Dhabi / Muscat > Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests > > On 12/29/14 9:19 AM, Pavel Chistyakov wrote: >> Hi all, >> >> webrev: http://cr.openjdk.java.net/~pchistyakov/8059551/webrev.04/ >> >> >> We need small update in compileBroker.cpp:255 for testing overload >> compile queue. >> >> 255 assert (_num_allocated_tasks < 10000, "Leaking compilation >> tasks?"); >> >> This assert fails during test if we lock compilation and trying to >> enqueue a lot of methods for compilation. > > The change seems reasonable. > > Could you explain the logic which put methods on queue? > JVM don't add a method compilation task if such task already exist. How > you bypass that check? > >> >> The suggestion is to change condition like this: >> >> 255 assert (WhiteBoxAPI || WhiteBox::compilation_locked || >> _num_allocated_tasks < 10000, "Leaking compilation tasks?"); >> >> Checking only WhiteBox::compilation_locked flag is not enough, because >> even after compilation is unlocked we can fall into situation when >> _num_allocated_tasks will be greater than 10000 and test fails. > > Why check WhiteBox::compilation_locked then? Should WhiteBoxAPI check be > enough? > > Thanks, > Vladimir > >> >> ------------- >> Thanks, >> Pavel >> >> On 19.12.2014 13:53, Pavel Chistyakov wrote: >>> Hi Christian, >>> >>> Yes, here is updated version: >>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.03 >>> Could you please take a look into it? >>> >>> -------- >>> Thanks, >>> Pavel >>> >>> ----- Original Message ----- >>> From: christian.thalinger at oracle.com >>> To: igor.ignatyev at oracle.com >>> Cc: pavel.chistyakov at oracle.com, hotspot-compiler-dev at openjdk.java.net >>> Sent: Friday, December 19, 2014 1:17:48 AM GMT +04:00 Abu Dhabi / Muscat >>> Subject: Re: RFR: 8059551: JEP-JDK-8043304: Test task: stress tests >>> >>> >>>> On Dec 15, 2014, at 5:34 AM, Igor Ignatyev >>>> wrote: >>>> >>>> Pavel, >>>> >>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/test/compiler/codecache/stress/Helper.java.html >>>> >>>> >>>>> 45 CLASS_DATA = >>>>> loadClassData(TestCaseImpl.class.getName()); >>>>> 95 String className = TestCaseImpl.class.getName(); >>>> these lines will load 'TestCaseImpl' class via default class loader, >>>> could you try to avoid it? >>> Any update on that? >>> >>>> Igor >>>> >>>> On 12/15/2014 04:15 PM, Pavel Chistyakov wrote: >>>>> Hi, >>>>> >>>>> please take a look into slightly updated webrev: >>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.02/ >>>>> >>>>> >>>>> >>>>> -------------- >>>>> Thanks, >>>>> Pavel >>>>> >>>>> On 12.12.2014 23:05, Vladimir Kozlov wrote: >>>>>> Looks fine. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 12/12/14 6:07 AM, David Chase wrote: >>>>>>> On 2014-12-12, at 5:14 AM, Pavel Chistyakov >>>>>>> wrote: >>>>>>> >>>>>>>> David, thank you for review. >>>>>>>> Here is updated webrev: >>>>>>>> http://cr.openjdk.java.net/~iignatyev/pchistyakov/8059551/webrev.01 >>>>>>>> >>>>>>>> >>>>>>> That is excellent -- now we just need a real reviewer. >>>>>>> >>>>>>> David >>>>>>> >> From filipp.zhinkin at oracle.com Tue Dec 30 19:51:55 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 30 Dec 2014 11:51:55 -0800 (PST) Subject: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases Message-ID: <68e06b22-cb5a-4ff5-b9fd-a98ff19d67fd@default> Vladimir, thank you. Regards, Filipp. ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Tuesday, December 30, 2014 9:43:28 PM GMT +03:00 Iraq Subject: Re: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases Good. Thanks, Vladimir On 12/30/14 10:14 AM, Filipp Zhinkin wrote: > Hi Vladimir, > > I've added appropriate comment: > http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.02/ > > Well, if such intrinsic will be added, > then we can replace Unsafe::addressSize by any > other native method call. > > Thanks, > Filipp. > > ----- Original Message ----- > From: vladimir.kozlov at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Sent: Tuesday, December 30, 2014 8:25:57 PM GMT +03:00 Iraq > Subject: Re: [9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases > > Please, add comment that abort is caused by jni call to addressSize(). I thought we have intrinsic for that method and > abort will not happen. And if we add such intrinsic the test will fail. > > Thanks, > Vladimir > > On 12/30/14 12:42 AM, Filipp Zhinkin wrote: >> Hi all, >> >> please review a fix for 8068269. >> A few RTM tests assert on non-zero locks count in >> PrintPreciseRTMLockingStatistics entries, but at the same time >> these tests use RTMTotalCountIncrRate > 1. >> >> If RTMTotalCountIncrRate > 1, then locks count will be incremented >> only when (rdtsc() & (RTMTotalCountIncrRate - 1) == 0) (*). >> >> We may never met condition (*) during a short test run and >> in such case test will fail. >> >> An there is one more rare case: when we didn't met (*) and >> there were no transactional execution abortions. >> In such case counters will contain zero, JVM will consider >> it unused and won't print it out. >> >> To fix these issues assertions on non-zero locks count >> were removed for cases where RTMTotalCountIncrRate > 1 >> and in order to avoid issue with zero counters affected >> test is now forcing one transactional execution abort. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8068269 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.01/ >> Testing: manual & automaed on host w/ HSW CPU, JPRT >> >> Thanks, >> Filipp. >> From vladimir.kozlov at oracle.com Tue Dec 30 20:40:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Dec 2014 12:40:22 -0800 Subject: [9] RFR (M): 8059342 : Add test to cover JDK-8030976 In-Reply-To: <54732963-052a-4982-9761-1c697b76562b@default> References: <54732963-052a-4982-9761-1c697b76562b@default> Message-ID: <54A30DB6.3080301@oracle.com> Seems good. Thanks, Vladimir On 12/30/14 4:07 AM, Filipp Zhinkin wrote: > Hi all, > > please review a new test on 8030976 (unstable_if trap). > > The test simply execute a method with an "if" only one > of whose branches is always taken. > After that compilation log is analyzed in order to find > expected trap for appropriate bci. > > In order to obtain correct bci number the tested method is > constructed using asmlib. > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8059342 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8059342/webrev.00/ > Testing: JPRT, manual & automated > > Thanks, > Filipp. > From filipp.zhinkin at oracle.com Tue Dec 30 23:31:39 2014 From: filipp.zhinkin at oracle.com (Filipp Zhinkin) Date: Tue, 30 Dec 2014 15:31:39 -0800 (PST) Subject: [9] RFR (M): 8059342 : Add test to cover JDK-8030976 Message-ID: <2c1de306-0d22-450f-82d8-2c5bd9d9b30b@default> Vladimir, thank you for review. Regards, Filipp. ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Tuesday, December 30, 2014 11:40:33 PM GMT +03:00 Iraq Subject: Re: [9] RFR (M): 8059342 : Add test to cover JDK-8030976 Seems good. Thanks, Vladimir On 12/30/14 4:07 AM, Filipp Zhinkin wrote: > Hi all, > > please review a new test on 8030976 (unstable_if trap). > > The test simply execute a method with an "if" only one > of whose branches is always taken. > After that compilation log is analyzed in order to find > expected trap for appropriate bci. > > In order to obtain correct bci number the tested method is > constructed using asmlib. > > Bug-id: https://bugs.openjdk.java.net/browse/JDK-8059342 > Webrev: http://cr.openjdk.java.net/~fzhinkin/8059342/webrev.00/ > Testing: JPRT, manual & automated > > Thanks, > Filipp. >