Re: review (S) for 6943485: JVMTI always on capabilities change code generation too much

On Tue, 2010-04-20 at 15:39 -0700, Tom Rodriguez wrote: http://cr.openjdk.java.net/~never/6943485 6943485: JVMTI always on capabilities change code generation too much Reviewed-by: The set of always on JVMTI capabilities include thing which will cause changes in the code the compiler

Re: Pls review 6173675/7003271

On Jan 4, 2011, at 10:00 PM, Paul Hohensee wrote: These two rfes implement per-thread approximate memory allocation tracking. 6173675 also adds multi-thread-id versions of getThreadCpuTime and getThreadUserTime. 6173675 MM: approximate memory allocation rate/amount per thread 7003271

Re: RFR: 6830717: replay of compilations would help with debugging

On Aug 6, 2012, at 2:40 PM, yumin...@oracle.com wrote: Hi, Please give your comments of the changes about 6830717: replay of compilations would help with debugging. http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 Sometime jvm crashes in the process of compilation or in compiled

Re: Code review for SA changes to allow for new processor architectures (7154641)

On Aug 21, 2012, at 2:47 PM, BILL PITTORE bill.pitt...@oracle.com wrote: These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing

Re: RFR: 6879063: SA should use hsdis for disassembly

On Aug 27, 2012, at 2:07 PM, Yumin Qi yumin...@oracle.com wrote: Hi, all Can I have you code review of 6879063: SA should use hsdis for disassembly http://cr.openjdk.java.net/~minqi/6879063 The SA has Java based disassemblers for x86 and sparc but amd64. Instead of

Re: RFR: 6879063: SA should use hsdis for disassembly

Looks good. -- Chris On Aug 28, 2012, at 4:48 PM, Yumin Qi yumin...@oracle.com wrote: Hi, all Updated with feedback suggestions. Please have a look again at the same link. Thanks Yumin On 2012/8/27 14:07, Yumin Qi wrote: Hi, all Can I have you code review of

Re: RFR: 6879063: SA should use hsdis for disassembly

This change broke the usage of previously built versions of hsdis. I filed a bug for it: 8000489: older builds of hsdis don't work anymore after 6879063 Yumin, I assigned the bug to you. Could you please take care of it? -- Chris On Aug 27, 2012, at 2:07 PM, Yumin Qi yumin...@oracle.com

Re: 1-line review request: 7194607 VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge

On Oct 30, 2012, at 4:25 PM, serguei.spit...@oracle.com wrote: Ok, it seems there are some suspicious fragments in the interpreter code. Christian, could you, please, check and comment the fragments below? This is how the Method::max_stack() is defined: src/share/vm/oops/method.hpp:

Re: 1-line review request: 7194607 VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge

. I'm not comfortable to fix it as a part of 7194607. One question is what tests are need to be run to verify possible fixes. I'll open a separate CR under hotspot/runtime to track the Interpreter issues related to max_stack. Thanks, Serguei On 10/31/12 10:54 AM, Christian Thalinger wrote

Re: Review Request (S) 8006542: JSR 292: the VM_RedefineClasses::append_entry() must support invokedynamic entry kinds

On Jan 22, 2013, at 4:07 PM, serguei.spit...@oracle.com wrote: Please, review the fix for: https://jbs.oracle.com/bugs/browse/JDK-8006542 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8006542-JVMTI-JSR292.1/ src/share/vm/prims/jvmtiRedefineClasses.hpp: +

Re: hs25 review request (round 2): 8007037 JSR 292: the VM_RedefineClasses::append_entry() should do cross-checks with indy operands

On Apr 11, 2013, at 4:08 PM, serguei.spit...@oracle.com wrote: Please, review the hs25 fix (round 2) below. Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8007037-JVMTI-JSR292.2/ One thing that makes it hard to follow what going on are the variable names, e.g.:

Re: hg: hsx/hotspot-rt/hotspot: 8012927: 'assert(nbits == 32 || (-(1 nbits-1) = x x ( 1 nbits-1))) failed: value out of range' in interpreter initialization.

On Apr 25, 2013, at 6:45 AM, Volker Simonis volker.simo...@gmail.com wrote: Hi Jiangli, that's really sad! First because it is not the way it is supposed to work and second because we detected and fixed this same problem a few days ago as well.. I don't understand what's the problem

Re: Review Request (S) 8014288: perf regression in nashorn JDK-8008448.js test after 8008511 changes

Looks good. -- Chris On May 23, 2013, at 4:19 PM, serguei.spit...@oracle.com wrote: Please, review the fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=8014288 jbs: https://jbs.oracle.com/bugs/browse/JDK-8014288 Open webrev:

Re: Review Request (S) 8015436: compiler/ciReplay/TestSA.sh fails with assert() index is out of bounds

Looks good. -- Chris On May 29, 2013, at 9:08 PM, serguei.spit...@oracle.com wrote: Please, review the fix and unit test for: bug: http://bugs.sun.com/view_bug.do?bug_id=8015436 jbs: https://jbs.oracle.com/bugs/browse/JDK-8015436 Open webrev:

Re: Review Request (S) 8014052: JSR292: assert(end_offset == next_offset) failed: matched ending

Looks good. -- Chris On May 30, 2013, at 11:19 PM, serguei.spit...@oracle.com wrote: Please, review the fix for: bug: https://jbs.oracle.com/bugs/browse/JDK-8014052 jbs: https://jbs.oracle.com/bugs/browse/JDK-8014052 Open webrev:

hg: jdk8/tl/jdk: 7177472: JSR292: MethodType interning penalizes scalability

Changeset: 2b63fda275a3 Author:twisti Date: 2013-06-17 16:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b63fda275a3 7177472: JSR292: MethodType interning penalizes scalability Reviewed-by: twisti Contributed-by: Aleksey Shipilev aleksey.shipi...@oracle.com !

hg: jdk8/tl/jdk: 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs

Changeset: bd6949f9dbb2 Author:twisti Date: 2013-07-03 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd6949f9dbb2 8019184: MethodHandles.catchException() fails when methods have 8 args + varargs Reviewed-by: jrose !

Re: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments

On Jul 25, 2013, at 5:14 PM, serguei.spit...@oracle.com wrote: Please, review the fix for: bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 Open webrev:

Re: RFR: 8020962: dump loaded java classes when vm crash

On Aug 12, 2013, at 8:43 PM, Yumin Qi yumin...@oracle.com wrote: Coleen, Chris Thalinger already answered some of your concerns. For jar file which dumped in this change, compiler replay has added functions to SA to dump out replay jars against core file. Since customer is the one

Re: RFR: 8020962: dump loaded java classes when vm crash

-Original Message- From: hotspot-runtime-dev-boun...@openjdk.java.net [mailto:hotspot-runtime-dev-boun...@openjdk.java.net] On Behalf Of Christian Thalinger Sent: Monday, August 12, 2013 9:12 PM To: Coleen Phillimore Cc: serviceability-dev@openjdk.java.net serviceability-dev

Re: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation for invokedynamic

On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff dmitry.samers...@oracle.com wrote: Please, review the changes. http://cr.openjdk.java.net/~dsamersoff/JDK-8015848/webrev.01/ With this change you can dump the boot class path classes again? -- Chris -Dmitry -- Dmitry Samersoff Oracle

Re: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation for invokedynamic

On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff dmitry.samers...@oracle.com wrote: On 2013-09-05 02:30, Christian Thalinger wrote: On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff dmitry.samers...@oracle.com wrote: Please, review the changes. http://cr.openjdk.java.net/~dsamersoff/JDK

Re: RR(S): JDK-8015848: SA: ByteCodeRewriter needs implementation for invokedynamic

-11 20:37, Christian Thalinger wrote: On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff dmitry.samers...@oracle.com wrote: On 2013-09-05 02:30, Christian Thalinger wrote: On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff dmitry.samers...@oracle.com wrote: Please, review the changes. http

hg: jdk8/tl/jdk: 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms

Changeset: 66884b270b44 Author:twisti Date: 2013-10-24 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/66884b270b44 8026502: java/lang/invoke/MethodHandleConstants.java fails on all platforms Reviewed-by: iveresov, jrose !

Re: RFR(L): 8028468: Add inlining information into ciReplay

Why are we using a different file for the inline data? On Dec 27, 2013, at 6:15 PM, Vladimir Kozlov vladimir.koz...@oracle.com wrote: http://cr.openjdk.java.net/~kvn/8028468/webrev/ https://bugs.openjdk.java.net/browse/JDK-8028468 Add inlining information into Compilation Replay data to

Re: RFR 8019389: SA-JDI JSR292: sun.jvm.hotspot.jdi.StackFrame.thisObject() throws sun.jvm.hotspot.utilities.AssertionFailure: sanity check

Looks good. On Jan 21, 2014, at 12:41 AM, Olivier Lagneau olivier.lagn...@oracle.com wrote: Please find the new webrev with copyright date fixed (changed to 2014). Webrev: http://cr.openjdk.java.net/~olagneau/8019389/webrev.01/ Olivier. Olivier Lagneau said on date 1/20/2014 5:50 PM:

Re: RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), cur_stack_depth out of sync)

I cannot comment on the performance impact but the change looks good. On Jan 31, 2014, at 6:58 PM, serguei.spit...@oracle.com wrote: Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-6471769 Open webrev:

Re: RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), cur_stack_depth out of sync)

Looks good. On Feb 25, 2014, at 12:43 PM, serguei.spit...@oracle.com wrote: Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-6471769 Open webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 Summary: This is another Test

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

Since: int _interp_only_mode; is an int field I would prefer to actually read the value as an int instead of just a byte on x86: +__ cmpb(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); Otherwise this looks good. On May 13, 2014, at 11:30 AM, Staffan Larsen

Re: RFR: 8041934 com/sun/jdi/RepStep.java fails on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync

::interp_only_mode_offset()), 0); +__ cmpl(Address(r15_thread, JavaThread::interp_only_mode_offset()), 0); __ jcc(Assembler::zero, skip_jvmti_method_exit, true); save_native_result(masm, ret_type, stack_slots); On 14 maj 2014, at 00:21, Christian Thalinger christian.thalin...@oracle.com wrote

Re: [9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle

Looks good. Would be good to put a FIXME on the comment as well so we don’t forget to remove it. On May 26, 2014, at 12:25 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8034935 http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00

Re: RFR: 8059625 - JEP-JDK-8043304: Test task: DTrace- tests for segmented codecache feature

40 public static int[] getAvailableCompilationLevels() { 41 if (System.getProperty(java.vm.info).startsWith(interpreted )) { 42 return new int[0]; 43 } Wouldn’t it be better to check the UseCompiler flag instead? On Dec 19, 2014, at 11:03 AM, Dmitrij

Re: RFR(S): 8071999: SA's buildreplayjars fail with exception

Since you’re saying it only fixes it partially should we file a followup bug and maybe leave a comment behind? On Feb 4, 2015, at 7:04 AM, Roland Westrelin roland.westre...@oracle.com wrote: buildreplayjars sometimes fail with an exception and I think that's caused by the lack of

Re: RFR[9u-dev]: 8150900: Implement diagnostic_pd

src/share/vm/runtime/globals.hpp - develop_pd(bool, ImplicitNullChecks, \ + diagnostic_pd(bool, ImplicitNullChecks, \ "Generate code for implicit null checks") \ Align the \ > On May

Re: JEP 158 support for JIT

> On Jan 2, 2017, at 6:08 PM, Yasumasa Suenaga wrote: > > Thanks Vladimir, > >> Definitely not in JDK 9. And I can't say when it could be done or done at >> all. > > I hope this feature will be implemented ASAP. You can always contribute an implementation. Shouldn’t be