From goetz.lindenmaier at sap.com Tue May 6 10:17:34 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 May 2014 10:17:34 +0000 Subject: RFR(M): 8042309: Some bugfixes for the ppc64 port. Message-ID: <4295855A5C1DE049A61835A1887419CC2CEBFC0A@DEWDFEMB12A.global.corp.sap> Hi, please review this change. I also please need a sponsor. It should go to jdk8u20 at some point. It only touches files needed for the ppc64 port. http://cr.openjdk.java.net/~goetz/webrevs/8042309/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8042309 This change fixes a few bugs in the ppc64 port: * Expand of max/min nodes in .ad file relied on 64-bit sign extend but placed the values in 32-bit registers. After SpillCopies the upper bits were lost. * Expand of decodeNKlass used wrong node. * Implement missing support for method handles in generate_throw_exception. * Some small optimizations and cleanups. Thanks and best regards, Goetz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue May 6 18:55:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 May 2014 11:55:13 -0700 Subject: RFR(M): 8042309: Some bugfixes for the ppc64 port. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEBFC0A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEBFC0A@DEWDFEMB12A.global.corp.sap> Message-ID: <53693011.2080100@oracle.com> Looks fine to me. Only minor issues in ppc.ad: New vtable_index is not used. It is strange to see predicate(false) in expanded instructions. Thanks, Vladimir On 5/6/14 3:17 AM, Lindenmaier, Goetz wrote: > Hi, > > please review this change. I also please need a sponsor. > It should go to jdk8u20 at some point. It only touches files > needed for the ppc64 port. > http://cr.openjdk.java.net/~goetz/webrevs/8042309/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8042309 > > This change fixes a few bugs in the ppc64 port: > > * Expand of max/min nodes in .ad file relied on 64-bit sign extend > but placed the values in 32-bit registers. After SpillCopies > the upper bits were lost. > * Expand of decodeNKlass used wrong node. > * Implement missing support for method handles in generate_throw_exception. > * Some small optimizations and cleanups. > > Thanks and best regards, > Goetz. > From goetz.lindenmaier at sap.com Tue May 6 19:22:19 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 May 2014 19:22:19 +0000 Subject: RFR(M): 8042309: Some bugfixes for the ppc64 port. In-Reply-To: <53693011.2080100@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEBFC0A@DEWDFEMB12A.global.corp.sap> <53693011.2080100@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEBFF70@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I removed the dead variable and updated the webrev. I also removed a debug print. In the expanded nodes we need mach rules so they get the poper funcionaltiy generated by adlc, but we don't want them to match, as they not fully implement the required functionality. We use that quite often. Thanks for the review, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, May 06, 2014 8:55 PM To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8042309: Some bugfixes for the ppc64 port. Looks fine to me. Only minor issues in ppc.ad: New vtable_index is not used. It is strange to see predicate(false) in expanded instructions. Thanks, Vladimir On 5/6/14 3:17 AM, Lindenmaier, Goetz wrote: > Hi, > > please review this change. I also please need a sponsor. > It should go to jdk8u20 at some point. It only touches files > needed for the ppc64 port. > http://cr.openjdk.java.net/~goetz/webrevs/8042309/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8042309 > > This change fixes a few bugs in the ppc64 port: > > * Expand of max/min nodes in .ad file relied on 64-bit sign extend > but placed the values in 32-bit registers. After SpillCopies > the upper bits were lost. > * Expand of decodeNKlass used wrong node. > * Implement missing support for method handles in generate_throw_exception. > * Some small optimizations and cleanups. > > Thanks and best regards, > Goetz. > From vladimir.kozlov at oracle.com Tue May 6 19:44:45 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 May 2014 12:44:45 -0700 Subject: RFR(M): 8042309: Some bugfixes for the ppc64 port. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEBFF70@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEBFC0A@DEWDFEMB12A.global.corp.sap> <53693011.2080100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEBFF70@DEWDFEMB12A.global.corp.sap> Message-ID: <53693BAD.8080707@oracle.com> Good. The push job is in JPRT. Thanks, Vladimir On 5/6/14 12:22 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I removed the dead variable and updated the webrev. > I also removed a debug print. > > In the expanded nodes we need mach rules so they get > the poper funcionaltiy generated by adlc, but we don't > want them to match, as they not fully implement the > required functionality. We use that quite often. > > Thanks for the review, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Tuesday, May 06, 2014 8:55 PM > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8042309: Some bugfixes for the ppc64 port. > > Looks fine to me. Only minor issues in ppc.ad: > New vtable_index is not used. > It is strange to see predicate(false) in expanded instructions. > > Thanks, > Vladimir > > On 5/6/14 3:17 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> please review this change. I also please need a sponsor. >> It should go to jdk8u20 at some point. It only touches files >> needed for the ppc64 port. >> http://cr.openjdk.java.net/~goetz/webrevs/8042309/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8042309 >> >> This change fixes a few bugs in the ppc64 port: >> >> * Expand of max/min nodes in .ad file relied on 64-bit sign extend >> but placed the values in 32-bit registers. After SpillCopies >> the upper bits were lost. >> * Expand of decodeNKlass used wrong node. >> * Implement missing support for method handles in generate_throw_exception. >> * Some small optimizations and cleanups. >> >> Thanks and best regards, >> Goetz. >> From vladimir.kozlov at oracle.com Wed May 7 00:05:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 May 2014 17:05:36 -0700 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: References: Message-ID: <536978D0.7060901@oracle.com> I think we need to let SAP know about this change (counter code in C2) since it may affect their tiered compilation. It use the same Deoptimization::Reason_age. Can you separate C1 trap_request newa code in a separate RFE and push it first? Can you add the field to MDO and not to MethodCounters? We doing this only for methods which were compiled already and have MDO. MethodCounters small size is important. Can you use Method* method instead of next expression?: MethodCounters::should_nmethod_age(method()->nmethod_age()) like: method()->should_nmethod_age(). Also the name is not good, I think. How about profile_aging()? Rename Parse::decrement_code_age() --> Parse::decrement_age(). Add comment to _age_code in compile.hpp Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in nmethod::inc_decompile_count(), I think. In globals.hpp flags description indention is off. sweeper.cpp: // The stack-scanning low-cost detection may not see the method was used (which can happen for // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the existing Why do you need to repeat? For small leaf nmethods (with no safepoint, for example) it could trigger continues recompilation: + if (time_since_reset > MinPassesBeforeFlush * 2) { + // It's been long enough, we still haven't seen it on stack. + // Try to flush it, but enable counters the next time. + mc->reset_nmethod_age(); Thanks, Vladimir On 5/5/14 7:44 PM, Igor Veresov wrote: > The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows: > > 1. Initially a method is compiled as usual (no instrumentation, no overhead). > 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code. > 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter. > 4. The value of the counter is then used by the sweeper to determine is the method is in fact used. > 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again. > > Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ > > Testing: > - jprt, > - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations. > > igor > From goetz.lindenmaier at sap.com Wed May 7 07:29:54 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 May 2014 07:29:54 +0000 Subject: RFR(M): 8042309: Some bugfixes for the ppc64 port. In-Reply-To: <53693BAD.8080707@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CEBFC0A@DEWDFEMB12A.global.corp.sap> <53693011.2080100@oracle.com> <4295855A5C1DE049A61835A1887419CC2CEBFF70@DEWDFEMB12A.global.corp.sap> <53693BAD.8080707@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC0078@DEWDFEMB12A.global.corp.sap> Thanks for pushing this, Vladimir! Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Tuesday, May 06, 2014 9:45 PM To: Lindenmaier, Goetz; 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net' Subject: Re: RFR(M): 8042309: Some bugfixes for the ppc64 port. Good. The push job is in JPRT. Thanks, Vladimir On 5/6/14 12:22 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I removed the dead variable and updated the webrev. > I also removed a debug print. > > In the expanded nodes we need mach rules so they get > the poper funcionaltiy generated by adlc, but we don't > want them to match, as they not fully implement the > required functionality. We use that quite often. > > Thanks for the review, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Tuesday, May 06, 2014 8:55 PM > To: Lindenmaier, Goetz; hotspot-dev at openjdk.java.net; 'ppc-aix-port-dev at openjdk.java.net' > Subject: Re: RFR(M): 8042309: Some bugfixes for the ppc64 port. > > Looks fine to me. Only minor issues in ppc.ad: > New vtable_index is not used. > It is strange to see predicate(false) in expanded instructions. > > Thanks, > Vladimir > > On 5/6/14 3:17 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> please review this change. I also please need a sponsor. >> It should go to jdk8u20 at some point. It only touches files >> needed for the ppc64 port. >> http://cr.openjdk.java.net/~goetz/webrevs/8042309/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8042309 >> >> This change fixes a few bugs in the ppc64 port: >> >> * Expand of max/min nodes in .ad file relied on 64-bit sign extend >> but placed the values in 32-bit registers. After SpillCopies >> the upper bits were lost. >> * Expand of decodeNKlass used wrong node. >> * Implement missing support for method handles in generate_throw_exception. >> * Some small optimizations and cleanups. >> >> Thanks and best regards, >> Goetz. >> From igor.veresov at oracle.com Wed May 7 07:37:18 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 7 May 2014 00:37:18 -0700 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: <536978D0.7060901@oracle.com> References: <536978D0.7060901@oracle.com> Message-ID: <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> Vladimir, Thanks for the review! Please find the reply inline. igor On May 6, 2014, at 5:05 PM, Vladimir Kozlov wrote: > I think we need to let SAP know about this change (counter code in C2) since it may affect their tiered compilation. It use the same Deoptimization::Reason_age. > Oh, I didn?t know that. I?ll introduce another constant. > Can you separate C1 trap_request newa code in a separate RFE and push it first? > Do you think this is necessary? It so happens that the DeoptimizeStub was not used before this by any code. So the aging scheme is the only user of it so far. > Can you add the field to MDO and not to MethodCounters? We doing this only for methods which were compiled already and have MDO. MethodCounters small size is important. It was in MDO originally, unfortunately I have to make it work for pure C1 and we usually don?t allocate MDOs in that configuration. Although, we need to only allocate MDOs for methods with aging, a set of which may be would be smallish.. But MDOs are kind of big.. Would that be better? > > Can you use Method* method instead of next expression?: > > MethodCounters::should_nmethod_age(method()->nmethod_age()) > > like: method()->should_nmethod_age(). > > Also the name is not good, I think. How about profile_aging()? Ok, I?ll add this. > > Rename Parse::decrement_code_age() --> Parse::decrement_age(). Ok > > Add comment to _age_code in compile.hpp > Ok > Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in nmethod::inc_decompile_count(), I think. You?re right, for pure C1 that won?t work anyways, because there are no MDOs. I?ll remove these for now. I probably need another decompile counter to put a cap on the number of recompiles, see the idea below. > In globals.hpp flags description indention is off. > Fixed. > sweeper.cpp: > > // The stack-scanning low-cost detection may not see the method was used (which can happen for > > // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the existing > > Why do you need to repeat? For small leaf nmethods (with no safepoint, for example) it could trigger continues recompilation: > > + if (time_since_reset > MinPassesBeforeFlush * 2) { > + // It's been long enough, we still haven't seen it on stack. > + // Try to flush it, but enable counters the next time. > + mc->reset_nmethod_age(); > That?s a good question. Before this change we would?ve recompiled warm methods continuously (given some code cache pressure), so the number of such cases is probably small. The options here with the code aging are: - don?t ever again flush a method that we?ve seen deopt once; - allow the flusher machinery to get rid of it if it becomes idle again. Currently I decided to stick with the latter but also give the method twice the standard time initially to be noticed by the stack-walker. You are right that there is a problem for small methods. Technically there is always one safepoint in the epilog though, right? I?m good with either option. Vladimir, what are your thoughts on this? Albert, if you skimming through this, what do you think? Here is an idea... We could count the number of decompiles for this particular reason and use it to scale the number of stack-walks we have to do before we flush the method again. For example we can wait MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. Essentially this makes it unflushable in the limit - a combination of the two options above. I?ll need to allocate an MDO or add another counter to methodCounters for that though, or pack a small value info method_age itself, at the expense of a slightly bigger code. And there is an MT problem, as usual, with counting the number of deopts. Here is the updated (with the changes addressed so far) webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ Thanks, igor > Thanks, > Vladimir > > On 5/5/14 7:44 PM, Igor Veresov wrote: >> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows: >> >> 1. Initially a method is compiled as usual (no instrumentation, no overhead). >> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code. >> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter. >> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used. >> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >> >> Testing: >> - jprt, >> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations. >> >> igor >> From vladimir.kozlov at oracle.com Wed May 7 21:27:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 May 2014 14:27:22 -0700 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> References: <536978D0.7060901@oracle.com> <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> Message-ID: <536AA53A.7050408@oracle.com> On 5/7/14 12:37 AM, Igor Veresov wrote: > Vladimir, > > Thanks for the review! > Please find the reply inline. > > igor > > On May 6, 2014, at 5:05 PM, Vladimir Kozlov wrote: > >> I think we need to let SAP know about this change (counter code in C2) since it may affect their tiered compilation. It use the same Deoptimization::Reason_age. >> > Oh, I didn?t know that. I?ll introduce another constant. > >> Can you separate C1 trap_request newa code in a separate RFE and push it first? >> > > Do you think this is necessary? It so happens that the DeoptimizeStub was not used before this by any code. So the aging scheme is the only user of it so far. I am fine to keep it in this fix but I can't review it. Ask Christian to look. > >> Can you add the field to MDO and not to MethodCounters? We doing this only for methods which were compiled already and have MDO. MethodCounters small size is important. > > It was in MDO originally, unfortunately I have to make it work for pure C1 and we usually don?t allocate MDOs in that configuration. Although, we need to only allocate MDOs for methods with aging, a set of which may be would be smallish.. But MDOs are kind of big.. Would that be better? I forgot about pure C1. Chris Plummer pointed me, for RTM changes, MethodCounters are allocated for all executed methods which may not be compiled. About 30% methods are executed. > >> Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in nmethod::inc_decompile_count(), I think. > > You?re right, for pure C1 that won?t work anyways, because there are no MDOs. I?ll remove these for now. I probably need another decompile counter to put a cap on the number of recompiles, see the idea below. > >> In globals.hpp flags description indention is off. >> > > Fixed. You moved it to opposite direction :) . Indention of all comments are the same in the file. They are not aligned to a flag's declaration line. > >> sweeper.cpp: >> >> // The stack-scanning low-cost detection may not see the method was used (which can happen for >> >> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the existing You did not change above comments as I suggested. >> >> Why do you need to repeat? For small leaf nmethods (with no safepoint, for example) it could trigger continues recompilation: >> >> + if (time_since_reset > MinPassesBeforeFlush * 2) { >> + // It's been long enough, we still haven't seen it on stack. >> + // Try to flush it, but enable counters the next time. >> + mc->reset_nmethod_age(); >> > > That?s a good question. Before this change we would?ve recompiled warm methods continuously (given some code cache pressure), so the number of such cases is probably small. The options here with the code aging are: > - don?t ever again flush a method that we?ve seen deopt once; > - allow the flusher machinery to get rid of it if it becomes idle again. > > Currently I decided to stick with the latter but also give the method twice the standard time initially to be noticed by the stack-walker. You are right that there is a problem for small methods. Technically there is always one safepoint in the epilog though, right? I?m good with either option. Vladimir, what are your thoughts on this? Albert, if you skimming through this, what do you think? > > Here is an idea... We could count the number of decompiles for this particular reason and use it to scale the number of stack-walks we have to do before we flush the method again. For example we can wait MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. Essentially this makes it unflushable in the limit - a combination of the two options above. > I?ll need to allocate an MDO or add another counter to methodCounters for that though, or pack a small value info method_age itself, at the expense of a slightly bigger code. And there is an MT problem, as usual, with counting the number of deopts. As we discussed the check will be scaled by number of recompilation. Thanks, Vladimir > > Here is the updated (with the changes addressed so far) webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ > > Thanks, > igor > >> Thanks, >> Vladimir >> >> On 5/5/14 7:44 PM, Igor Veresov wrote: >>> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows: >>> >>> 1. Initially a method is compiled as usual (no instrumentation, no overhead). >>> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code. >>> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter. >>> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used. >>> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >>> >>> Testing: >>> - jprt, >>> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations. >>> >>> igor >>> > From goetz.lindenmaier at sap.com Thu May 8 14:25:07 2014 From: goetz.lindenmaier at sap.com (goetz.lindenmaier at sap.com) Date: Thu, 08 May 2014 14:25:07 +0000 Subject: hg: ppc-aix-port/jdk7u/hotspot: 8042309: Some bugfixes for the ppc64 port Message-ID: <201405081425.s48EP9ss011124@aojmv0008> Changeset: 1fb2b8c1442c Author: goetz Date: 2014-05-08 16:16 +0200 URL: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/1fb2b8c1442c 8042309: Some bugfixes for the ppc64 port ! src/cpu/ppc/vm/frame_ppc.inline.hpp ! src/cpu/ppc/vm/interpreterRT_ppc.cpp ! src/cpu/ppc/vm/jniFastGetField_ppc.cpp ! src/cpu/ppc/vm/ppc.ad ! src/cpu/ppc/vm/templateInterpreter_ppc.cpp ! src/cpu/ppc/vm/templateTable_ppc_64.cpp From igor.veresov at oracle.com Thu May 8 19:30:33 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 8 May 2014 12:30:33 -0700 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: <536AA53A.7050408@oracle.com> References: <536978D0.7060901@oracle.com> <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> <536AA53A.7050408@oracle.com> Message-ID: <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com> Alright, here is the update: http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/ The change is that I added a trap counter in the MDO that is used to scale up the number of stack walks that are necessary for the tenured method to revert back to the standard flushing policy. This required some changes in c1_Runtime.cpp and deoptimization.cpp to handle these deopts and allocate MDOs (in C1). The counter increment is guarded by the make_not_entrant() call that guarantees that the increment happens only once per method state change. Also fixed the comments in sweeper.cpp and indent in globals.hpp that I forgot to do the last time. Thanks! igor On May 7, 2014, at 2:27 PM, Vladimir Kozlov wrote: > On 5/7/14 12:37 AM, Igor Veresov wrote: >> Vladimir, >> >> Thanks for the review! >> Please find the reply inline. >> >> igor >> >> On May 6, 2014, at 5:05 PM, Vladimir Kozlov wrote: >> >>> I think we need to let SAP know about this change (counter code in C2) since it may affect their tiered compilation. It use the same Deoptimization::Reason_age. >>> >> Oh, I didn?t know that. I?ll introduce another constant. >> >>> Can you separate C1 trap_request newa code in a separate RFE and push it first? >>> >> >> Do you think this is necessary? It so happens that the DeoptimizeStub was not used before this by any code. So the aging scheme is the only user of it so far. > > I am fine to keep it in this fix but I can't review it. Ask Christian to look. > >> >>> Can you add the field to MDO and not to MethodCounters? We doing this only for methods which were compiled already and have MDO. MethodCounters small size is important. >> >> It was in MDO originally, unfortunately I have to make it work for pure C1 and we usually don?t allocate MDOs in that configuration. Although, we need to only allocate MDOs for methods with aging, a set of which may be would be smallish.. But MDOs are kind of big.. Would that be better? > > I forgot about pure C1. > Chris Plummer pointed me, for RTM changes, MethodCounters are allocated for all executed methods which may not be compiled. About 30% methods are executed. > >> >>> Why the change in methodData.hpp and nmethod.cpp? '||' should be '&&' in nmethod::inc_decompile_count(), I think. >> >> You?re right, for pure C1 that won?t work anyways, because there are no MDOs. I?ll remove these for now. I probably need another decompile counter to put a cap on the number of recompiles, see the idea below. >> >>> In globals.hpp flags description indention is off. >>> >> >> Fixed. > > You moved it to opposite direction :) . Indention of all comments are the same in the file. They are not aligned to a flag's declaration line. > >> >>> sweeper.cpp: >>> >>> // The stack-scanning low-cost detection may not see the method was used (which can happen for >>> >>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in the existing > > You did not change above comments as I suggested. > >>> >>> Why do you need to repeat? For small leaf nmethods (with no safepoint, for example) it could trigger continues recompilation: >>> >>> + if (time_since_reset > MinPassesBeforeFlush * 2) { >>> + // It's been long enough, we still haven't seen it on stack. >>> + // Try to flush it, but enable counters the next time. >>> + mc->reset_nmethod_age(); >>> >> >> That?s a good question. Before this change we would?ve recompiled warm methods continuously (given some code cache pressure), so the number of such cases is probably small. The options here with the code aging are: >> - don?t ever again flush a method that we?ve seen deopt once; >> - allow the flusher machinery to get rid of it if it becomes idle again. >> >> Currently I decided to stick with the latter but also give the method twice the standard time initially to be noticed by the stack-walker. You are right that there is a problem for small methods. Technically there is always one safepoint in the epilog though, right? I?m good with either option. Vladimir, what are your thoughts on this? Albert, if you skimming through this, what do you think? >> >> Here is an idea... We could count the number of decompiles for this particular reason and use it to scale the number of stack-walks we have to do before we flush the method again. For example we can wait MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. Essentially this makes it unflushable in the limit - a combination of the two options above. >> I?ll need to allocate an MDO or add another counter to methodCounters for that though, or pack a small value info method_age itself, at the expense of a slightly bigger code. And there is an MT problem, as usual, with counting the number of deopts. > > As we discussed the check will be scaled by number of recompilation. > > Thanks, > Vladimir > >> >> Here is the updated (with the changes addressed so far) webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ >> >> Thanks, >> igor >> >>> Thanks, >>> Vladimir >>> >>> On 5/5/14 7:44 PM, Igor Veresov wrote: >>>> The current implementation of the code cache flusher tries to determine the working set of methods by doing periodic stack walks during safepoints. Methods that are seen on the stack are considered to be used by the program and are excluded from the set of flush candidates. Such sampling is a great zero-overhead approach to collect the working set of super-hot methods without instrumentation. However it doesn?t work that good for flat profiles, which the test in the bug report happens to expose (thousands of methods calls sequentially one after another in the loop). The solution I ended up implementing uses conservative on-demand instrumentation to obtain information about the method usage. The algorithms is as follows: >>>> >>>> 1. Initially a method is compiled as usual (no instrumentation, no overhead). >>>> 2. When the sampling (stack-walking) scheme fails to detect activity we flush the method (again, as usual). However before the flush we set the age counter (an int added to MethodCounters) to a value that instructs the compilers to instrument the code. >>>> 3. If we ever request to compile this method again the aging code is inserted, which decrements the counter. >>>> 4. The value of the counter is then used by the sweeper to determine is the method is in fact used. >>>> 5. If the counter reaches zero before the sweeper is able examine and reset the counter we deopt and recompile the method without the counters, basically switching it back to use the sampling scheme again. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >>>> >>>> Testing: >>>> - jprt, >>>> - aurora-perf No performance effects with the default code cache, since we have enough headroom and the flusher is not exercised that much. No statistically significant effects after warmup (for spec benchmarks) in stress mode (-XX:+StressCodeAging) either, that is if all methods are compiled initially with counters deopt and switch to sampling later after 100000 invocations. >>>> >>>> igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri May 9 01:28:43 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 May 2014 18:28:43 -0700 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com> References: <536978D0.7060901@oracle.com> <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> <536AA53A.7050408@oracle.com> <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com> Message-ID: <536C2F4B.6060405@oracle.com> Looks good. Thanks, Vladimir On 5/8/14 12:30 PM, Igor Veresov wrote: > Alright, here is the update: > http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/ > > The change is that I added a trap counter in the MDO that is used to > scale up the number of stack walks that are necessary for the tenured > method to revert back to the standard flushing policy. This required > some changes in c1_Runtime.cpp and deoptimization.cpp to handle these > deopts and allocate MDOs (in C1). The counter increment is guarded by > the make_not_entrant() call that guarantees that the increment happens > only once per method state change. > Also fixed the comments in sweeper.cpp and indent in globals.hpp that I > forgot to do the last time. > > Thanks! > igor > > > On May 7, 2014, at 2:27 PM, Vladimir Kozlov > wrote: > >> On 5/7/14 12:37 AM, Igor Veresov wrote: >>> Vladimir, >>> >>> Thanks for the review! >>> Please find the reply inline. >>> >>> igor >>> >>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov >>> > wrote: >>> >>>> I think we need to let SAP know about this change (counter code in >>>> C2) since it may affect their tiered compilation. It use the same >>>> Deoptimization::Reason_age. >>>> >>> Oh, I didn?t know that. I?ll introduce another constant. >>> >>>> Can you separate C1 trap_request newa code in a separate RFE and >>>> push it first? >>>> >>> >>> Do you think this is necessary? It so happens that the DeoptimizeStub >>> was not used before this by any code. So the aging scheme is the only >>> user of it so far. >> >> I am fine to keep it in this fix but I can't review it. Ask Christian >> to look. >> >>> >>>> Can you add the field to MDO and not to MethodCounters? We doing >>>> this only for methods which were compiled already and have MDO. >>>> MethodCounters small size is important. >>> >>> It was in MDO originally, unfortunately I have to make it work for >>> pure C1 and we usually don?t allocate MDOs in that configuration. >>> Although, we need to only allocate MDOs for methods with aging, a set >>> of which may be would be smallish.. But MDOs are kind of big.. Would >>> that be better? >> >> I forgot about pure C1. >> Chris Plummer pointed me, for RTM changes, MethodCounters are >> allocated for all executed methods which may not be compiled. About >> 30% methods are executed. >> >>> >>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be >>>> '&&' in nmethod::inc_decompile_count(), I think. >>> >>> You?re right, for pure C1 that won?t work anyways, because there are >>> no MDOs. I?ll remove these for now. I probably need another decompile >>> counter to put a cap on the number of recompiles, see the idea below. >>> >>>> In globals.hpp flags description indention is off. >>>> >>> >>> Fixed. >> >> You moved it to opposite direction :) . Indention of all comments are >> the same in the file. They are not aligned to a flag's declaration line. >> >>> >>>> sweeper.cpp: >>>> >>>> // The stack-scanning low-cost detection may not see the method was >>>> used (which can happen for >>>> >>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in >>>> the existing >> >> You did not change above comments as I suggested. >> >>>> >>>> Why do you need to repeat? For small leaf nmethods (with no >>>> safepoint, for example) it could trigger continues recompilation: >>>> >>>> + if (time_since_reset > MinPassesBeforeFlush * 2) { >>>> + // It's been long enough, we still haven't seen it >>>> on stack. >>>> + // Try to flush it, but enable counters the next time. >>>> + mc->reset_nmethod_age(); >>>> >>> >>> That?s a good question. Before this change we would?ve recompiled >>> warm methods continuously (given some code cache pressure), so the >>> number of such cases is probably small. The options here with the >>> code aging are: >>> - don?t ever again flush a method that we?ve seen deopt once; >>> - allow the flusher machinery to get rid of it if it becomes idle again. >>> >>> Currently I decided to stick with the latter but also give the method >>> twice the standard time initially to be noticed by the stack-walker. >>> You are right that there is a problem for small methods. Technically >>> there is always one safepoint in the epilog though, right? I?m good >>> with either option. Vladimir, what are your thoughts on this? Albert, >>> if you skimming through this, what do you think? >>> >>> Here is an idea... We could count the number of decompiles for this >>> particular reason and use it to scale the number of stack-walks we >>> have to do before we flush the method again. For example we can wait >>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. >>> Essentially this makes it unflushable in the limit - a combination of >>> the two options above. >>> I?ll need to allocate an MDO or add another counter to methodCounters >>> for that though, or pack a small value info method_age itself, at the >>> expense of a slightly bigger code. And there is an MT problem, as >>> usual, with counting the number of deopts. >> >> As we discussed the check will be scaled by number of recompilation. >> >> Thanks, >> Vladimir >> >>> >>> Here is the updated (with the changes addressed so far) webrev: >>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ >>> >>> Thanks, >>> igor >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/5/14 7:44 PM, Igor Veresov wrote: >>>>> The current implementation of the code cache flusher tries to >>>>> determine the working set of methods by doing periodic stack walks >>>>> during safepoints. Methods that are seen on the stack are >>>>> considered to be used by the program and are excluded from the set >>>>> of flush candidates. Such sampling is a great zero-overhead >>>>> approach to collect the working set of super-hot methods without >>>>> instrumentation. However it doesn?t work that good for flat >>>>> profiles, which the test in the bug report happens to expose >>>>> (thousands of methods calls sequentially one after another in the >>>>> loop). The solution I ended up implementing uses conservative >>>>> on-demand instrumentation to obtain information about the method >>>>> usage. The algorithms is as follows: >>>>> >>>>> 1. Initially a method is compiled as usual (no instrumentation, no >>>>> overhead). >>>>> 2. When the sampling (stack-walking) scheme fails to detect >>>>> activity we flush the method (again, as usual). However before the >>>>> flush we set the age counter (an int added to MethodCounters) to a >>>>> value that instructs the compilers to instrument the code. >>>>> 3. If we ever request to compile this method again the aging code >>>>> is inserted, which decrements the counter. >>>>> 4. The value of the counter is then used by the sweeper to >>>>> determine is the method is in fact used. >>>>> 5. If the counter reaches zero before the sweeper is able examine >>>>> and reset the counter we deopt and recompile the method without the >>>>> counters, basically switching it back to use the sampling scheme again. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >>>>> >>>>> Testing: >>>>> - jprt, >>>>> - aurora-perf No performance effects with the default code cache, >>>>> since we have enough headroom and the flusher is not exercised that >>>>> much. No statistically significant effects after warmup (for spec >>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is >>>>> if all methods are compiled initially with counters deopt and >>>>> switch to sampling later after 100000 invocations. >>>>> >>>>> igor > From christian.thalinger at oracle.com Fri May 9 02:25:18 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 May 2014 16:25:18 -1000 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: <536C2F4B.6060405@oracle.com> References: <536978D0.7060901@oracle.com> <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> <536AA53A.7050408@oracle.com> <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com> <536C2F4B.6060405@oracle.com> Message-ID: src/share/vm/c1/c1_Runtime1.cpp + nmethod* nm = (nmethod*)caller_frame.cb(); + assert(nm != NULL && nm->is_nmethod(), "Sanity check"); There is CodeBlob::as_nmethod_or_null(). The C1 code looks good. On May 8, 2014, at 3:28 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/8/14 12:30 PM, Igor Veresov wrote: >> Alright, here is the update: >> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/ >> >> The change is that I added a trap counter in the MDO that is used to >> scale up the number of stack walks that are necessary for the tenured >> method to revert back to the standard flushing policy. This required >> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these >> deopts and allocate MDOs (in C1). The counter increment is guarded by >> the make_not_entrant() call that guarantees that the increment happens >> only once per method state change. >> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I >> forgot to do the last time. >> >> Thanks! >> igor >> >> >> On May 7, 2014, at 2:27 PM, Vladimir Kozlov > > wrote: >> >>> On 5/7/14 12:37 AM, Igor Veresov wrote: >>>> Vladimir, >>>> >>>> Thanks for the review! >>>> Please find the reply inline. >>>> >>>> igor >>>> >>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov >>>> > wrote: >>>> >>>>> I think we need to let SAP know about this change (counter code in >>>>> C2) since it may affect their tiered compilation. It use the same >>>>> Deoptimization::Reason_age. >>>>> >>>> Oh, I didn?t know that. I?ll introduce another constant. >>>> >>>>> Can you separate C1 trap_request newa code in a separate RFE and >>>>> push it first? >>>>> >>>> >>>> Do you think this is necessary? It so happens that the DeoptimizeStub >>>> was not used before this by any code. So the aging scheme is the only >>>> user of it so far. >>> >>> I am fine to keep it in this fix but I can't review it. Ask Christian >>> to look. >>> >>>> >>>>> Can you add the field to MDO and not to MethodCounters? We doing >>>>> this only for methods which were compiled already and have MDO. >>>>> MethodCounters small size is important. >>>> >>>> It was in MDO originally, unfortunately I have to make it work for >>>> pure C1 and we usually don?t allocate MDOs in that configuration. >>>> Although, we need to only allocate MDOs for methods with aging, a set >>>> of which may be would be smallish.. But MDOs are kind of big.. Would >>>> that be better? >>> >>> I forgot about pure C1. >>> Chris Plummer pointed me, for RTM changes, MethodCounters are >>> allocated for all executed methods which may not be compiled. About >>> 30% methods are executed. >>> >>>> >>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be >>>>> '&&' in nmethod::inc_decompile_count(), I think. >>>> >>>> You?re right, for pure C1 that won?t work anyways, because there are >>>> no MDOs. I?ll remove these for now. I probably need another decompile >>>> counter to put a cap on the number of recompiles, see the idea below. >>>> >>>>> In globals.hpp flags description indention is off. >>>>> >>>> >>>> Fixed. >>> >>> You moved it to opposite direction :) . Indention of all comments are >>> the same in the file. They are not aligned to a flag's declaration line. >>> >>>> >>>>> sweeper.cpp: >>>>> >>>>> // The stack-scanning low-cost detection may not see the method was >>>>> used (which can happen for >>>>> >>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in >>>>> the existing >>> >>> You did not change above comments as I suggested. >>> >>>>> >>>>> Why do you need to repeat? For small leaf nmethods (with no >>>>> safepoint, for example) it could trigger continues recompilation: >>>>> >>>>> + if (time_since_reset > MinPassesBeforeFlush * 2) { >>>>> + // It's been long enough, we still haven't seen it >>>>> on stack. >>>>> + // Try to flush it, but enable counters the next time. >>>>> + mc->reset_nmethod_age(); >>>>> >>>> >>>> That?s a good question. Before this change we would?ve recompiled >>>> warm methods continuously (given some code cache pressure), so the >>>> number of such cases is probably small. The options here with the >>>> code aging are: >>>> - don?t ever again flush a method that we?ve seen deopt once; >>>> - allow the flusher machinery to get rid of it if it becomes idle again. >>>> >>>> Currently I decided to stick with the latter but also give the method >>>> twice the standard time initially to be noticed by the stack-walker. >>>> You are right that there is a problem for small methods. Technically >>>> there is always one safepoint in the epilog though, right? I?m good >>>> with either option. Vladimir, what are your thoughts on this? Albert, >>>> if you skimming through this, what do you think? >>>> >>>> Here is an idea... We could count the number of decompiles for this >>>> particular reason and use it to scale the number of stack-walks we >>>> have to do before we flush the method again. For example we can wait >>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. >>>> Essentially this makes it unflushable in the limit - a combination of >>>> the two options above. >>>> I?ll need to allocate an MDO or add another counter to methodCounters >>>> for that though, or pack a small value info method_age itself, at the >>>> expense of a slightly bigger code. And there is an MT problem, as >>>> usual, with counting the number of deopts. >>> >>> As we discussed the check will be scaled by number of recompilation. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Here is the updated (with the changes addressed so far) webrev: >>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ >>>> >>>> Thanks, >>>> igor >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 5/5/14 7:44 PM, Igor Veresov wrote: >>>>>> The current implementation of the code cache flusher tries to >>>>>> determine the working set of methods by doing periodic stack walks >>>>>> during safepoints. Methods that are seen on the stack are >>>>>> considered to be used by the program and are excluded from the set >>>>>> of flush candidates. Such sampling is a great zero-overhead >>>>>> approach to collect the working set of super-hot methods without >>>>>> instrumentation. However it doesn?t work that good for flat >>>>>> profiles, which the test in the bug report happens to expose >>>>>> (thousands of methods calls sequentially one after another in the >>>>>> loop). The solution I ended up implementing uses conservative >>>>>> on-demand instrumentation to obtain information about the method >>>>>> usage. The algorithms is as follows: >>>>>> >>>>>> 1. Initially a method is compiled as usual (no instrumentation, no >>>>>> overhead). >>>>>> 2. When the sampling (stack-walking) scheme fails to detect >>>>>> activity we flush the method (again, as usual). However before the >>>>>> flush we set the age counter (an int added to MethodCounters) to a >>>>>> value that instructs the compilers to instrument the code. >>>>>> 3. If we ever request to compile this method again the aging code >>>>>> is inserted, which decrements the counter. >>>>>> 4. The value of the counter is then used by the sweeper to >>>>>> determine is the method is in fact used. >>>>>> 5. If the counter reaches zero before the sweeper is able examine >>>>>> and reset the counter we deopt and recompile the method without the >>>>>> counters, basically switching it back to use the sampling scheme again. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - jprt, >>>>>> - aurora-perf No performance effects with the default code cache, >>>>>> since we have enough headroom and the flusher is not exercised that >>>>>> much. No statistically significant effects after warmup (for spec >>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is >>>>>> if all methods are compiled initially with counters deopt and >>>>>> switch to sampling later after 100000 invocations. >>>>>> >>>>>> igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Fri May 9 02:35:15 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 8 May 2014 19:35:15 -0700 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: <536C2F4B.6060405@oracle.com> References: <536978D0.7060901@oracle.com> <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> <536AA53A.7050408@oracle.com> <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com> <536C2F4B.6060405@oracle.com> Message-ID: <0487BADD-BF7A-4F80-871A-3ABF3ECECA35@oracle.com> Thanks, Vladimir! igor On May 8, 2014, at 6:28 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/8/14 12:30 PM, Igor Veresov wrote: >> Alright, here is the update: >> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/ >> >> The change is that I added a trap counter in the MDO that is used to >> scale up the number of stack walks that are necessary for the tenured >> method to revert back to the standard flushing policy. This required >> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these >> deopts and allocate MDOs (in C1). The counter increment is guarded by >> the make_not_entrant() call that guarantees that the increment happens >> only once per method state change. >> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I >> forgot to do the last time. >> >> Thanks! >> igor >> >> >> On May 7, 2014, at 2:27 PM, Vladimir Kozlov > > wrote: >> >>> On 5/7/14 12:37 AM, Igor Veresov wrote: >>>> Vladimir, >>>> >>>> Thanks for the review! >>>> Please find the reply inline. >>>> >>>> igor >>>> >>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov >>>> > wrote: >>>> >>>>> I think we need to let SAP know about this change (counter code in >>>>> C2) since it may affect their tiered compilation. It use the same >>>>> Deoptimization::Reason_age. >>>>> >>>> Oh, I didn?t know that. I?ll introduce another constant. >>>> >>>>> Can you separate C1 trap_request newa code in a separate RFE and >>>>> push it first? >>>>> >>>> >>>> Do you think this is necessary? It so happens that the DeoptimizeStub >>>> was not used before this by any code. So the aging scheme is the only >>>> user of it so far. >>> >>> I am fine to keep it in this fix but I can't review it. Ask Christian >>> to look. >>> >>>> >>>>> Can you add the field to MDO and not to MethodCounters? We doing >>>>> this only for methods which were compiled already and have MDO. >>>>> MethodCounters small size is important. >>>> >>>> It was in MDO originally, unfortunately I have to make it work for >>>> pure C1 and we usually don?t allocate MDOs in that configuration. >>>> Although, we need to only allocate MDOs for methods with aging, a set >>>> of which may be would be smallish.. But MDOs are kind of big.. Would >>>> that be better? >>> >>> I forgot about pure C1. >>> Chris Plummer pointed me, for RTM changes, MethodCounters are >>> allocated for all executed methods which may not be compiled. About >>> 30% methods are executed. >>> >>>> >>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be >>>>> '&&' in nmethod::inc_decompile_count(), I think. >>>> >>>> You?re right, for pure C1 that won?t work anyways, because there are >>>> no MDOs. I?ll remove these for now. I probably need another decompile >>>> counter to put a cap on the number of recompiles, see the idea below. >>>> >>>>> In globals.hpp flags description indention is off. >>>>> >>>> >>>> Fixed. >>> >>> You moved it to opposite direction :) . Indention of all comments are >>> the same in the file. They are not aligned to a flag's declaration line. >>> >>>> >>>>> sweeper.cpp: >>>>> >>>>> // The stack-scanning low-cost detection may not see the method was >>>>> used (which can happen for >>>>> >>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in >>>>> the existing >>> >>> You did not change above comments as I suggested. >>> >>>>> >>>>> Why do you need to repeat? For small leaf nmethods (with no >>>>> safepoint, for example) it could trigger continues recompilation: >>>>> >>>>> + if (time_since_reset > MinPassesBeforeFlush * 2) { >>>>> + // It's been long enough, we still haven't seen it >>>>> on stack. >>>>> + // Try to flush it, but enable counters the next time. >>>>> + mc->reset_nmethod_age(); >>>>> >>>> >>>> That?s a good question. Before this change we would?ve recompiled >>>> warm methods continuously (given some code cache pressure), so the >>>> number of such cases is probably small. The options here with the >>>> code aging are: >>>> - don?t ever again flush a method that we?ve seen deopt once; >>>> - allow the flusher machinery to get rid of it if it becomes idle again. >>>> >>>> Currently I decided to stick with the latter but also give the method >>>> twice the standard time initially to be noticed by the stack-walker. >>>> You are right that there is a problem for small methods. Technically >>>> there is always one safepoint in the epilog though, right? I?m good >>>> with either option. Vladimir, what are your thoughts on this? Albert, >>>> if you skimming through this, what do you think? >>>> >>>> Here is an idea... We could count the number of decompiles for this >>>> particular reason and use it to scale the number of stack-walks we >>>> have to do before we flush the method again. For example we can wait >>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. >>>> Essentially this makes it unflushable in the limit - a combination of >>>> the two options above. >>>> I?ll need to allocate an MDO or add another counter to methodCounters >>>> for that though, or pack a small value info method_age itself, at the >>>> expense of a slightly bigger code. And there is an MT problem, as >>>> usual, with counting the number of deopts. >>> >>> As we discussed the check will be scaled by number of recompilation. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Here is the updated (with the changes addressed so far) webrev: >>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ >>>> >>>> Thanks, >>>> igor >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 5/5/14 7:44 PM, Igor Veresov wrote: >>>>>> The current implementation of the code cache flusher tries to >>>>>> determine the working set of methods by doing periodic stack walks >>>>>> during safepoints. Methods that are seen on the stack are >>>>>> considered to be used by the program and are excluded from the set >>>>>> of flush candidates. Such sampling is a great zero-overhead >>>>>> approach to collect the working set of super-hot methods without >>>>>> instrumentation. However it doesn?t work that good for flat >>>>>> profiles, which the test in the bug report happens to expose >>>>>> (thousands of methods calls sequentially one after another in the >>>>>> loop). The solution I ended up implementing uses conservative >>>>>> on-demand instrumentation to obtain information about the method >>>>>> usage. The algorithms is as follows: >>>>>> >>>>>> 1. Initially a method is compiled as usual (no instrumentation, no >>>>>> overhead). >>>>>> 2. When the sampling (stack-walking) scheme fails to detect >>>>>> activity we flush the method (again, as usual). However before the >>>>>> flush we set the age counter (an int added to MethodCounters) to a >>>>>> value that instructs the compilers to instrument the code. >>>>>> 3. If we ever request to compile this method again the aging code >>>>>> is inserted, which decrements the counter. >>>>>> 4. The value of the counter is then used by the sweeper to >>>>>> determine is the method is in fact used. >>>>>> 5. If the counter reaches zero before the sweeper is able examine >>>>>> and reset the counter we deopt and recompile the method without the >>>>>> counters, basically switching it back to use the sampling scheme again. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >>>>>> >>>>>> Testing: >>>>>> - jprt, >>>>>> - aurora-perf No performance effects with the default code cache, >>>>>> since we have enough headroom and the flusher is not exercised that >>>>>> much. No statistically significant effects after warmup (for spec >>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is >>>>>> if all methods are compiled initially with counters deopt and >>>>>> switch to sampling later after 100000 invocations. >>>>>> >>>>>> igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Fri May 9 02:37:02 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 8 May 2014 19:37:02 -0700 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: References: <536978D0.7060901@oracle.com> <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> <536AA53A.7050408@oracle.com> <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com> <536C2F4B.6060405@oracle.com> Message-ID: <8E2D4585-3D2B-470C-A76D-E70A96AE87EB@oracle.com> Thanks, Chris! Alright, thanks for the hint: http://cr.openjdk.java.net/~iveresov/8032463/webrev.03/ igor On May 8, 2014, at 7:25 PM, Christian Thalinger wrote: > src/share/vm/c1/c1_Runtime1.cpp > + nmethod* nm = (nmethod*)caller_frame.cb(); > + assert(nm != NULL && nm->is_nmethod(), "Sanity check"); > There is CodeBlob::as_nmethod_or_null(). > > The C1 code looks good. > > On May 8, 2014, at 3:28 PM, Vladimir Kozlov wrote: > >> Looks good. >> >> Thanks, >> Vladimir >> >> On 5/8/14 12:30 PM, Igor Veresov wrote: >>> Alright, here is the update: >>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/ >>> >>> The change is that I added a trap counter in the MDO that is used to >>> scale up the number of stack walks that are necessary for the tenured >>> method to revert back to the standard flushing policy. This required >>> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these >>> deopts and allocate MDOs (in C1). The counter increment is guarded by >>> the make_not_entrant() call that guarantees that the increment happens >>> only once per method state change. >>> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I >>> forgot to do the last time. >>> >>> Thanks! >>> igor >>> >>> >>> On May 7, 2014, at 2:27 PM, Vladimir Kozlov >> > wrote: >>> >>>> On 5/7/14 12:37 AM, Igor Veresov wrote: >>>>> Vladimir, >>>>> >>>>> Thanks for the review! >>>>> Please find the reply inline. >>>>> >>>>> igor >>>>> >>>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov >>>>> > wrote: >>>>> >>>>>> I think we need to let SAP know about this change (counter code in >>>>>> C2) since it may affect their tiered compilation. It use the same >>>>>> Deoptimization::Reason_age. >>>>>> >>>>> Oh, I didn?t know that. I?ll introduce another constant. >>>>> >>>>>> Can you separate C1 trap_request newa code in a separate RFE and >>>>>> push it first? >>>>>> >>>>> >>>>> Do you think this is necessary? It so happens that the DeoptimizeStub >>>>> was not used before this by any code. So the aging scheme is the only >>>>> user of it so far. >>>> >>>> I am fine to keep it in this fix but I can't review it. Ask Christian >>>> to look. >>>> >>>>> >>>>>> Can you add the field to MDO and not to MethodCounters? We doing >>>>>> this only for methods which were compiled already and have MDO. >>>>>> MethodCounters small size is important. >>>>> >>>>> It was in MDO originally, unfortunately I have to make it work for >>>>> pure C1 and we usually don?t allocate MDOs in that configuration. >>>>> Although, we need to only allocate MDOs for methods with aging, a set >>>>> of which may be would be smallish.. But MDOs are kind of big.. Would >>>>> that be better? >>>> >>>> I forgot about pure C1. >>>> Chris Plummer pointed me, for RTM changes, MethodCounters are >>>> allocated for all executed methods which may not be compiled. About >>>> 30% methods are executed. >>>> >>>>> >>>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be >>>>>> '&&' in nmethod::inc_decompile_count(), I think. >>>>> >>>>> You?re right, for pure C1 that won?t work anyways, because there are >>>>> no MDOs. I?ll remove these for now. I probably need another decompile >>>>> counter to put a cap on the number of recompiles, see the idea below. >>>>> >>>>>> In globals.hpp flags description indention is off. >>>>>> >>>>> >>>>> Fixed. >>>> >>>> You moved it to opposite direction :) . Indention of all comments are >>>> the same in the file. They are not aligned to a flag's declaration line. >>>> >>>>> >>>>>> sweeper.cpp: >>>>>> >>>>>> // The stack-scanning low-cost detection may not see the method was >>>>>> used (which can happen for >>>>>> >>>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in >>>>>> the existing >>>> >>>> You did not change above comments as I suggested. >>>> >>>>>> >>>>>> Why do you need to repeat? For small leaf nmethods (with no >>>>>> safepoint, for example) it could trigger continues recompilation: >>>>>> >>>>>> + if (time_since_reset > MinPassesBeforeFlush * 2) { >>>>>> + // It's been long enough, we still haven't seen it >>>>>> on stack. >>>>>> + // Try to flush it, but enable counters the next time. >>>>>> + mc->reset_nmethod_age(); >>>>>> >>>>> >>>>> That?s a good question. Before this change we would?ve recompiled >>>>> warm methods continuously (given some code cache pressure), so the >>>>> number of such cases is probably small. The options here with the >>>>> code aging are: >>>>> - don?t ever again flush a method that we?ve seen deopt once; >>>>> - allow the flusher machinery to get rid of it if it becomes idle again. >>>>> >>>>> Currently I decided to stick with the latter but also give the method >>>>> twice the standard time initially to be noticed by the stack-walker. >>>>> You are right that there is a problem for small methods. Technically >>>>> there is always one safepoint in the epilog though, right? I?m good >>>>> with either option. Vladimir, what are your thoughts on this? Albert, >>>>> if you skimming through this, what do you think? >>>>> >>>>> Here is an idea... We could count the number of decompiles for this >>>>> particular reason and use it to scale the number of stack-walks we >>>>> have to do before we flush the method again. For example we can wait >>>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. >>>>> Essentially this makes it unflushable in the limit - a combination of >>>>> the two options above. >>>>> I?ll need to allocate an MDO or add another counter to methodCounters >>>>> for that though, or pack a small value info method_age itself, at the >>>>> expense of a slightly bigger code. And there is an MT problem, as >>>>> usual, with counting the number of deopts. >>>> >>>> As we discussed the check will be scaled by number of recompilation. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Here is the updated (with the changes addressed so far) webrev: >>>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ >>>>> >>>>> Thanks, >>>>> igor >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 5/5/14 7:44 PM, Igor Veresov wrote: >>>>>>> The current implementation of the code cache flusher tries to >>>>>>> determine the working set of methods by doing periodic stack walks >>>>>>> during safepoints. Methods that are seen on the stack are >>>>>>> considered to be used by the program and are excluded from the set >>>>>>> of flush candidates. Such sampling is a great zero-overhead >>>>>>> approach to collect the working set of super-hot methods without >>>>>>> instrumentation. However it doesn?t work that good for flat >>>>>>> profiles, which the test in the bug report happens to expose >>>>>>> (thousands of methods calls sequentially one after another in the >>>>>>> loop). The solution I ended up implementing uses conservative >>>>>>> on-demand instrumentation to obtain information about the method >>>>>>> usage. The algorithms is as follows: >>>>>>> >>>>>>> 1. Initially a method is compiled as usual (no instrumentation, no >>>>>>> overhead). >>>>>>> 2. When the sampling (stack-walking) scheme fails to detect >>>>>>> activity we flush the method (again, as usual). However before the >>>>>>> flush we set the age counter (an int added to MethodCounters) to a >>>>>>> value that instructs the compilers to instrument the code. >>>>>>> 3. If we ever request to compile this method again the aging code >>>>>>> is inserted, which decrements the counter. >>>>>>> 4. The value of the counter is then used by the sweeper to >>>>>>> determine is the method is in fact used. >>>>>>> 5. If the counter reaches zero before the sweeper is able examine >>>>>>> and reset the counter we deopt and recompile the method without the >>>>>>> counters, basically switching it back to use the sampling scheme again. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >>>>>>> >>>>>>> Testing: >>>>>>> - jprt, >>>>>>> - aurora-perf No performance effects with the default code cache, >>>>>>> since we have enough headroom and the flusher is not exercised that >>>>>>> much. No statistically significant effects after warmup (for spec >>>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is >>>>>>> if all methods are compiled initially with counters deopt and >>>>>>> switch to sampling later after 100000 invocations. >>>>>>> >>>>>>> igor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Fri May 9 02:43:05 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 May 2014 16:43:05 -1000 Subject: RFR(L): JDK-8032463 VirtualDispatch test timeout with DeoptimizeALot In-Reply-To: <8E2D4585-3D2B-470C-A76D-E70A96AE87EB@oracle.com> References: <536978D0.7060901@oracle.com> <3EFF6FF5-8FC6-4C85-8CC1-667EA500A6E3@oracle.com> <536AA53A.7050408@oracle.com> <1153D39B-AD1A-4660-A323-2E80731460BE@oracle.com> <536C2F4B.6060405@oracle.com> <8E2D4585-3D2B-470C-A76D-E70A96AE87EB@oracle.com> Message-ID: Good. On May 8, 2014, at 4:37 PM, Igor Veresov wrote: > Thanks, Chris! > > Alright, thanks for the hint: http://cr.openjdk.java.net/~iveresov/8032463/webrev.03/ > > igor > > On May 8, 2014, at 7:25 PM, Christian Thalinger wrote: > >> src/share/vm/c1/c1_Runtime1.cpp >> + nmethod* nm = (nmethod*)caller_frame.cb(); >> + assert(nm != NULL && nm->is_nmethod(), "Sanity check"); >> There is CodeBlob::as_nmethod_or_null(). >> >> The C1 code looks good. >> >> On May 8, 2014, at 3:28 PM, Vladimir Kozlov wrote: >> >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 5/8/14 12:30 PM, Igor Veresov wrote: >>>> Alright, here is the update: >>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.02/ >>>> >>>> The change is that I added a trap counter in the MDO that is used to >>>> scale up the number of stack walks that are necessary for the tenured >>>> method to revert back to the standard flushing policy. This required >>>> some changes in c1_Runtime.cpp and deoptimization.cpp to handle these >>>> deopts and allocate MDOs (in C1). The counter increment is guarded by >>>> the make_not_entrant() call that guarantees that the increment happens >>>> only once per method state change. >>>> Also fixed the comments in sweeper.cpp and indent in globals.hpp that I >>>> forgot to do the last time. >>>> >>>> Thanks! >>>> igor >>>> >>>> >>>> On May 7, 2014, at 2:27 PM, Vladimir Kozlov >>> > wrote: >>>> >>>>> On 5/7/14 12:37 AM, Igor Veresov wrote: >>>>>> Vladimir, >>>>>> >>>>>> Thanks for the review! >>>>>> Please find the reply inline. >>>>>> >>>>>> igor >>>>>> >>>>>> On May 6, 2014, at 5:05 PM, Vladimir Kozlov >>>>>> > wrote: >>>>>> >>>>>>> I think we need to let SAP know about this change (counter code in >>>>>>> C2) since it may affect their tiered compilation. It use the same >>>>>>> Deoptimization::Reason_age. >>>>>>> >>>>>> Oh, I didn?t know that. I?ll introduce another constant. >>>>>> >>>>>>> Can you separate C1 trap_request newa code in a separate RFE and >>>>>>> push it first? >>>>>>> >>>>>> >>>>>> Do you think this is necessary? It so happens that the DeoptimizeStub >>>>>> was not used before this by any code. So the aging scheme is the only >>>>>> user of it so far. >>>>> >>>>> I am fine to keep it in this fix but I can't review it. Ask Christian >>>>> to look. >>>>> >>>>>> >>>>>>> Can you add the field to MDO and not to MethodCounters? We doing >>>>>>> this only for methods which were compiled already and have MDO. >>>>>>> MethodCounters small size is important. >>>>>> >>>>>> It was in MDO originally, unfortunately I have to make it work for >>>>>> pure C1 and we usually don?t allocate MDOs in that configuration. >>>>>> Although, we need to only allocate MDOs for methods with aging, a set >>>>>> of which may be would be smallish.. But MDOs are kind of big.. Would >>>>>> that be better? >>>>> >>>>> I forgot about pure C1. >>>>> Chris Plummer pointed me, for RTM changes, MethodCounters are >>>>> allocated for all executed methods which may not be compiled. About >>>>> 30% methods are executed. >>>>> >>>>>> >>>>>>> Why the change in methodData.hpp and nmethod.cpp? '||' should be >>>>>>> '&&' in nmethod::inc_decompile_count(), I think. >>>>>> >>>>>> You?re right, for pure C1 that won?t work anyways, because there are >>>>>> no MDOs. I?ll remove these for now. I probably need another decompile >>>>>> counter to put a cap on the number of recompiles, see the idea below. >>>>>> >>>>>>> In globals.hpp flags description indention is off. >>>>>>> >>>>>> >>>>>> Fixed. >>>>> >>>>> You moved it to opposite direction :) . Indention of all comments are >>>>> the same in the file. They are not aligned to a flag's declaration line. >>>>> >>>>>> >>>>>>> sweeper.cpp: >>>>>>> >>>>>>> // The stack-scanning low-cost detection may not see the method was >>>>>>> used (which can happen for >>>>>>> >>>>>>> // previous MinPassesBeforeFlush sweeps. Reset the counter. Stay in >>>>>>> the existing >>>>> >>>>> You did not change above comments as I suggested. >>>>> >>>>>>> >>>>>>> Why do you need to repeat? For small leaf nmethods (with no >>>>>>> safepoint, for example) it could trigger continues recompilation: >>>>>>> >>>>>>> + if (time_since_reset > MinPassesBeforeFlush * 2) { >>>>>>> + // It's been long enough, we still haven't seen it >>>>>>> on stack. >>>>>>> + // Try to flush it, but enable counters the next time. >>>>>>> + mc->reset_nmethod_age(); >>>>>>> >>>>>> >>>>>> That?s a good question. Before this change we would?ve recompiled >>>>>> warm methods continuously (given some code cache pressure), so the >>>>>> number of such cases is probably small. The options here with the >>>>>> code aging are: >>>>>> - don?t ever again flush a method that we?ve seen deopt once; >>>>>> - allow the flusher machinery to get rid of it if it becomes idle again. >>>>>> >>>>>> Currently I decided to stick with the latter but also give the method >>>>>> twice the standard time initially to be noticed by the stack-walker. >>>>>> You are right that there is a problem for small methods. Technically >>>>>> there is always one safepoint in the epilog though, right? I?m good >>>>>> with either option. Vladimir, what are your thoughts on this? Albert, >>>>>> if you skimming through this, what do you think? >>>>>> >>>>>> Here is an idea... We could count the number of decompiles for this >>>>>> particular reason and use it to scale the number of stack-walks we >>>>>> have to do before we flush the method again. For example we can wait >>>>>> MinPassesBeforeFlush * number_of_aging_deopts() stack-walks. >>>>>> Essentially this makes it unflushable in the limit - a combination of >>>>>> the two options above. >>>>>> I?ll need to allocate an MDO or add another counter to methodCounters >>>>>> for that though, or pack a small value info method_age itself, at the >>>>>> expense of a slightly bigger code. And there is an MT problem, as >>>>>> usual, with counting the number of deopts. >>>>> >>>>> As we discussed the check will be scaled by number of recompilation. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> Here is the updated (with the changes addressed so far) webrev: >>>>>> http://cr.openjdk.java.net/~iveresov/8032463/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> igor >>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 5/5/14 7:44 PM, Igor Veresov wrote: >>>>>>>> The current implementation of the code cache flusher tries to >>>>>>>> determine the working set of methods by doing periodic stack walks >>>>>>>> during safepoints. Methods that are seen on the stack are >>>>>>>> considered to be used by the program and are excluded from the set >>>>>>>> of flush candidates. Such sampling is a great zero-overhead >>>>>>>> approach to collect the working set of super-hot methods without >>>>>>>> instrumentation. However it doesn?t work that good for flat >>>>>>>> profiles, which the test in the bug report happens to expose >>>>>>>> (thousands of methods calls sequentially one after another in the >>>>>>>> loop). The solution I ended up implementing uses conservative >>>>>>>> on-demand instrumentation to obtain information about the method >>>>>>>> usage. The algorithms is as follows: >>>>>>>> >>>>>>>> 1. Initially a method is compiled as usual (no instrumentation, no >>>>>>>> overhead). >>>>>>>> 2. When the sampling (stack-walking) scheme fails to detect >>>>>>>> activity we flush the method (again, as usual). However before the >>>>>>>> flush we set the age counter (an int added to MethodCounters) to a >>>>>>>> value that instructs the compilers to instrument the code. >>>>>>>> 3. If we ever request to compile this method again the aging code >>>>>>>> is inserted, which decrements the counter. >>>>>>>> 4. The value of the counter is then used by the sweeper to >>>>>>>> determine is the method is in fact used. >>>>>>>> 5. If the counter reaches zero before the sweeper is able examine >>>>>>>> and reset the counter we deopt and recompile the method without the >>>>>>>> counters, basically switching it back to use the sampling scheme again. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8032463/webrev.00/ >>>>>>>> >>>>>>>> Testing: >>>>>>>> - jprt, >>>>>>>> - aurora-perf No performance effects with the default code cache, >>>>>>>> since we have enough headroom and the flusher is not exercised that >>>>>>>> much. No statistically significant effects after warmup (for spec >>>>>>>> benchmarks) in stress mode (-XX:+StressCodeAging) either, that is >>>>>>>> if all methods are compiled initially with counters deopt and >>>>>>>> switch to sampling later after 100000 invocations. >>>>>>>> >>>>>>>> igor >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luchsh at linux.vnet.ibm.com Mon May 12 10:37:29 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 12 May 2014 18:37:29 +0800 Subject: Review request for 8034218: AIX: Provide a better fontconfig.properties file Message-ID: Hi awt-dev, Please review the fix for issue: https://bugs.openjdk.java.net/browse/JDK-8034218 The changes are placed at http://cr.openjdk.java.net/~luchsh/JDK-8034218/ This patch is trying to provide a better fonctconfig.properties file for AIX platform, which contains support for more languages, like CJK. Thanks Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Mon May 12 16:06:25 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 12 May 2014 18:06:25 +0200 Subject: Review request for 8034218: AIX: Provide a better fontconfig.properties file In-Reply-To: References: Message-ID: Hi Jonathan, thanks for submitting this patch. Overall it looks good, but I don't think we should reference the fonts under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties (at least not until IBM will not also contribute the corresponding fonts :) I would also find it helpful to keep a reworked version of the comment: 27 # Minimal version for AIX using the standard Latin Type1 Fonts from the 28 # package X11.fnt.iso_T1. These fonts are installed by default into 29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to "/usr/lib/X11/fonts/Type1" which mentions which AIX packages provide the other referenced font files. Thank you and best regards, Volker On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu wrote: > Hi awt-dev, > > Please review the fix for issue: > https://bugs.openjdk.java.net/browse/JDK-8034218 > > The changes are placed at > http://cr.openjdk.java.net/~luchsh/JDK-8034218/ > > This patch is trying to provide a better fonctconfig.properties file for AIX > platform, > which contains support for more languages, like CJK. > > > Thanks > Jonathan > > From anthony.petrov at oracle.com Mon May 12 16:16:38 2014 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 12 May 2014 20:16:38 +0400 Subject: Review request for 8034218: AIX: Provide a better fontconfig.properties file In-Reply-To: References: Message-ID: <5370F3E6.1060209@oracle.com> (adding in 2d-dev@ since fonts belong there) -- best regards, Anthony On 5/12/2014 8:06 PM, Volker Simonis wrote: > Hi Jonathan, > > thanks for submitting this patch. > > Overall it looks good, but I don't think we should reference the fonts > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties > (at least not until IBM will not also contribute the corresponding > fonts :) > > I would also find it helpful to keep a reworked version of the comment: > > 27 # Minimal version for AIX using the standard Latin Type1 Fonts from the > 28 # package X11.fnt.iso_T1. These fonts are installed by default into > 29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to > "/usr/lib/X11/fonts/Type1" > > which mentions which AIX packages provide the other referenced font files. > > Thank you and best regards, > Volker > > > > On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu wrote: >> Hi awt-dev, >> >> Please review the fix for issue: >> https://bugs.openjdk.java.net/browse/JDK-8034218 >> >> The changes are placed at >> http://cr.openjdk.java.net/~luchsh/JDK-8034218/ >> >> This patch is trying to provide a better fonctconfig.properties file for AIX >> platform, >> which contains support for more languages, like CJK. >> >> >> Thanks >> Jonathan >> >> From philip.race at oracle.com Mon May 12 16:42:15 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 12 May 2014 09:42:15 -0700 Subject: Review request for 8034218: AIX: Provide a better fontconfig.properties file In-Reply-To: References: Message-ID: <5370F9E7.8050109@oracle.com> All, If you want to continue this discussion i should be restarted on 2d-dev and awt-dev removed. AWT has nothing to do with the fonts .. I've fixed the bug sub-cat. -phil. On 05/12/2014 09:06 AM, Volker Simonis wrote: > Hi Jonathan, > > thanks for submitting this patch. > > Overall it looks good, but I don't think we should reference the fonts > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties > (at least not until IBM will not also contribute the corresponding > fonts :) > > I would also find it helpful to keep a reworked version of the comment: > > 27 # Minimal version for AIX using the standard Latin Type1 Fonts from the > 28 # package X11.fnt.iso_T1. These fonts are installed by default into > 29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to > "/usr/lib/X11/fonts/Type1" > > which mentions which AIX packages provide the other referenced font files. > > Thank you and best regards, > Volker > > > > On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu wrote: >> Hi awt-dev, >> >> Please review the fix for issue: >> https://bugs.openjdk.java.net/browse/JDK-8034218 >> >> The changes are placed at >> http://cr.openjdk.java.net/~luchsh/JDK-8034218/ >> >> This patch is trying to provide a better fonctconfig.properties file for AIX >> platform, >> which contains support for more languages, like CJK. >> >> >> Thanks >> Jonathan >> >> From philip.race at oracle.com Mon May 12 16:47:27 2014 From: philip.race at oracle.com (Phil Race) Date: Mon, 12 May 2014 09:47:27 -0700 Subject: [OpenJDK 2D-Dev] Review request for 8034218: AIX: Provide a better fontconfig.properties file In-Reply-To: <5370F9E7.8050109@oracle.com> References: <5370F9E7.8050109@oracle.com> Message-ID: <5370FB1F.1070904@oracle.com> removed awt-dev ... > I don't think we should reference the fonts > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties Volker is correct on this point. Since OpenJDK can't ship those fonts we made sure they were never used in any openjdk fontconfig file. -phil. On 05/12/2014 09:42 AM, Phil Race wrote: > All, > > If you want to continue this discussion i should be restarted on 2d-dev > and awt-dev removed. AWT has nothing to do with the fonts .. > I've fixed the bug sub-cat. > > -phil. > > On 05/12/2014 09:06 AM, Volker Simonis wrote: >> Hi Jonathan, >> >> thanks for submitting this patch. >> >> Overall it looks good, but I don't think we should reference the fonts >> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties >> (at least not until IBM will not also contribute the corresponding >> fonts :) >> >> I would also find it helpful to keep a reworked version of the comment: >> >> 27 # Minimal version for AIX using the standard Latin Type1 Fonts >> from the >> 28 # package X11.fnt.iso_T1. These fonts are installed by default >> into >> 29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to >> "/usr/lib/X11/fonts/Type1" >> >> which mentions which AIX packages provide the other referenced font >> files. >> >> Thank you and best regards, >> Volker >> >> >> >> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu >> wrote: >>> Hi awt-dev, >>> >>> Please review the fix for issue: >>> https://bugs.openjdk.java.net/browse/JDK-8034218 >>> >>> The changes are placed at >>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/ >>> >>> This patch is trying to provide a better fonctconfig.properties file >>> for AIX >>> platform, >>> which contains support for more languages, like CJK. >>> >>> >>> Thanks >>> Jonathan >>> >>> > From luchsh at linux.vnet.ibm.com Tue May 13 02:06:15 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 13 May 2014 10:06:15 +0800 Subject: [OpenJDK 2D-Dev] Review request for 8034218: AIX: Provide a better fontconfig.properties file In-Reply-To: <5370FB1F.1070904@oracle.com> References: <5370F9E7.8050109@oracle.com> <5370FB1F.1070904@oracle.com> Message-ID: Hi Phil, Volker, Thanks for your comments, but I noticed that JRE_LIB_FONTS has been referred by the solaris fontconfig file, jdk/make/data/fontconfig/solaris.fontconfig.properties So I'm wondering if we can do this in the same way as Solaris platform. Thanks Jonathan On Tue, May 13, 2014 at 12:47 AM, Phil Race wrote: > removed awt-dev ... > > > > I don't think we should reference the fonts > > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties > > Volker is correct on this point. > > Since OpenJDK can't ship those fonts we made sure they were never used > in any openjdk fontconfig file. > > -phil. > > > > On 05/12/2014 09:42 AM, Phil Race wrote: > >> All, >> >> If you want to continue this discussion i should be restarted on 2d-dev >> and awt-dev removed. AWT has nothing to do with the fonts .. >> I've fixed the bug sub-cat. >> >> -phil. >> >> On 05/12/2014 09:06 AM, Volker Simonis wrote: >> >>> Hi Jonathan, >>> >>> thanks for submitting this patch. >>> >>> Overall it looks good, but I don't think we should reference the fonts >>> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties >>> (at least not until IBM will not also contribute the corresponding >>> fonts :) >>> >>> I would also find it helpful to keep a reworked version of the comment: >>> >>> 27 # Minimal version for AIX using the standard Latin Type1 Fonts >>> from the >>> 28 # package X11.fnt.iso_T1. These fonts are installed by default into >>> 29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to >>> "/usr/lib/X11/fonts/Type1" >>> >>> which mentions which AIX packages provide the other referenced font >>> files. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> >>> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu >>> wrote: >>> >>>> Hi awt-dev, >>>> >>>> Please review the fix for issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8034218 >>>> >>>> The changes are placed at >>>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/ >>>> >>>> This patch is trying to provide a better fonctconfig.properties file >>>> for AIX >>>> platform, >>>> which contains support for more languages, like CJK. >>>> >>>> >>>> Thanks >>>> Jonathan >>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Tue May 13 09:25:20 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 13 May 2014 11:25:20 +0200 Subject: [OpenJDK 2D-Dev] Review request for 8034218: AIX: Provide a better fontconfig.properties file In-Reply-To: References: <5370F9E7.8050109@oracle.com> <5370FB1F.1070904@oracle.com> Message-ID: Hi Jonathan, from all fontconfig files in make/data/fontconfig, solaris.fontconfig.properties is the only file which contains a single line referring to $JRE_LIB_FONTS. This is obviously a first-day bug which should be fixed. It simply makes no sense to define font files and default fonts with references to files which won't be in a JDK for sure. Again, if you could convince IBM to donate the corresponding fonts to the OpenJDK that would be great. Otherwise these entries should be dropped from the fontconfig files. Thank you and best regards, Volker On Tue, May 13, 2014 at 4:06 AM, Jonathan Lu wrote: > Hi Phil, Volker, > > Thanks for your comments, but I noticed that JRE_LIB_FONTS has been referred > by the solaris fontconfig file, > > jdk/make/data/fontconfig/solaris.fontconfig.properties > > So I'm wondering if we can do this in the same way as Solaris platform. > > > Thanks > Jonathan > > > > On Tue, May 13, 2014 at 12:47 AM, Phil Race wrote: >> >> removed awt-dev ... >> >> >> > I don't think we should reference the fonts >> > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties >> >> Volker is correct on this point. >> >> Since OpenJDK can't ship those fonts we made sure they were never used >> in any openjdk fontconfig file. >> >> -phil. >> >> >> >> On 05/12/2014 09:42 AM, Phil Race wrote: >>> >>> All, >>> >>> If you want to continue this discussion i should be restarted on 2d-dev >>> and awt-dev removed. AWT has nothing to do with the fonts .. >>> I've fixed the bug sub-cat. >>> >>> -phil. >>> >>> On 05/12/2014 09:06 AM, Volker Simonis wrote: >>>> >>>> Hi Jonathan, >>>> >>>> thanks for submitting this patch. >>>> >>>> Overall it looks good, but I don't think we should reference the fonts >>>> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties >>>> (at least not until IBM will not also contribute the corresponding >>>> fonts :) >>>> >>>> I would also find it helpful to keep a reworked version of the comment: >>>> >>>> 27 # Minimal version for AIX using the standard Latin Type1 Fonts >>>> from the >>>> 28 # package X11.fnt.iso_T1. These fonts are installed by default >>>> into >>>> 29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to >>>> "/usr/lib/X11/fonts/Type1" >>>> >>>> which mentions which AIX packages provide the other referenced font >>>> files. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> >>>> >>>> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu >>>> wrote: >>>>> >>>>> Hi awt-dev, >>>>> >>>>> Please review the fix for issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8034218 >>>>> >>>>> The changes are placed at >>>>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/ >>>>> >>>>> This patch is trying to provide a better fonctconfig.properties file >>>>> for AIX >>>>> platform, >>>>> which contains support for more languages, like CJK. >>>>> >>>>> >>>>> Thanks >>>>> Jonathan >>>>> >>>>> >>> >> > From monica.b at servergy.com Tue May 13 12:05:58 2014 From: monica.b at servergy.com (Monica Beckwith) Date: Tue, 13 May 2014 07:05:58 -0500 Subject: Fwd: RE: Fwd: Question wrt ppc.ad (for 64b PPC) In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC0EDD@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CEC0EDD@DEWDFEMB12A.global.corp.sap> Message-ID: <53720AA6.4030901@servergy.com> Thanks Goetz. As requested, I am forwarding to the alias so this gets documented. :) Regards, -Monica -------- Original Message -------- Subject: RE: Fwd: Question wrt ppc.ad (for 64b PPC) Date: Tue, 13 May 2014 07:34:50 +0000 From: Lindenmaier, Goetz To: Monica Beckwith , "Simonis, Volker" CC: Ruchika Hi Ruchika, these are values needed for the runtime functionality of the VM, so they are not found in an official ppc document. R16 points to a thread of class Thread from runtime/thread.hpp. R29 is the global TOC we use to compute the tocs for methods with few instructions. Loading a 64-bit address requires 5 instructions, so it's cheaper to have some address nearby in a register and compute the address by an offset to that. (toc: pointer to the constant section of a method) R30 is used for compressed oops. This is a feature only needed on 64-bit machines. If the Java heap is < 32GB, oop pointers are compressed to 32-bit by cOop = (oop -- heap_base) >> 3. heap_base is held in R30 (cOop: compressed oop) Best regards, Goetz. *Question:* While reading the ppc.ad file for ppc (./hotspot/src/cpu/ppc/vm/ppc.ad) I came across these lines wrt the register definitions (line 434 in file) /*R13*/ // system thread id <-- THis is as per "64-bit PowerPC ELF Application Binary Interface Supplement 1.7" so it is ok R14, R15, /*R16*/ // R16_thread <--- Where does this convention arise from ? Which document/supplement? R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, /*R29*/ // global TOC <--- Where does this convention arise from ? Which document/supplement? /*R30*/ // Narrow Oop Base<--- Where does this convention arise from ? Which document/supplement? Thank you Regards Ruchika -- Ruchika Kharwar Senior Validation Engineer Servergy, Inc. Mobile:(469) 919-5635 Fax:(972) 542-5633 Email:ruchika.k at servergy.com Website:Servergy.com Twitter:Twitter.com/Servergy Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research O Data Centers have become as vital to the functioning of society as power stations. -- The Economist O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruchika.k at servergy.com Tue May 13 14:37:06 2014 From: ruchika.k at servergy.com (Ruchika Kharwar) Date: Tue, 13 May 2014 09:37:06 -0500 Subject: : Re: Fwd: RE: Fwd: Question wrt ppc.ad (for 64b PPC) In-Reply-To: <53722D11.6000507@servergy.com> References: <53722D11.6000507@servergy.com> Message-ID: <53722E12.5010602@servergy.com> Goetz, Thank you for your response, really appreciate it. As you might have expected I have a followup question ;-) sorry and thank you in advance As per "64-bit PowerPC ELF Application Binary Interface Supplement 1.7" register r2 holds the "TOC base" so why not use r2 instead of using using another register r29. You say we don't need a coop on 32b machines because the oop pointer is <= 32 bits anyways since the memory span is 32GB, yes ? Now deviating some from the original question a little: Now for the 32b port of the code base referring to the e500 ABI doc, r2 holds the TOC and r13 the small data are and I need to use those 2 together instead of the r2 toc on the 64b. If that information is handy, do you know which files would need change in the openjdk ? Secondly, the 64 b 1.7 eabi has register r13 dedicated to the system thread id, there isn't one dedicated in the e500 abi doc, any recommendation on how that would need to get handled ? Thank you Regards, Ruchika On 5/13/2014 7:05 AM, Monica Beckwith wrote: > Thanks Goetz. As requested, I am forwarding to the alias so this gets > documented. :) > > Regards, > -Monica > > -------- Original Message -------- > Subject: RE: Fwd: Question wrt ppc.ad (for 64b PPC) > Date: Tue, 13 May 2014 07:34:50 +0000 > From: Lindenmaier, Goetz > To: Monica Beckwith , "Simonis, Volker" > > CC: Ruchika > > > > Hi Ruchika, > > these are values needed for the runtime functionality of the VM, so > they are not > > found in an official ppc document. > > R16 points to a thread of class Thread from runtime/thread.hpp. > > R29 is the global TOC we use to compute the tocs for methods with > > few instructions. Loading a 64-bit address requires 5 instructions, > > so it's cheaper to have some address nearby in a register and compute > > the address by an offset to that. > > (toc: pointer to the constant section of a method) > > R30 is used for compressed oops. This is a feature only needed on 64-bit > > machines. If the Java heap is < 32GB, oop pointers are compressed to > 32-bit > > by cOop = (oop -- heap_base) >> 3. heap_base is held in R30 (cOop: > compressed oop) > > Best regards, > > Goetz. > > *Question:* > > While reading the ppc.ad file for ppc > (./hotspot/src/cpu/ppc/vm/ppc.ad) I came across these lines > wrt the register definitions (line 434 in file) > /*R13*/ // system thread id <-- THis is as per > "64-bit PowerPC ELF Application Binary > Interface Supplement 1.7" so it is ok > R14, > R15, > /*R16*/ // R16_thread <--- Where does this convention > arise from ? Which document/supplement? > R17, > R18, > R19, > R20, > R21, > R22, > R23, > R24, > R25, > R26, > R27, > R28, > /*R29*/ // global TOC <--- Where does this convention > arise from ? Which document/supplement? > /*R30*/ // Narrow Oop Base<--- Where does this > convention arise from ? Which document/supplement? > > Thank you > Regards > Ruchika > > > -- > > Ruchika Kharwar > > Senior Validation Engineer > > Servergy, Inc. > > Mobile:(469) 919-5635 > > Fax:(972) 542-5633 > > Email:ruchika.k at servergy.com > > Website:Servergy.com > > Twitter:Twitter.com/Servergy > > > > Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! > > O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust > > O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research > > O Data Centers have become as vital to the functioning of society as power stations. -- The Economist > > O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research > > O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research > > > > CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. > > > -- Ruchika Kharwar Senior Validation Engineer Servergy, Inc. Mobile:(469) 919-5635 Fax:(972) 542-5633 Email:ruchika.k at servergy.com Website:Servergy.com Twitter:Twitter.com/Servergy Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research O Data Centers have become as vital to the functioning of society as power stations. -- The Economist O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. -- Ruchika Kharwar Senior Validation Engineer Servergy, Inc. Mobile:(469) 919-5635 Fax:(972) 542-5633 Email:ruchika.k at servergy.com Website:Servergy.com Twitter:Twitter.com/Servergy Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research O Data Centers have become as vital to the functioning of society as power stations. -- The Economist O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue May 13 16:39:53 2014 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 13 May 2014 16:39:53 +0000 Subject: Fwd: RE: Fwd: Question wrt ppc.ad (for 64b PPC) In-Reply-To: <53722E12.5010602@servergy.com> References: <53722D11.6000507@servergy.com> <53722E12.5010602@servergy.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CEC2BAB@DEWDFEMB12A.global.corp.sap> Hi Ruchika, > As per "64-bit PowerPC ELF Application Binary Interface Supplement 1.7" register r2 holds the "TOC base" so why not use r2 instead of using using another register r29. Because |r2 - r29| >> 2^32 is possible, and we introduced our toc in r29 to reach the constants with a small offset < 2^32. > You say we don't need a coop on 32b machines because the oop pointer is <= 32 bits anyways since the memory span is 32GB, yes ? Yes. > Now deviating some from the original question a little: > Now for the 32b port of the code base referring to the e500 ABI doc, r2 holds the TOC and r13 the small data area and I need to use those 2 together instead of the r2 toc on the 64b. If that information is handy, do you know which files would need change in the openjdk ? The file ppc.ad specifies the nodes of the low IR of the C2 compiler, as well as rules for register allocation, matching etc.. The compiled code will not read the abi content of the registers. r13 is just left alone, r2 is saved and used for allocation, so it basically does not matter what they contain. On 32-bit I would just load constants directly, as only two instructions are needed, so you don't need a toc there at all. But freeing r29 and r30 and using them for register allocation in the C2 compiler is one of the last things you should address because it's only an optimization. I can't enumber all files you need to edit, but a lot of code issued by the compiler is implemented in macroAssembler_ppc.*. The biggest effort will probably be to identify all loads of pointers and replace 64-bit loads with 32-bit loads there. > Secondly, the 64 b 1.7 eabi has register r13 dedicated to the system thread id, there isn't one dedicated in the e500 abi doc, any recommendation on how that would need to get handled ? I don't remember that we use the system thread, we just don't touch the register. How do you plan to do the port? Will you do the template interpreter right away? Or will you start with the cpp interpreter? I would first port a 'core' build that only contains one of interpreters without any compiler, because that will get you to a running VM much faster. There is a build target 'debugcore' in hotspot. The abi relevant stuff needed for the interpreter is specified in the frame_ppc.* files. Best regards, Goetz. Thank you Regards, Ruchika On 5/13/2014 7:05 AM, Monica Beckwith wrote: Thanks Goetz. As requested, I am forwarding to the alias so this gets documented. :) Regards, -Monica -------- Original Message -------- Subject: RE: Fwd: Question wrt ppc.ad (for 64b PPC) Date: Tue, 13 May 2014 07:34:50 +0000 From: Lindenmaier, Goetz To: Monica Beckwith , "Simonis, Volker" CC: Ruchika Hi Ruchika, these are values needed for the runtime functionality of the VM, so they are not found in an official ppc document. R16 points to a thread of class Thread from runtime/thread.hpp. R29 is the global TOC we use to compute the tocs for methods with few instructions. Loading a 64-bit address requires 5 instructions, so it's cheaper to have some address nearby in a register and compute the address by an offset to that. (toc: pointer to the constant section of a method) R30 is used for compressed oops. This is a feature only needed on 64-bit machines. If the Java heap is < 32GB, oop pointers are compressed to 32-bit by cOop = (oop - heap_base) >> 3. heap_base is held in R30 (cOop: compressed oop) Best regards, Goetz. Question: While reading the ppc.ad file for ppc (./hotspot/src/cpu/ppc/vm/ppc.ad) I came across these lines wrt the register definitions (line 434 in file) /*R13*/ // system thread id <-- THis is as per "64-bit PowerPC ELF Application Binary Interface Supplement 1.7" so it is ok R14, R15, /*R16*/ // R16_thread <--- Where does this convention arise from ? Which document/supplement? R17, R18, R19, R20, R21, R22, R23, R24, R25, R26, R27, R28, /*R29*/ // global TOC <--- Where does this convention arise from ? Which document/supplement? /*R30*/ // Narrow Oop Base<--- Where does this convention arise from ? Which document/supplement? Thank you Regards Ruchika -- Ruchika Kharwar Senior Validation Engineer Servergy, Inc. Mobile:(469) 919-5635 Fax:(972) 542-5633 Email:ruchika.k at servergy.com Website:Servergy.com Twitter:Twitter.com/Servergy Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research O Data Centers have become as vital to the functioning of society as power stations. -- The Economist O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research CONFIDENTIALITY NOTICE: Copyright (c) 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. -- Ruchika Kharwar Senior Validation Engineer Servergy, Inc. Mobile:(469) 919-5635 Fax:(972) 542-5633 Email:ruchika.k at servergy.com Website:Servergy.com Twitter:Twitter.com/Servergy Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research O Data Centers have become as vital to the functioning of society as power stations. -- The Economist O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research CONFIDENTIALITY NOTICE: Copyright (c) 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. -- Ruchika Kharwar Senior Validation Engineer Servergy, Inc. Mobile:(469) 919-5635 Fax:(972) 542-5633 Email:ruchika.k at servergy.com Website:Servergy.com Twitter:Twitter.com/Servergy Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research O Data Centers have become as vital to the functioning of society as power stations. -- The Economist O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research CONFIDENTIALITY NOTICE: Copyright (c) 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruchika.k at servergy.com Thu May 15 15:24:38 2014 From: ruchika.k at servergy.com (Ruchika Kharwar) Date: Thu, 15 May 2014 10:24:38 -0500 Subject: Fwd: RE: Fwd: Question wrt ppc.ad (for 64b PPC) In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CEC2BAB@DEWDFEMB12A.global.corp.sap> References: <53722D11.6000507@servergy.com> <53722E12.5010602@servergy.com> <4295855A5C1DE049A61835A1887419CC2CEC2BAB@DEWDFEMB12A.global.corp.sap> Message-ID: <5374DC36.6070605@servergy.com> Goetz, Thank you so much for your reply: On 5/13/2014 11:39 AM, Lindenmaier, Goetz wrote: > > Hi Ruchika, > > > As per "64-bit PowerPC ELF Application Binary Interface Supplement > 1.7" register r2 holds the "TOC base" so why not use r2 instead of > using using another register r29. > Because |r2 -- r29| >> 2^32 is possible, and we introduced our toc in > r29 to reach the constants with a small offset < 2^32. > > > You say we don't need a coop on 32b machines because the oop pointer is <= 32 bits anyways since the > memory span is 32GB, yes ? > Yes. > > > Now deviating some from the original question a little: > > Now for the 32b port of the code base referring to the e500 ABI doc, > r2 holds the TOC and r13 the small data area and I need to use those 2 > together instead of the r2 toc on the 64b. If that information is > handy, do you know which files would need change in the openjdk ? > > The file ppc.ad specifies the nodes of the low IR of the C2 compiler, > as well as rules for register allocation, matching etc.. The compiled > code will not read the abi content of the registers. r13 is just left > alone, r2 is saved and used for allocation, so it basically does not > matter what they contain. On 32-bit I would just load constants > directly, as only two instructions are needed, so you don't need a toc > there at all. But freeing r29 and r30 and using them for register > allocation in the C2 compiler is one of the last things you should > address because it's only an optimization. > [RK] Thank you , this is very helpful. I may need to understand more but thanks for the pointer. > > I can't enumber all files you need to edit, but a lot of code issued > by the compiler is implemented in macroAssembler_ppc.*. The biggest > effort will probably be to identify all loads of pointers and replace > 64-bit loads with 32-bit loads there. > [RK] Thank you , I ported over the macroAssembler_ppc.* file (not tested yet in any way) > > > Secondly, the 64 b 1.7 eabi has register r13 dedicated to the system thread id, there isn't one dedicated in > the e500 abi doc, any recommendation on how that would need to get > handled ? > > I don't remember that we use the system thread, we just don't touch > the register. > > How do you plan to do the port? Will you do the template interpreter > right away? Or will you start with the cpp interpreter? I would first > port a 'core' build that only contains one of interpreters without any > compiler, because that will get you to a running VM much faster. > There is a build target 'debugcore' in hotspot. The abi relevant > stuff needed for the interpreter is specified in the frame_ppc.* files. > [RK] I am working with the Cpp interpreter for now. Thanks again for the input.. > > Best regards, Goetz. > > > > Thank you > Regards, > Ruchika > > On 5/13/2014 7:05 AM, Monica Beckwith wrote: > > Thanks Goetz. As requested, I am forwarding to the alias so this > gets documented. :) > > > Regards, > -Monica > > -------- Original Message -------- > > *Subject: * > > > > RE: Fwd: Question wrt ppc.ad (for 64b PPC) > > *Date: * > > > > Tue, 13 May 2014 07:34:50 +0000 > > *From: * > > > > Lindenmaier, Goetz > > > *To: * > > > > Monica Beckwith > , "Simonis, Volker" > > > *CC: * > > > > Ruchika > > > > > Hi Ruchika, > > these are values needed for the runtime functionality of the VM, > so they are not > > found in an official ppc document. > > R16 points to a thread of class Thread from runtime/thread.hpp. > > R29 is the global TOC we use to compute the tocs for methods with > > few instructions. Loading a 64-bit address requires 5 instructions, > > so it's cheaper to have some address nearby in a register and compute > > the address by an offset to that. > > (toc: pointer to the constant section of a method) > > R30 is used for compressed oops. This is a feature only needed on > 64-bit > > machines. If the Java heap is < 32GB, oop pointers are compressed > to 32-bit > > by cOop = (oop -- heap_base) >> 3. heap_base is held in R30 > (cOop: compressed oop) > > Best regards, > > Goetz. > > *Question:* > > While reading the ppc.ad file for ppc > (./hotspot/src/cpu/ppc/vm/ppc.ad) I came across these lines > wrt the register definitions (line 434 in file) > /*R13*/ // system thread id <-- THis is as per > "64-bit PowerPC ELF Application Binary > Interface Supplement 1.7" so it is ok > R14, > R15, > /*R16*/ // R16_thread <--- Where does this > convention arise from ? Which document/supplement? > R17, > R18, > R19, > R20, > R21, > R22, > R23, > R24, > R25, > R26, > R27, > R28, > /*R29*/ // global TOC <--- Where does this > convention arise from ? Which document/supplement? > /*R30*/ // Narrow Oop Base<--- Where does this > convention arise from ? Which document/supplement? > > Thank you > Regards > Ruchika > > > > -- > > Ruchika Kharwar > > Senior Validation Engineer > > Servergy, Inc. > > Mobile:(469) 919-5635 > > Fax:(972) 542-5633 > > Email:ruchika.k at servergy.com > > Website:Servergy.com > > Twitter:Twitter.com/Servergy > > > > Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! > > O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust > > O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research > > O Data Centers have become as vital to the functioning of society as power stations. -- The Economist > > O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research > > O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research > > > > CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. > > > > -- > Ruchika Kharwar > Senior Validation Engineer > Servergy, Inc. > Mobile:(469) 919-5635 > Fax:(972) 542-5633 > Email:ruchika.k at servergy.com > Website:Servergy.com > Twitter:Twitter.com/Servergy > > Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! > O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust > O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research > O Data Centers have become as vital to the functioning of society as power stations. -- The Economist > O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research > O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research > > CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. > > > > -- > Ruchika Kharwar > Senior Validation Engineer > Servergy, Inc. > Mobile:(469) 919-5635 > Fax:(972) 542-5633 > Email:ruchika.k at servergy.com > Website:Servergy.com > Twitter:Twitter.com/Servergy > > Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! > O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust > O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research > O Data Centers have become as vital to the functioning of society as power stations. -- The Economist > O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research > O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research > > CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. > -- Ruchika Kharwar Senior Validation Engineer Servergy, Inc. Mobile:(469) 919-5635 Fax:(972) 542-5633 Email:ruchika.k at servergy.com Website:Servergy.com Twitter:Twitter.com/Servergy Servergy Makes # 4 on the EE Times 2013 Global Top 10 List of Most Disruptive Tech Start-up Plays! O Energy-efficiency is #1 reason data centers look to expand. -- Digital Realty Trust O Green Data Centers spending to increase 300% worldwide by 2016. -- Pike Research O Data Centers have become as vital to the functioning of society as power stations. -- The Economist O By 2015, 30% of investments in $150B+ data center market will be in energy-efficiency plays [like Servergy]. -- Pike Research O By 2015 there will be 2B+ more people online and 10X more servers in the world. -- IDC Research CONFIDENTIALITY NOTICE: Copyright ? 2014 by Servergy, Inc. All Rights Reserved. This communication contains privileged and/or confidential information to be maintained with the strictest confidence. It is intended solely for the use of the person or entity in which it is addressed. If you are not the intended recipient, you are STRICTLY PROHIBITED from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luchsh at linux.vnet.ibm.com Tue May 20 06:17:42 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 20 May 2014 14:17:42 +0800 Subject: [OpenJDK 2D-Dev] Review request for 8034218: AIX: Provide a better fontconfig.properties file In-Reply-To: References: <5370F9E7.8050109@oracle.com> <5370FB1F.1070904@oracle.com> Message-ID: Hi Volker, I've updated the patch by dropping the those fonts configurations from $JRE_LIB_FONTS directory. The change is based on the SAP version, current change is primarily adding support for CJK fonts, pls review. http://cr.openjdk.java.net/~luchsh/JDK-8034218.v2/ Thanks Jonathan On Tue, May 13, 2014 at 5:25 PM, Volker Simonis wrote: > Hi Jonathan, > > from all fontconfig files in make/data/fontconfig, > solaris.fontconfig.properties is the only file which contains a single > line referring to $JRE_LIB_FONTS. This is obviously a first-day bug > which should be fixed. > > It simply makes no sense to define font files and default fonts with > references to files which won't be in a JDK for sure. Again, if you > could convince IBM to donate the corresponding fonts to the OpenJDK > that would be great. Otherwise these entries should be dropped from > the fontconfig files. > > Thank you and best regards, > Volker > > > On Tue, May 13, 2014 at 4:06 AM, Jonathan Lu > wrote: > > Hi Phil, Volker, > > > > Thanks for your comments, but I noticed that JRE_LIB_FONTS has been > referred > > by the solaris fontconfig file, > > > > jdk/make/data/fontconfig/solaris.fontconfig.properties > > > > So I'm wondering if we can do this in the same way as Solaris platform. > > > > > > Thanks > > Jonathan > > > > > > > > On Tue, May 13, 2014 at 12:47 AM, Phil Race > wrote: > >> > >> removed awt-dev ... > >> > >> > >> > I don't think we should reference the fonts > >> > under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties > >> > >> Volker is correct on this point. > >> > >> Since OpenJDK can't ship those fonts we made sure they were never used > >> in any openjdk fontconfig file. > >> > >> -phil. > >> > >> > >> > >> On 05/12/2014 09:42 AM, Phil Race wrote: > >>> > >>> All, > >>> > >>> If you want to continue this discussion i should be restarted on 2d-dev > >>> and awt-dev removed. AWT has nothing to do with the fonts .. > >>> I've fixed the bug sub-cat. > >>> > >>> -phil. > >>> > >>> On 05/12/2014 09:06 AM, Volker Simonis wrote: > >>>> > >>>> Hi Jonathan, > >>>> > >>>> thanks for submitting this patch. > >>>> > >>>> Overall it looks good, but I don't think we should reference the fonts > >>>> under $JRE_LIB_FONTS/ in the OpenJDK version of fontconfig.properties > >>>> (at least not until IBM will not also contribute the corresponding > >>>> fonts :) > >>>> > >>>> I would also find it helpful to keep a reworked version of the > comment: > >>>> > >>>> 27 # Minimal version for AIX using the standard Latin Type1 Fonts > >>>> from the > >>>> 28 # package X11.fnt.iso_T1. These fonts are installed by default > >>>> into > >>>> 29 # "/usr/lpp/X11/lib/X11/fonts/Type1" and sym-linked to > >>>> "/usr/lib/X11/fonts/Type1" > >>>> > >>>> which mentions which AIX packages provide the other referenced font > >>>> files. > >>>> > >>>> Thank you and best regards, > >>>> Volker > >>>> > >>>> > >>>> > >>>> On Mon, May 12, 2014 at 12:37 PM, Jonathan Lu > >>>> wrote: > >>>>> > >>>>> Hi awt-dev, > >>>>> > >>>>> Please review the fix for issue: > >>>>> https://bugs.openjdk.java.net/browse/JDK-8034218 > >>>>> > >>>>> The changes are placed at > >>>>> http://cr.openjdk.java.net/~luchsh/JDK-8034218/ > >>>>> > >>>>> This patch is trying to provide a better fonctconfig.properties file > >>>>> for AIX > >>>>> platform, > >>>>> which contains support for more languages, like CJK. > >>>>> > >>>>> > >>>>> Thanks > >>>>> Jonathan > >>>>> > >>>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed May 21 17:47:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 May 2014 10:47:18 -0700 Subject: RFR (S) JDK-8043301: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp versus math.h in VS2013 In-Reply-To: <537CE0D2.3030706@oracle.com> References: <537CBB0F.5010706@oracle.com> <537CD907.1030303@oracle.com> <537CE0D2.3030706@oracle.com> Message-ID: <537CE6A6.6080602@oracle.com> These methods are there to get the same results on all platforms. I don't like adding 'A'. Can we use __scalbn names? Also we need to ask SAP if they have conflict with new names before removing #if. Thanks, Vladimir On 5/21/14 10:22 AM, Lois Foltan wrote: > > On 5/21/2014 12:49 PM, Tim Bell wrote: >> Lois: >> >>> Please review the following fix: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301/ >>> >>> Bug: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp >>> versus math.h in VS2013 >>> https://bugs.openjdk.java.net/browse/JDK-8043301 >>> >>> Summary of fix: >>> VS2013's include/math.h now contains definitions for both copysign() >>> and scalbn(). This yielded compilation conflicts with the JVM's >>> definition of these functions within runtime/sharedRuntimeTrans.cpp. >>> I changed copysign and scalbn definitions to be consistent with how >>> they are defined within sharedRuntimeTrig.cpp. They are now defined >>> as copysignA and scalbnA static functions. I also removed the >>> !defined(AIX) conditionalization around these defintions since no >>> conflict should now exist with AIX's math.h. >>> >>> Tests: >>> JPRT build & test, Hotspot jtreg, JDK lang & util, >>> vm.quick.testlist (in progress) >> >> Thank you for the fix. Looks good to me, although I am not a hotspot >> reviewer or committer. I have very low confidence that their >> implementations of 'copysign' and 'scalbn' would exactly match what we >> use on all other platforms, especially since we can't inspect their code. > > Thanks Tim for the review. I think due to performance reasons > sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have their own > definitions. These are the only two files in the JVM that use copysign > and scalbn. > >> >> I have the sharedRuntimeTrans.cpp patch in my compiler upgrade source >> tree... testing now. > > Great, thanks again! > Lois > >> >> Tim >> > From lois.foltan at oracle.com Wed May 21 18:03:39 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 21 May 2014 14:03:39 -0400 Subject: RFR (S) JDK-8043301: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp versus math.h in VS2013 In-Reply-To: <537CE6A6.6080602@oracle.com> References: <537CBB0F.5010706@oracle.com> <537CD907.1030303@oracle.com> <537CE0D2.3030706@oracle.com> <537CE6A6.6080602@oracle.com> Message-ID: <537CEA7B.8050105@oracle.com> On 5/21/2014 1:47 PM, Vladimir Kozlov wrote: > These methods are there to get the same results on all platforms. > > I don't like adding 'A'. Can we use __scalbn names? > > Also we need to ask SAP if they have conflict with new names before > removing #if. Thanks Vladimir for the review. I hesitate to go to the use of double underscores since I thought this was reserved for a C/C++ compiler's internal use. Also one underscore is how copysign is defined within VS2010's math.h so that is not a viable option either. Again, there was precedent within sharedRuntimeTrig.cpp for the 'A', so I chose to follow suit. I would be happy to follow up with SAP, do you have a specific contact, or by cc'ing the ppc-aix-port-dev alias that should be sufficient? Lois > Thanks, > Vladimir > > On 5/21/14 10:22 AM, Lois Foltan wrote: >> >> On 5/21/2014 12:49 PM, Tim Bell wrote: >>> Lois: >>> >>>> Please review the following fix: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301/ >>>> >>>> Bug: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp >>>> versus math.h in VS2013 >>>> https://bugs.openjdk.java.net/browse/JDK-8043301 >>>> >>>> Summary of fix: >>>> VS2013's include/math.h now contains definitions for both copysign() >>>> and scalbn(). This yielded compilation conflicts with the JVM's >>>> definition of these functions within runtime/sharedRuntimeTrans.cpp. >>>> I changed copysign and scalbn definitions to be consistent with how >>>> they are defined within sharedRuntimeTrig.cpp. They are now defined >>>> as copysignA and scalbnA static functions. I also removed the >>>> !defined(AIX) conditionalization around these defintions since no >>>> conflict should now exist with AIX's math.h. >>>> >>>> Tests: >>>> JPRT build & test, Hotspot jtreg, JDK lang & util, >>>> vm.quick.testlist (in progress) >>> >>> Thank you for the fix. Looks good to me, although I am not a hotspot >>> reviewer or committer. I have very low confidence that their >>> implementations of 'copysign' and 'scalbn' would exactly match what we >>> use on all other platforms, especially since we can't inspect their >>> code. >> >> Thanks Tim for the review. I think due to performance reasons >> sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have their own >> definitions. These are the only two files in the JVM that use copysign >> and scalbn. >> >>> >>> I have the sharedRuntimeTrans.cpp patch in my compiler upgrade source >>> tree... testing now. >> >> Great, thanks again! >> Lois >> >>> >>> Tim >>> >> From vladimir.kozlov at oracle.com Wed May 21 18:32:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 May 2014 11:32:02 -0700 Subject: RFR (S) JDK-8043301: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp versus math.h in VS2013 In-Reply-To: <537CEA7B.8050105@oracle.com> References: <537CBB0F.5010706@oracle.com> <537CD907.1030303@oracle.com> <537CE0D2.3030706@oracle.com> <537CE6A6.6080602@oracle.com> <537CEA7B.8050105@oracle.com> Message-ID: <537CF122.9020509@oracle.com> On 5/21/14 11:03 AM, Lois Foltan wrote: > > On 5/21/2014 1:47 PM, Vladimir Kozlov wrote: >> These methods are there to get the same results on all platforms. >> >> I don't like adding 'A'. Can we use __scalbn names? >> >> Also we need to ask SAP if they have conflict with new names before >> removing #if. > > Thanks Vladimir for the review. I hesitate to go to the use of double > underscores since I thought this was reserved for a C/C++ compiler's > internal use. Also one underscore is how copysign is defined within > VS2010's math.h so that is not a viable option either. Again, there was > precedent within sharedRuntimeTrig.cpp for the 'A', so I chose to follow > suit. Yes, it is a pain to find unique name. Using namespace could solve this too but we are not using it in VM :( So we have duplicated code in these files. In this case can you move copysignA, scalbnA and other common definitions into .hpp file? > > I would be happy to follow up with SAP, do you have a specific contact, > or by cc'ing the ppc-aix-port-dev alias that should be sufficient? CC to ppc-aix-port-dev should get their attention. If they will not comment, we will assume it is okay to change. Thanks, Vladimir > > Lois > >> Thanks, >> Vladimir >> >> On 5/21/14 10:22 AM, Lois Foltan wrote: >>> >>> On 5/21/2014 12:49 PM, Tim Bell wrote: >>>> Lois: >>>> >>>>> Please review the following fix: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301/ >>>>> >>>>> Bug: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp >>>>> versus math.h in VS2013 >>>>> https://bugs.openjdk.java.net/browse/JDK-8043301 >>>>> >>>>> Summary of fix: >>>>> VS2013's include/math.h now contains definitions for both copysign() >>>>> and scalbn(). This yielded compilation conflicts with the JVM's >>>>> definition of these functions within runtime/sharedRuntimeTrans.cpp. >>>>> I changed copysign and scalbn definitions to be consistent with how >>>>> they are defined within sharedRuntimeTrig.cpp. They are now defined >>>>> as copysignA and scalbnA static functions. I also removed the >>>>> !defined(AIX) conditionalization around these defintions since no >>>>> conflict should now exist with AIX's math.h. >>>>> >>>>> Tests: >>>>> JPRT build & test, Hotspot jtreg, JDK lang & util, >>>>> vm.quick.testlist (in progress) >>>> >>>> Thank you for the fix. Looks good to me, although I am not a hotspot >>>> reviewer or committer. I have very low confidence that their >>>> implementations of 'copysign' and 'scalbn' would exactly match what we >>>> use on all other platforms, especially since we can't inspect their >>>> code. >>> >>> Thanks Tim for the review. I think due to performance reasons >>> sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have their own >>> definitions. These are the only two files in the JVM that use copysign >>> and scalbn. >>> >>>> >>>> I have the sharedRuntimeTrans.cpp patch in my compiler upgrade source >>>> tree... testing now. >>> >>> Great, thanks again! >>> Lois >>> >>>> >>>> Tim >>>> >>> > From lois.foltan at oracle.com Wed May 21 20:12:06 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 21 May 2014 16:12:06 -0400 Subject: RFR (S) JDK-8043301: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp versus math.h in VS2013 In-Reply-To: <537CF122.9020509@oracle.com> References: <537CBB0F.5010706@oracle.com> <537CD907.1030303@oracle.com> <537CE0D2.3030706@oracle.com> <537CE6A6.6080602@oracle.com> <537CEA7B.8050105@oracle.com> <537CF122.9020509@oracle.com> Message-ID: <537D0896.2080006@oracle.com> On 5/21/2014 2:32 PM, Vladimir Kozlov wrote: > On 5/21/14 11:03 AM, Lois Foltan wrote: >> >> On 5/21/2014 1:47 PM, Vladimir Kozlov wrote: >>> These methods are there to get the same results on all platforms. >>> >>> I don't like adding 'A'. Can we use __scalbn names? >>> >>> Also we need to ask SAP if they have conflict with new names before >>> removing #if. >> >> Thanks Vladimir for the review. I hesitate to go to the use of double >> underscores since I thought this was reserved for a C/C++ compiler's >> internal use. Also one underscore is how copysign is defined within >> VS2010's math.h so that is not a viable option either. Again, there was >> precedent within sharedRuntimeTrig.cpp for the 'A', so I chose to follow >> suit. > > Yes, it is a pain to find unique name. Using namespace could solve > this too but we are not using it in VM :( > > So we have duplicated code in these files. In this case can you move > copysignA, scalbnA and other common definitions into .hpp file? Hi Vladimir, Good idea, please review updated webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301_2/. I have verified that this builds with VS2010 and VS2013. Retesting is in progress. Thanks, Lois > >> >> I would be happy to follow up with SAP, do you have a specific contact, >> or by cc'ing the ppc-aix-port-dev alias that should be sufficient? > > CC to ppc-aix-port-dev should get their attention. If they will not > comment, we will assume it is okay to change. > > Thanks, > Vladimir > >> >> Lois >> >>> Thanks, >>> Vladimir >>> >>> On 5/21/14 10:22 AM, Lois Foltan wrote: >>>> >>>> On 5/21/2014 12:49 PM, Tim Bell wrote: >>>>> Lois: >>>>> >>>>>> Please review the following fix: >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301/ >>>>>> >>>>>> Bug: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp >>>>>> versus math.h in VS2013 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8043301 >>>>>> >>>>>> Summary of fix: >>>>>> VS2013's include/math.h now contains definitions for both copysign() >>>>>> and scalbn(). This yielded compilation conflicts with the JVM's >>>>>> definition of these functions within runtime/sharedRuntimeTrans.cpp. >>>>>> I changed copysign and scalbn definitions to be consistent with how >>>>>> they are defined within sharedRuntimeTrig.cpp. They are now defined >>>>>> as copysignA and scalbnA static functions. I also removed the >>>>>> !defined(AIX) conditionalization around these defintions since no >>>>>> conflict should now exist with AIX's math.h. >>>>>> >>>>>> Tests: >>>>>> JPRT build & test, Hotspot jtreg, JDK lang & util, >>>>>> vm.quick.testlist (in progress) >>>>> >>>>> Thank you for the fix. Looks good to me, although I am not a hotspot >>>>> reviewer or committer. I have very low confidence that their >>>>> implementations of 'copysign' and 'scalbn' would exactly match >>>>> what we >>>>> use on all other platforms, especially since we can't inspect their >>>>> code. >>>> >>>> Thanks Tim for the review. I think due to performance reasons >>>> sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have their own >>>> definitions. These are the only two files in the JVM that use >>>> copysign >>>> and scalbn. >>>> >>>>> >>>>> I have the sharedRuntimeTrans.cpp patch in my compiler upgrade source >>>>> tree... testing now. >>>> >>>> Great, thanks again! >>>> Lois >>>> >>>>> >>>>> Tim >>>>> >>>> >> From vladimir.kozlov at oracle.com Wed May 21 20:54:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 May 2014 13:54:01 -0700 Subject: RFR (S) JDK-8043301: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp versus math.h in VS2013 In-Reply-To: <537D0896.2080006@oracle.com> References: <537CBB0F.5010706@oracle.com> <537CD907.1030303@oracle.com> <537CE0D2.3030706@oracle.com> <537CE6A6.6080602@oracle.com> <537CEA7B.8050105@oracle.com> <537CF122.9020509@oracle.com> <537D0896.2080006@oracle.com> Message-ID: <537D1269.60906@oracle.com> Yes, this looks good. Thanks, Vladimir On 5/21/14 1:12 PM, Lois Foltan wrote: > > On 5/21/2014 2:32 PM, Vladimir Kozlov wrote: >> On 5/21/14 11:03 AM, Lois Foltan wrote: >>> >>> On 5/21/2014 1:47 PM, Vladimir Kozlov wrote: >>>> These methods are there to get the same results on all platforms. >>>> >>>> I don't like adding 'A'. Can we use __scalbn names? >>>> >>>> Also we need to ask SAP if they have conflict with new names before >>>> removing #if. >>> >>> Thanks Vladimir for the review. I hesitate to go to the use of double >>> underscores since I thought this was reserved for a C/C++ compiler's >>> internal use. Also one underscore is how copysign is defined within >>> VS2010's math.h so that is not a viable option either. Again, there was >>> precedent within sharedRuntimeTrig.cpp for the 'A', so I chose to follow >>> suit. >> >> Yes, it is a pain to find unique name. Using namespace could solve >> this too but we are not using it in VM :( >> >> So we have duplicated code in these files. In this case can you move >> copysignA, scalbnA and other common definitions into .hpp file? > > Hi Vladimir, > > Good idea, please review updated webrev at > http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301_2/. I have verified > that this builds with VS2010 and VS2013. Retesting is in progress. > > Thanks, > Lois > >> >>> >>> I would be happy to follow up with SAP, do you have a specific contact, >>> or by cc'ing the ppc-aix-port-dev alias that should be sufficient? >> >> CC to ppc-aix-port-dev should get their attention. If they will not >> comment, we will assume it is okay to change. >> >> Thanks, >> Vladimir >> >>> >>> Lois >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 5/21/14 10:22 AM, Lois Foltan wrote: >>>>> >>>>> On 5/21/2014 12:49 PM, Tim Bell wrote: >>>>>> Lois: >>>>>> >>>>>>> Please review the following fix: >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301/ >>>>>>> >>>>>>> Bug: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp >>>>>>> versus math.h in VS2013 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043301 >>>>>>> >>>>>>> Summary of fix: >>>>>>> VS2013's include/math.h now contains definitions for both copysign() >>>>>>> and scalbn(). This yielded compilation conflicts with the JVM's >>>>>>> definition of these functions within runtime/sharedRuntimeTrans.cpp. >>>>>>> I changed copysign and scalbn definitions to be consistent with how >>>>>>> they are defined within sharedRuntimeTrig.cpp. They are now defined >>>>>>> as copysignA and scalbnA static functions. I also removed the >>>>>>> !defined(AIX) conditionalization around these defintions since no >>>>>>> conflict should now exist with AIX's math.h. >>>>>>> >>>>>>> Tests: >>>>>>> JPRT build & test, Hotspot jtreg, JDK lang & util, >>>>>>> vm.quick.testlist (in progress) >>>>>> >>>>>> Thank you for the fix. Looks good to me, although I am not a hotspot >>>>>> reviewer or committer. I have very low confidence that their >>>>>> implementations of 'copysign' and 'scalbn' would exactly match >>>>>> what we >>>>>> use on all other platforms, especially since we can't inspect their >>>>>> code. >>>>> >>>>> Thanks Tim for the review. I think due to performance reasons >>>>> sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have their own >>>>> definitions. These are the only two files in the JVM that use >>>>> copysign >>>>> and scalbn. >>>>> >>>>>> >>>>>> I have the sharedRuntimeTrans.cpp patch in my compiler upgrade source >>>>>> tree... testing now. >>>>> >>>>> Great, thanks again! >>>>> Lois >>>>> >>>>>> >>>>>> Tim >>>>>> >>>>> >>> > From lois.foltan at oracle.com Wed May 21 21:20:58 2014 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 21 May 2014 17:20:58 -0400 Subject: RFR (S) JDK-8043301: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp versus math.h in VS2013 In-Reply-To: <537D1269.60906@oracle.com> References: <537CBB0F.5010706@oracle.com> <537CD907.1030303@oracle.com> <537CE0D2.3030706@oracle.com> <537CE6A6.6080602@oracle.com> <537CEA7B.8050105@oracle.com> <537CF122.9020509@oracle.com> <537D0896.2080006@oracle.com> <537D1269.60906@oracle.com> Message-ID: <537D18BA.4080209@oracle.com> On 5/21/2014 4:54 PM, Vladimir Kozlov wrote: > Yes, this looks good. Great, thanks! Lois > > Thanks, > Vladimir > > On 5/21/14 1:12 PM, Lois Foltan wrote: >> >> On 5/21/2014 2:32 PM, Vladimir Kozlov wrote: >>> On 5/21/14 11:03 AM, Lois Foltan wrote: >>>> >>>> On 5/21/2014 1:47 PM, Vladimir Kozlov wrote: >>>>> These methods are there to get the same results on all platforms. >>>>> >>>>> I don't like adding 'A'. Can we use __scalbn names? >>>>> >>>>> Also we need to ask SAP if they have conflict with new names before >>>>> removing #if. >>>> >>>> Thanks Vladimir for the review. I hesitate to go to the use of double >>>> underscores since I thought this was reserved for a C/C++ compiler's >>>> internal use. Also one underscore is how copysign is defined within >>>> VS2010's math.h so that is not a viable option either. Again, there >>>> was >>>> precedent within sharedRuntimeTrig.cpp for the 'A', so I chose to >>>> follow >>>> suit. >>> >>> Yes, it is a pain to find unique name. Using namespace could solve >>> this too but we are not using it in VM :( >>> >>> So we have duplicated code in these files. In this case can you move >>> copysignA, scalbnA and other common definitions into .hpp file? >> >> Hi Vladimir, >> >> Good idea, please review updated webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301_2/. I have verified >> that this builds with VS2010 and VS2013. Retesting is in progress. >> >> Thanks, >> Lois >> >>> >>>> >>>> I would be happy to follow up with SAP, do you have a specific >>>> contact, >>>> or by cc'ing the ppc-aix-port-dev alias that should be sufficient? >>> >>> CC to ppc-aix-port-dev should get their attention. If they will not >>> comment, we will assume it is okay to change. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Lois >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 5/21/14 10:22 AM, Lois Foltan wrote: >>>>>> >>>>>> On 5/21/2014 12:49 PM, Tim Bell wrote: >>>>>>> Lois: >>>>>>> >>>>>>>> Please review the following fix: >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8043301/ >>>>>>>> >>>>>>>> Bug: Duplicate definitions in vm/runtime/sharedRuntimeTrans.cpp >>>>>>>> versus math.h in VS2013 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043301 >>>>>>>> >>>>>>>> Summary of fix: >>>>>>>> VS2013's include/math.h now contains definitions for both >>>>>>>> copysign() >>>>>>>> and scalbn(). This yielded compilation conflicts with the JVM's >>>>>>>> definition of these functions within >>>>>>>> runtime/sharedRuntimeTrans.cpp. >>>>>>>> I changed copysign and scalbn definitions to be consistent with >>>>>>>> how >>>>>>>> they are defined within sharedRuntimeTrig.cpp. They are now >>>>>>>> defined >>>>>>>> as copysignA and scalbnA static functions. I also removed the >>>>>>>> !defined(AIX) conditionalization around these defintions since no >>>>>>>> conflict should now exist with AIX's math.h. >>>>>>>> >>>>>>>> Tests: >>>>>>>> JPRT build & test, Hotspot jtreg, JDK lang & util, >>>>>>>> vm.quick.testlist (in progress) >>>>>>> >>>>>>> Thank you for the fix. Looks good to me, although I am not a >>>>>>> hotspot >>>>>>> reviewer or committer. I have very low confidence that their >>>>>>> implementations of 'copysign' and 'scalbn' would exactly match >>>>>>> what we >>>>>>> use on all other platforms, especially since we can't inspect their >>>>>>> code. >>>>>> >>>>>> Thanks Tim for the review. I think due to performance reasons >>>>>> sharedRuntimeTrans.cpp and sharedRuntimeTrig.cpp have their own >>>>>> definitions. These are the only two files in the JVM that use >>>>>> copysign >>>>>> and scalbn. >>>>>> >>>>>>> >>>>>>> I have the sharedRuntimeTrans.cpp patch in my compiler upgrade >>>>>>> source >>>>>>> tree... testing now. >>>>>> >>>>>> Great, thanks again! >>>>>> Lois >>>>>> >>>>>>> >>>>>>> Tim >>>>>>> >>>>>> >>>> >> From luchsh at linux.vnet.ibm.com Mon May 26 09:04:38 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 26 May 2014 17:04:38 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX Message-ID: Hello, May I have following patch reviewed ? http://cr.openjdk.java.net/~luchsh/JDK-8043495/ The patch will add native FileChannelImpl.transferTo0() implementation for AIX by using the 'send_file' API, http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/send_file.htm?lang=en Thanks Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 26 10:09:53 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 May 2014 11:09:53 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: Message-ID: <538312F1.10503@oracle.com> On 26/05/2014 10:04, Jonathan Lu wrote: > Hello, > > May I have following patch reviewed ? > > http://cr.openjdk.java.net/~luchsh/JDK-8043495/ > > > The patch will add native FileChannelImpl.transferTo0() implementation > for AIX > by using the 'send_file' API, > http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.commtrf2/send_file.htm?lang=en Is the getsockopt needed to test the destination? I don't have access to a system with AIX and the man page you cite seems to detect this and give you the ENOTSOCK. Otherwise I don't see any issues with this, a minor consistent issue at L245 where it could be "< 0". Just looking at the OSX implementation just before this in the function and there is redundant ifdef __APPLE__. We could fix it with this patch or use another bug, I don't of course want to expand the scope of your change. -Alan From luchsh at linux.vnet.ibm.com Tue May 27 06:31:49 2014 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Tue, 27 May 2014 14:31:49 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <538312F1.10503@oracle.com> References: <538312F1.10503@oracle.com> Message-ID: Hi Alan, Thank you for the comments, here's the updated webrev, http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ On Mon, May 26, 2014 at 6:09 PM, Alan Bateman wrote: > On 26/05/2014 10:04, Jonathan Lu wrote: > >> Hello, >> >> May I have following patch reviewed ? >> >> http://cr.openjdk.java.net/~luchsh/JDK-8043495/ < >> http://cr.openjdk.java.net/%7Eluchsh/JDK-8043495/> >> >> >> The patch will add native FileChannelImpl.transferTo0() implementation >> for AIX >> by using the 'send_file' API, >> http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/ >> com.ibm.aix.commtrf2/send_file.htm?lang=en >> > Is the getsockopt needed to test the destination? I don't have access to a > system with AIX and the man page you cite seems to detect this and give you > the ENOTSOCK. > Agree, the updated patch has removed getsockopt and will check ENOTSOCK if send_file() reports error (-1). > > Otherwise I don't see any issues with this, a minor consistent issue at > L245 where it could be "< 0". > Fixed in the updated patch. > > Just looking at the OSX implementation just before this in the function > and there is redundant ifdef __APPLE__. We could fix it with this patch or > use another bug, I don't of course want to expand the scope of your change. > I'm OK with this minor removal and have done that in the second patch, please review. > > -Alan > > > Thanks Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue May 27 06:49:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 07:49:27 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: <538312F1.10503@oracle.com> Message-ID: <53843577.8050709@oracle.com> On 27/05/2014 07:31, Jonathan Lu wrote: > Hi Alan, > > Thank you for the comments, here's the updated webrev, > http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ > Thanks for the updates and for including the the ifdef __APPLE__ change. With the getsockopt removed then maybe socket.h is not needed now? Otherwise looks good to me. -Alan. From volker.simonis at gmail.com Tue May 27 08:49:46 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 May 2014 10:49:46 +0200 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <53843577.8050709@oracle.com> References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> Message-ID: On Tue, May 27, 2014 at 8:49 AM, Alan Bateman wrote: > On 27/05/2014 07:31, Jonathan Lu wrote: >> >> Hi Alan, >> >> Thank you for the comments, here's the updated webrev, >> http://cr.openjdk.java.net/~luchsh/JDK-8043495-2/ >> > > Thanks for the updates and for including the the ifdef __APPLE__ change. > With the getsockopt removed then maybe socket.h is not needed now? Otherwise > looks good to me. 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. The change looks good to me as well. Thanks for contributing it! Is there any test which exercises this code? Regards, Volker > > -Alan. From Alan.Bateman at oracle.com Tue May 27 09:00:08 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 10:00:08 +0100 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> Message-ID: <53845418.606@oracle.com> On 27/05/2014 09:49, Volker Simonis wrote: > : > 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. Thanks, just checking. > : > > > Is there any test which exercises this code? > The tests in java/nio/channels/FileChannel are the tests to run, they will give the transfer methods a good work out. -Alan. From chuanshenglu at gmail.com Tue May 27 09:43:37 2014 From: chuanshenglu at gmail.com (Jonathan Lu) Date: Tue, 27 May 2014 17:43:37 +0800 Subject: RFR JDK-8043495: add native FileChannelImpl.transferTo0() implementation for AIX In-Reply-To: <53845418.606@oracle.com> References: <538312F1.10503@oracle.com> <53843577.8050709@oracle.com> <53845418.606@oracle.com> Message-ID: Thanks, Alan and Volker! I will push this change. Regards, Jonathan On Tue, May 27, 2014 at 5:00 PM, Alan Bateman wrote: > On 27/05/2014 09:49, Volker Simonis wrote: > >> : >> 'send_file()' is declared in 'sys/socket.h' on AIX, so we need it. >> > Thanks, just checking. > > > : >> >> >> Is there any test which exercises this code? >> >> The tests in java/nio/channels/FileChannel are the tests to run, they > will give the transfer methods a good work out. > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: