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
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
> wrote:
>
>
> buildreplayjars sometimes fail with an exception and I think that's
> caused by the lack of support for default methods
src/share/vm/runtime/globals.hpp
- develop_pd(bool, ImplicitNullChecks, \
+ diagnostic_pd(bool, ImplicitNullChecks,
\
"Generate code for implicit null checks") \
Align the \
> On May 10
> 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 too difficult.
>
>
K 9 we already passed Features freeze dates.
>>
>> Should I file them to JBS and send webrev after jdk10 repos is opened?
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2017/01/04 8:06, Vladimir Kozlov wrote:
>>> Contribut
On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff
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 Java development te
On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff
wrote:
> On 2013-09-05 02:30, Christian Thalinger wrote:
>>
>> On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff
>> wrote:
>>
>>> Please, review the changes.
>>>
>>> http://cr.openjdk.java.n
7, Christian Thalinger wrote:
>>
>> On Sep 5, 2013, at 12:31 AM, Dmitry Samersoff
>> wrote:
>>
>>> On 2013-09-05 02:30, Christian Thalinger wrote:
>>>>
>>>> On Sep 4, 2013, at 1:35 PM, Dmitry Samersoff
>>>> wrote:
>>>&g
Changeset: 78b4dc33e6e6
Author:twisti
Date: 2013-09-26 18:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78b4dc33e6e6
8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
Reviewed-by: jrose
! src/share/classes/java/lang/invoke/MemberName.java
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
! src/share/classes/java/lang/invoke/MethodHandle
Looks good.
On Dec 9, 2013, at 1:05 PM, Roland Westrelin
wrote:
>
> Hi Vladimir,
>
> Thanks for reviewing this change.
>
>> CC to serviceability group.
>>
>> I am for "always call notice_modification() in parse_stream()”.
>
> This then:
>
> http://cr.openjdk.java.net/~roland/8029383/webre
Why are we using a different file for the inline data?
On Dec 27, 2013, at 6:15 PM, Vladimir Kozlov 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 correctly inline
> met
Looks good.
On Jan 21, 2014, at 12:41 AM, Olivier Lagneau
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:
>>
>> Oops, right
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:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6
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
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
gt; Label skip_jvmti_method_exit;
> -__ cmpb(Address(r15_thread, JavaThread::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, r
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
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8034935
> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
>
> Citing John's explanation of m
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 compil
On Aug 21, 2012, at 2:47 PM, BILL PITTORE 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 code. Rather
> the cla
On Aug 27, 2012, at 2:07 PM, Yumin Qi 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 porting to amd64
Looks good. -- Chris
On Aug 28, 2012, at 4:48 PM, Yumin Qi 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
>>
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 wrote:
> Hi, all
>
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:
>> issues related to max_stack.
>>
>>
>> Thanks,
>> Serguei
>>
>> On 10/31/12 10:54 AM, Christian Thalinger wrote:
>>> On Oct 30, 2012, at 4:25 PM, serguei.spit...@oracle.com wrote:
>>>
>>>> Ok, it seems there are some
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.h
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.:
On Apr 25, 2013, at 6:45 AM, Volker Simonis 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 to post a review
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:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/ho
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:
> http://cr.openjdk.java.net/~sspitsyn/
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:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/201
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
! src/share/classes/java/lang/invoke/Met
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
! src/share/classes/java/lang/invoke/MethodHandleImpl.
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:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI
On Aug 12, 2013, at 2:43 PM, Coleen Phillimore
wrote:
>
> Yumin,
>
> I don't think this change should be added to the JVM for the following
> reasons.
This change is something that I (kind of) requested from Yumin since it would
help to reproduce crashes in the compilers. Getting replay d
On Aug 12, 2013, at 8:43 PM, Yumin Qi 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 wants us to fix
>
A.
>
> Thanks,
> Christian
>
> -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
&
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 compile
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 M&M: approximate memory allocation rate/amount per thread
> 7003271
39 matches
Mail list logo
