> On Jun 20, 2017, at 3:14 AM, Claes Redestad wrote:
>
> Hi,
>
> as a startup optimization, we can avoid a number of reflective operations on
> variouscore classes by adding a specialized objectFieldOffset method taking
> Class and String rather than Field:
>
> Webrev: https://bugs.openjdk.jav
> On May 4, 2016, at 1:48 PM, Artem Smotrakov
> wrote:
>
> Hello,
>
> Please review two small patches for jdk and hotspot repos which add array
> bound checks to functions which return a length of bytecode instruction.
>
> Please see details in https://bugs.openjdk.java.net/browse/JDK-815220
> On Feb 19, 2016, at 1:22 PM, Aleksey Shipilev
> wrote:
>
> On 02/20/2016 01:40 AM, Christian Thalinger wrote:
>>> On Feb 19, 2016, at 9:03 AM, John Rose wrote:
>>> On Feb 19, 2016, at 9:57 AM, Christian Thalinger
>>> mailto:christian.thalin...@orac
> On Feb 19, 2016, at 9:03 AM, John Rose wrote:
>
> On Feb 19, 2016, at 9:57 AM, Christian Thalinger
> mailto:christian.thalin...@oracle.com>>
> wrote:
>>
>> Why don’t you change the values to:
>>
>>static final byte LATIN1 = 1;
>>
> On Feb 19, 2016, at 4:05 AM, Peter Levart wrote:
>
> Hi,
>
> Just a stupid question.
>
> Your comment in String:
>
> 140 * @implNote Note this field is not {@link Stable}, because we want
> 141 * LATIN1 (0) coder to fold too. {@link Stable} would not allow that,
> 142 * as it
> On Jan 9, 2016, at 11:23 PM, Alan Bateman wrote:
>
>
>
> On 09/01/2016 19:35, James Laskey wrote:
>> Alan questioned why this is showing up after the sjavac changes. There was
>> concern there was some lurking issue.
>>
> No issue removing the test from the exclude list, that should have b
-Konstantin
>
> On 12/15/2015 08:36 PM, Christian Thalinger wrote:
>>
>>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov
>>> mailto:konstantin.she...@oracle.com>> wrote:
>>>
>>> Hi Christian
>>>
>>> Thanks for reviewing, I
>
and either do a simple linear search to find the entry or build up a table like
the HotSpotConstantPool example above.
>
> -Konstantin
>
> On 12/15/2015 06:23 AM, Christian Thalinger wrote:
>>
>>> On Dec 11, 2015, at 1:54 AM, Konstantin Shefov
>>> mailt
;>>
>>>>> -Konstantin
>>>>>
>>>>> On 11/18/2015 12:04 AM, Remi Forax wrote:
>>>>>> Hi Konstantin,
>>>>>> Technically, getInvokedynamicRefInfoAt should be
>>>>>> getNameAndTypeOfInvokedynamicRefInfo
etter to decompose the API, i.e. to have a
> method
> int getInvokedynamicRefNameAndTypeIndex(int index)
> that returns the nameAndType index and to reuse
> getNameAndTypeRefInfoAt(index) to get the corresponding array of Strings.
>
> cheers,
> Rémi
>
> - Mail
[CC'ing core-libs-dev]
> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
> wrote:
>
> Hello
>
> Please review an enhancement to add three new methods to
> sun.reflect.ConstantPool class.
> The following methods are suggested:
>
> public String[] getNameAndTypeRefInfoAt(int index) - returns st
> On Oct 22, 2015, at 6:31 AM, Paul Sandoz wrote:
>
> Hi Chris,
>
> This looks like a good first step. I am sure hotspot devs will have more
> concrete review comments, but i like the way the method aliasing (copying the
> same technique StrictMath -> Math) avoids any changes to the intrinsic
> On Oct 19, 2015, at 8:09 AM, Bob Vandette wrote:
>
> Here’s the updated set of webrev’s that address two issues:
>
> 1. Move jni_util.h out of jawt.h
> 2. Christians concern over using a single variable name for Makefile and
> C/C++ logic.
Thanks. Looks good to me.
>
> http://cr.openjdk.
Copy-pasting the comment I made earlier (internally):
>> make/bsd/makefiles/gcc.make:
>>
>> + ifeq ($(BUILD_STATIC),true)
>> + CXXFLAGS += -DSTATIC_BUILD
>> + CFLAGS += -DSTATIC_BUILD
>>
>> Can we use the same name everywhere?
>
> We were trying to differentiate Makefile options from compile ti
> On Feb 4, 2015, at 9:44 AM, Daniel Fuchs wrote:
>
> On 04/02/15 17:21, Christian Thalinger wrote:
>>>
>>> -const jlong MAX_DIFF_SECS = 0x01; // 2^32
>>> +const jlong MAX_DIFF_SECS = 0x01LL; // 2^32
>>
>> Don’t use LL direc
> On Feb 4, 2015, at 3:31 AM, Daniel Fuchs wrote:
>
> Hi,
>
> Please find below a fix for:
>
> 8072450: 9-dev build failed on elinux-i586 and rlinux-i586
>
> My fix for JDK-8068730 which was integrated from hs-rt into jdk9-dev
> yesterday is causing a build failure in the jdk9/dev nightly on
> On Nov 3, 2014, at 12:41 PM, David Chase wrote:
>
>
> On 2014-11-03, at 3:09 PM, Peter Levart wrote:
>
>> Hi David,
>>
>> I was thinking about the fact that java.lang.invoke code is leaking into
>> java.lang.Class. Perhaps, If you don't mind rewriting the code, a better
>> code structure
On Jun 30, 2014, at 5:50 PM, Coleen Phillimore
wrote:
>
> On 6/30/14, 3:50 PM, Christian Thalinger wrote:
>> private Class(ClassLoader loader) {
>> // Initialize final field for classLoader. The initialization
>> value of non-null
>>
On Jun 30, 2014, at 1:06 PM, Coleen Phillimore
wrote:
>
> On 6/30/14, 3:50 PM, Christian Thalinger wrote:
>> private Class(ClassLoader loader) {
>> // Initialize final field for classLoader. The initialization
>> value of non-null
>>
private Class(ClassLoader loader) {
// Initialize final field for classLoader. The initialization value
of non-null
// prevents future JIT optimizations from assuming this final field is
null.
classLoader = loader;
+componentType = null;
}
Are we wor
On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov
wrote:
> Tobias, I'll take care of it.
Are you also taking care of the backports?
>
> Best regards,
> Vladimir Ivanov
>
> On 6/2/14 10:04 AM, Tobias Hartmann wrote:
>>
>> On 28.05.2014 12:48, Vladimir Ivanov wrote:
>>> Looks good.
>>>
>>> It sho
Thanks, John and Vladimir.
On May 15, 2014, at 2:46 PM, Vladimir Ivanov
wrote:
> Looks good.
>
> Best regards,
> Vladimir Ivanov
>
> On 5/15/14 9:48 PM, Christian Thalinger wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8032606
>> http://cr.openjdk.java
https://bugs.openjdk.java.net/browse/JDK-8032606
http://cr.openjdk.java.net/~twisti/8032606/webrev.00
8032606: ClassValue.ClassValueMap.type is unused
Reviewed-by:
hodTypeForm::setCachedLambdaForm(...) to
>>>> update the cache without checking it again. In a high concurrency
>>>> setting, this leads to multiple LambdaForms being created for the
>>>> same invokeExact instruction because the cache entry is overwritten
>>&
On Apr 3, 2014, at 9:44 PM, John Rose wrote:
> On Apr 3, 2014, at 6:33 PM, Christian Thalinger
> wrote:
>
>> Of course they are popular because these are the type names. There is no
>> type L; it’s an object. I don’t understand why we have to use different
>>
s.
>
> Best regards,
> Vladimir Ivanov
>
> On 3/26/14 12:24 AM, Christian Thalinger wrote:
>> + enum BasicType {
>> + L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types
>> + I_TYPE('I', int.class,Wrapp
On Mar 24, 2014, at 1:33 PM, Igor Ignatyev wrote:
> Hi all,
>
> Please review the patch:
>
> Problems:
> - MethodHandlesTest::testCatchException() doesn't provide enough testing of
> j.l.i.MethodHandles::catchException().
> - MethodHandlesTest contains more than 3k lines, an auxiliary code to
+ enum BasicType {
+ L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types
+ I_TYPE('I', int.class,Wrapper.INT),
+ J_TYPE('J', long.class, Wrapper.LONG),
+ F_TYPE('F', float.class, Wrapper.FLOAT),
+ D_TYPE('D', double.class, Wrapper.DO
On Mar 18, 2014, at 2:35 PM, John Rose wrote:
> On Mar 18, 2014, at 1:36 PM, Christian Thalinger
> wrote:
>
>> Why are we not using an Enum instead of an "untyped" byte?
>
> Byte is moderately typed, in the sense (which I rely on during development)
> th
On Mar 14, 2014, at 4:28 AM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8037210
> 953 lines changed: 425 ins; 217 del; 311 mod
>
> This is a massive cleanup of JSR292 code to replace char-based description of
> b
; Vladimir Ivanov
>
> On 3/8/14 4:51 AM, Christian Thalinger wrote:
>> Seems good to me. I’d like to have another name for this method:
>>
>> + private static Object invokeCustom(MethodHandle target, Object...
>> args) throws Throwable {
>>
>>
Seems good to me. I’d like to have another name for this method:
+ private static Object invokeCustom(MethodHandle target, Object... args)
throws Throwable {
On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
> https://bugs.openj
Looks good.
While touching the code some time ago John and I were playing around with the
idea to call Class.cast in the failing case:
+ static T castReference(Class t, U x) {
+ // inlined Class.cast because we can't ForceInline it
+ if (x != null && !t.isInstance(x))
+
On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov
wrote:
> Paul,
>
> Thanks for the feedback! See my answers inline.
>
> Updated webrev:
> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/
>
> I finally figured out how to make caching work. This webrev contains
> these changes.
>
>
Looks good.
On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8033278
>
> The fix for 8032585 [1] introduced a regression: in some cases access
> check on a reference class is omitted.
>
>
Looks good.
On Jan 27, 2014, at 8:05 AM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8032585
>
> JSR292 access verification logic refuses method handle lookup access to
> methods which are defined on inaccessible
https://bugs.openjdk.java.net/browse/JDK-8031043
http://cr.openjdk.java.net/~twisti/8031043/webrev.00
8031043: ClassValue's backing map should have a smaller initial size
Reviewed-by:
The current initial size for ClassValue's backing WeakHashMap (ClassValueMap)
is:
private static final
On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov
wrote:
> Chris,
>
> Thanks for looking into this. See my answers inline.
>
> Best regards,
> Vladimir Ivanov
>
> On 1/15/14 9:51 PM, Christian Thalinger wrote:
>> [I’m resending something I sent earlier today to Vla
[I’m resending something I sent earlier today to Vladimir directly.]
On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8031502
>
> InvokeBytecodeGenerator can produce incorrect bytecode for a
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
Unfortunate but I understand. It might be a good idea to add a
getCallerClass(-1) call to the test case.
On Oct 7, 2013, at 1:24 AM, Mandy Chung wrote:
> JDK 8 was feature complete in June and there just isn't sufficient time
> remaining to get agreement and feedback on an API to examine the
ink it is intelligible as
> posted. — John
I'm fine with that.
>
> On Oct 4, 2013, at 11:34 AM, John Rose wrote:
>
>> Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
>> also. — John
>>
>> On Oct 4, 2013, at 11:17 AM
src/share/classes/java/lang/invoke/MethodHandles.java:
You have renamed "coll" to "filter" but the documentation still references
"coll" in multiple places, e.g.:
+ * If the filter method handle {@code coll} consumes one argument and
produces
+ * a non-void result, then {@code collectAr
Looks good.
On Oct 2, 2013, at 12:33 PM, John Rose wrote:
> Push-button webrev generator to the rescue:
> http://cr.openjdk.java.net/~jrose/8024599/webrev.01
>
> — John
>
> On Oct 2, 2013, at 11:23 AM, Christian Thalinger
> wrote:
>
>> Since there
On Sep 20, 2013, at 5:09 PM, John Rose wrote:
> On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov
> wrote:
>
>> I cleaned javadoc a little [1], so it is more readable in the browser now.
>
> Thanks; I applied those edits. I fixed the problem of a missing in a few
> other places too.
>
>> The
Thank you for doing this; it is much clearer now. Looks good.
On Oct 1, 2013, at 10:19 PM, John Rose wrote:
> Chris Thalinger suggested removing the new booleans from the changed
> "getDirectMethod" call sites and instead put the intended usage into the
> method names, e.g., "getDirectMethodN
Since there is no new webrev I assume you incorporated all the stuff below. If
that's the case then it looks good.
On Sep 20, 2013, at 6:18 PM, John Rose wrote:
> On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov
> wrote:
>
>> John,
>>
>> I don't see much value in documenting buggy behavior of
Looks good.
On Sep 27, 2013, at 5:39 AM, Sergey Kuksenko wrote:
>
> Updated version at
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.02/
> according comments:
> - remove "null check" comment near Object.requireNonNull calls
> - distort/(change parameters order) in key-purposed M
On Sep 19, 2013, at 2:31 PM, John Rose wrote:
>
> On Sep 18, 2013, at 5:05 PM, Christian Thalinger
> wrote:
>
>> src/share/classes/java/lang/invoke/MethodHandles.java:
>>
>> + * methods as if they were normal methods, but the JVM verifier rejects
>>
ase wrote:
>>>>
>>>>> The test is adapted from the test in the bug report.
>>>>> The headline on the bug report is wrong -- because it uses reflection in
>>>>> the test to do the invocation,
>>>>> the thrown exception is wrappe
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
fields and name can actually be null is the
tricky part. Someone down the line in 5 years might not know about this
conversation and be surprised.
> your call of course, just looks odd as-is.
>
> Sent from my phone
>
> On Sep 26, 2013 8:15 PM, "Christian Thalinger"
>
I
wanted to keep the pattern if someone adds code to that method in the future.
The compiler will optimize it anyway.
> Vitaly
>
> Sent from my phone
>
> On Sep 26, 2013 5:47 PM, "Christian Thalinger"
> wrote:
>
> On Sep 26, 2013, at 2:28 PM, John Rose
On Sep 26, 2013, at 2:28 PM, John Rose wrote:
> On Sep 26, 2013, at 1:13 PM, Christian Thalinger
> wrote:
>
>> On Sep 26, 2013, at 11:50 AM, Christian Thalinger
>> wrote:
>>
>>>
>>> On Sep 26, 2013, at 1:22 AM, Peter Levart wrote:
>>
On Sep 26, 2013, at 11:50 AM, Christian Thalinger
wrote:
>
> On Sep 26, 2013, at 1:22 AM, Peter Levart wrote:
>
>> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>>>
>>> 80
On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko wrote:
> Hi All,
>
> I updated fix.
> You may find it here
> http://cr.openjdk.java.net/~skuksenko/jsr335/8024635/webrev.01/
The change looks good. Since we use Objects.requireNonNull now we can remove
the null check comment:
+Objects.req
On Sep 26, 2013, at 1:22 AM, Peter Levart wrote:
> On 09/26/2013 01:27 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8019192/webrev/
>>
>> 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
>> Reviewed-by:
>>
>>
http://cr.openjdk.java.net/~twisti/8019192/webrev/
8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()
Reviewed-by:
This is a race in MemberName's name and type getters.
MemberName's type field is of type Object so it can hold different objects when
it gets filled in from the VM.
src/share/classes/java/lang/invoke/MethodHandles.java:
+ * methods as if they were normal methods, but the JVM verifier rejects
them.
I think you should say "JVM byte code verifier" here.
+ * (Note: JVM internal methods named {@code } not visible
to this API,
+ * even thou
Looks good.
On Sep 12, 2013, at 6:02 PM, John Rose wrote:
> Please review this change for a change to the JSR 292 implementation:
>
> http://cr.openjdk.java.net/~jrose/8001109/webrev.00/
>
> The change is mostly to javadoc and unit tests, documenting and testing some
> corner cases of JSR 292
On Sep 12, 2013, at 4:34 PM, John Rose wrote:
> Please review this change for a change to the JSR 292 implementation:
>
> http://cr.openjdk.java.net/~jrose/8019417/webrev.00
>
> The change is to javadoc and unit tests, documenting and testing some corner
> cases of JSR 292 APIs.
>
> Since th
ceptions that lead to the defined exception being thrown. The commented
>> line should have just been removed (I think).
>>
>> On 2013-09-12, at 1:24 PM, Christian Thalinger
>> wrote:
>>
>>> + // err.initCause(ex);
>>>
>>> Why is this commented?
>>>
>>> -- Chris
>
+ // err.initCause(ex);
Why is this commented?
-- Chris
On Sep 6, 2013, at 4:59 PM, David Chase wrote:
> new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/
> Same small changes to the sources, plus a test.
>
> bug: wrong exception was thrown in call of me
On Jul 30, 2013, at 4:11 PM, Nick Williams
wrote:
> Quick question for those of you that know anything about @CallerSensitive...
>
> After looking at the code and experimenting some, I've discovered that
> getCallerClass() doesn't actually keep going until it finds the first method
> without
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.
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
On Jun 13, 2013, at 12:09 PM, Aleksey Shipilev
wrote:
> On 06/13/2013 09:51 PM, Christian Thalinger wrote:
>> While preparing the push I noticed the new code gives a warning:
>>
>> src/share/classes/java/lang/invoke/MethodType.java:1106: warning:
>>
On Jun 11, 2013, at 7:16 PM, Christian Thalinger
wrote:
>
> On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev
> wrote:
>
>> On 06/11/2013 10:24 PM, Christian Thalinger wrote:
>>>
>>> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev
>>> wrote
On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev
wrote:
> On 06/11/2013 10:24 PM, Christian Thalinger wrote:
>>
>> On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev
>> wrote:
>>
>>> On 06/11/2013 08:06 PM, Christian Thalinger wrote:
>>>> Anyway, le
On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev
wrote:
> On 06/11/2013 08:06 PM, Christian Thalinger wrote:
>> Anyway, let's push this.
>
> Do you want me any other testing done? vm.mlvm.testlist is OK, but I
> haven't done the full JPRT test cycle, only the bui
On Jun 11, 2013, at 9:03 AM, Aleksey Shipilev
wrote:
> On 06/11/2013 07:43 PM, Christian Thalinger wrote:
>> Thanks for this but I was thinking running it with -Xprof to see
>> whether some of the table methods show up on the profile.
>
> I put little trust into this k
On Jun 11, 2013, at 1:47 AM, Aleksey Shipilev
wrote:
> On 06/11/2013 02:52 AM, Christian Thalinger wrote:
>> This looks good to me.
>
> Thanks for the review!
>
>> Could you run RegExp with Nashorn again with and without your changes?
>
> Being single-threade
On Jun 10, 2013, at 8:47 AM, Aleksey Shipilev
wrote:
> On 06/09/2013 12:17 AM, Peter Levart wrote:
>> In case the loop retries, there's no need to construct another WeakEntry...
>>
>>T interned;
>> WeakEntry e = new WeakEntry<>(elem, stale);
>>do {
>>
On Mar 27, 2013, at 8:01 PM, Mandy Chung wrote:
> Thanks for the review. I forgot to mention that Chris contributed the
> initial patch (thanks).
>
> On 3/27/2013 1:13 PM, Christian Thalinger wrote:
>> On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote:
>>
>>&g
On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote:
> This is the JDK change for JEP 176: JEP 176: Mechanical Checking of
> Caller-Sensitive Methods [1]. Christian has posted the webrev for the
> hotspot VM change a couple weeks ago [2].
>
> Webrev at:
> http://cr.openjdk.java.net/~mchung/jdk8/
On Mar 19, 2013, at 6:02 PM, Christian Thalinger
wrote:
>
> On Mar 19, 2013, at 5:21 PM, John Rose wrote:
>
>> On Mar 14, 2013, at 8:31 PM, Christian Thalinger
>> wrote:
>>
>>> [This is the HotSpot part of JEP 176]
>>>
>>> http:
On Mar 19, 2013, at 5:21 PM, John Rose wrote:
> On Mar 14, 2013, at 8:31 PM, Christian Thalinger
> wrote:
>
>> [This is the HotSpot part of JEP 176]
>>
>> http://cr.openjdk.java.net/~twisti/7198429
>>
>> 7198429: need checked categorization
t that yesterday. The better solution seems to
be to leave the old entry point. If we add a new one that kind of adds a new
method to the "official" VM interface. Other VM implementors would have to
implement that one as well because the JDK then links to this new method.
Thanks
[This is the HotSpot part of JEP 176]
http://cr.openjdk.java.net/~twisti/7198429
7198429: need checked categorization of caller-sensitive methods in the JDK
Reviewed-by:
More information in JEP 176:
http://openjdk.java.net/jeps/176
src/share/vm/ci/ciMethod.cpp
src/share/vm/ci/ciMethod.hpp
src/
On Feb 8, 2013, at 10:38 AM, Krystal Mo wrote:
> Hi all,
>
> Could I have a couple of review for this change:
>
> 7087570: java.lang.invoke.MemberName information wrong for method handles
> created with findConstructor
> Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitl
On Jan 11, 2013, at 10:19 AM, Ulf Zibis wrote:
> Hi Sherman,
>
> Am 11.01.2013 06:47, schrieb Xueming Shen:
>> (1) sp++ at Ln#159 probably can be moved into ln#155? the local sp here
>> should
>> not change the real "sp" after "break+return".
>> (2) maybe the "overflowflag" can just be rep
On Nov 30, 2012, at 10:48 AM, Krystal Mo wrote:
> Hi all,
>
> Could I get a couple of review for this small change, please?
> And could someone from the JDK side sponsor this change?
>
> Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066
> Webrev: http://cr.openjdk.java.net/~kmo/8004066/webre
On Oct 19, 2012, at 10:42 AM, Mandy Chung wrote:
> On 10/18/2012 6:11 PM, David Holmes wrote:
>> Hi Martin,
>>
>> On 19/10/2012 10:58 AM, Martin Buchholz wrote:
>>> http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java
>>>
>>
>
On Oct 18, 2012, at 6:11 PM, David Holmes wrote:
> Hi Martin,
>
> On 19/10/2012 10:58 AM, Martin Buchholz wrote:
>> http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java
>
> That code uses runFinalization in places which means it
On Oct 18, 2012, at 4:04 PM, Mandy Chung wrote:
> On 10/18/2012 3:37 PM, Christian Thalinger wrote:
>>
>>> Just curious - the test runs with a max of 10 GCs. You
>>> reproduced this bug on a slower machine with fastdebug build.
>>> If you increase the
y idea. I just picked the bug and tried the suggested fix and
it worked. The other suggested fix is to increase the sleep time (but I don't
like that).
-- Chris
>
> Mandy
>
>
> On 10/18/2012 2:43 PM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twi
http://cr.openjdk.java.net/~twisti/6771058
6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp
Reviewed-by:
This test can fail if finalizer of Basic is not called for some
reason. It happens in compiled mode if compilation is more slow than
execution of the main loop.
The f
re already in HS24.
-- Chris
>
> David
>
> On 17/10/2012 5:54 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8000999
>>
>> 8000999: backport of JSR 292 to 7u
>> Reviewed-by:
>>
>> This is an umbrella bug for these changes (
effort to a minimum when we back port future performance work.
-- Chris
>
> Or even add a package-private InternalError class that subclasses
> java.lang.InternalError to add the new constructors? (for 7u)
>
> David
>
>
> On 17/10/2012 4:01 AM, Christian
http://cr.openjdk.java.net/~twisti/8000999
8000999: backport of JSR 292 to 7u
Reviewed-by:
This is an umbrella bug for these changes (which are backported in one
changeset):
6983728: JSR 292 remove argument count limitations
7128512: Javadoc typo in java.lang.invoke.MethodHandle
7117167: Misc
at 11:01 AM, Christian Thalinger wrote:
>
>> http://cr.openjdk.java.net/~twisti/8000989
>>
>> 8000989: smaller code changes to make future JSR 292 backports easier
>> Reviewed-by:
>>
>> In 8 we added two new constructors to InternalError which we use in
>>
http://cr.openjdk.java.net/~twisti/8000989
8000989: smaller code changes to make future JSR 292 backports easier
Reviewed-by:
In 8 we added two new constructors to InternalError which we use in
292. Factor InternalError generation to a method to make future
backports to 7u easier.
src/share/cla
On Sep 19, 2011, at 11:58 PM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7030453/webrev.00
src/share/classes/java/lang/ClassValue.java:
233 /** Value stream for for hashCodeForCache. See similar structure in
ThreadLocal. */
Two for's.
578 * from the ehad of a non-null
While testing one of my changes with CompileTheWorld I hit a problem:
CompileTheWorld (1411) : com/sun/java/swing/plaf/motif/
MotifInternalFrameTitlePane$Title
=
=
=
=
=
=
Unexpected Error
---
On Mon, 2009-12-14 at 10:16 -0800, Joseph D. Darcy wrote:
> > Not a review, but did you think about implementing the whole FDLIBM in
> > Java, as done here:
> >
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001970.html
> >
>
> Yes, porting FDLIBM to Java has been an oft-del
On Mon, 2009-12-14 at 01:31 -0800, Joseph D. Darcy wrote:
> Hello.
>
> Please review my fix for
>
> 6908131 Pure Java implementations of StrictMath.floor(double)
> &StrictMath.ceil(double)
> http://cr.openjdk.java.net/~darcy/6908131.0/
>
> I've asked Doug Priest, one of Sun's numerical experts,
On Wed, 2009-10-28 at 22:44 +0100, Ulf Zibis wrote:
> Hi Christian,
>
> for a benchmark test I have replaced all sun.nio.cs.Surrogate methods in
> sun.nio.cs.ext.EUC_TW with corresponding ones from java.lang.Character.
>
> As result, the overall encoding performance was 10 % worse, so
> java.la
On Sat, 2009-10-03 at 23:43 -0500, Paul Benedict wrote:
> I've always found it a bit perplexing that java.lang was never chosen
> for the parent package of the Dynamic API. Why is that? Dynamic types
> are now "part of the language" as proven by spec itself and exotic
> identifiers. Will this be re
Tom Hawtin wrote:
> Janda Martin wrote:
>> I would like to ask about any plans of speed improvements to
>> "System.identityHashCode" or "IdentityHashMap"
>>
>> I use EclipseLink and it uses IdentityHashMap for storing entities and their
>> clones.
>>
>> In my case System.identityHashCode consumes
gustav trede wrote:
> Hello,
You should better ask these questions on hotspot-dev.
-- Christian
1 - 100 of 110 matches
Mail list logo
