Re: [10] RFR: 8182487: Add Unsafe.objectFieldOffset(Class, String)

> 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: > >

Re: [9] RFR: 8152207: Perform array bound checks while getting a length of bytecode instructions

> 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

Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 1:22 PM, Aleksey Shipilev <aleksey.shipi...@oracle.com> > wrote: > > On 02/20/2016 01:40 AM, Christian Thalinger wrote: >>> On Feb 19, 2016, at 9:03 AM, John Rose <john.r.r...@oracle.com> wrote: >>> On Feb 19, 2016, at 9:57 AM,

Re: RFR (S) 8150180: String.value contents should be trusted

> On Feb 19, 2016, at 9:03 AM, John Rose <john.r.r...@oracle.com> wrote: > > On Feb 19, 2016, at 9:57 AM, Christian Thalinger > <christian.thalin...@oracle.com <mailto:christian.thalin...@oracle.com>> > wrote: >> >> Why don’t you change the valu

Re: RFR (S) 8150180: String.value contents should be trusted

> 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

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

/8141615/jdk/webrev.04/ > > -Konstantin > > On 12/15/2015 08:36 PM, Christian Thalinger wrote: >> >>> On Dec 14, 2015, at 11:11 PM, Konstantin Shefov >>> <konstantin.she...@oracle.com <mailto:konstantin.she...@oracle.com>> wrote: >>> &

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

/jdk/vm/ci/sparc/SPARCKind.java#l27> 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 A

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

hods also. >>>>> >>>>> -Konstantin >>>>> >>>>> On 11/18/2015 12:04 AM, Remi Forax wrote: >>>>>> Hi Konstantin, >>>>>> Technically, getInvokedynamicRefInfoAt should be >>>>>> getNameAndTyp

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

PI, I think it's better 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 &

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

[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[]

Re: 8139891: Prepare Unsafe for true encapsulation

> 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

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

> 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

Re: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries

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

Re: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586

On Feb 4, 2015, at 3:31 AM, Daniel Fuchs daniel.fu...@oracle.com 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

Re: RFR - 8072450: 9-dev build failed on elinux-i586 and rlinux-i586

On Feb 4, 2015, at 9:44 AM, Daniel Fuchs daniel.fu...@oracle.com 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 directly; we have a compiler-dependent macro

Re: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

On Nov 3, 2014, at 12:41 PM, David Chase david.r.ch...@oracle.com wrote: On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com 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

Re: RFR 8047737 Move array component mirror to instance of java/lang/Class

On Jun 30, 2014, at 1:06 PM, Coleen Phillimore coleen.phillim...@oracle.com 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 // prevents

Re: RFR 8047737 Move array component mirror to instance of java/lang/Class

On Jun 30, 2014, at 5:50 PM, Coleen Phillimore coleen.phillim...@oracle.com 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 // prevents

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache

On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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.

RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused

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:

Re: RFR (XS): 8032606: ClassValue.ClassValueMap.type is unused

Thanks, John and Vladimir. On May 15, 2014, at 2:46 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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.net/~twisti

Re: [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache

. This allows only one thread to set the LambdaForm that is then being used by all instances of the invokeExact. *Testing* - Failing test (vm/mlvm/meth/stress/jni/nativeAndMH) - Nashorn + Octane - JPRT Many thanks to Christian Thalinger and Vladimir Ivanov! Best, Tobias [1] Call sequence

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Apr 3, 2014, at 9:44 PM, John Rose john.r.r...@oracle.com wrote: On Apr 3, 2014, at 6:33 PM, Christian Thalinger christian.thalin...@oracle.com 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

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

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,Wrapper.INT), + J_TYPE('J', long.class, Wrapper.LONG), + F_TYPE('F

Re: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles

On Mar 24, 2014, at 1:33 PM, Igor Ignatyev igor.ignat...@oracle.com 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

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

+ 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,

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Mar 14, 2014, at 4:28 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Mar 18, 2014, at 2:35 PM, John Rose john.r.r...@oracle.com wrote: On Mar 18, 2014, at 1:36 PM, Christian Thalinger christian.thalin...@oracle.com 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

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

, 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 { On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov vladimir.x.iva

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

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 vladimir.x.iva...@oracle.com wrote:

Re: RFR (S): 8033666: Make sure @ForceInline is everywhere it needs to be in sun.misc and java.lang.invoke

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,U T castReference(Class? extends T t, U x) { + // inlined Class.cast because we can't ForceInline it + if (x != null

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

Re: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585

Looks good. On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

Re: [8] RFR (XS): 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package

Looks good. On Jan 27, 2014, at 8:05 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

[9] RFR (XXS): 8031043: ClassValue's backing map should have a smaller initial size

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

Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

[I’m resending something I sent earlier today to Vladimir directly.] On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031502 InvokeBytecodeGenerator can produce

Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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 Vladimir

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 (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector

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

Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector

as posted. — John I'm fine with that. On Oct 4, 2013, at 11:34 AM, John Rose john.r.r...@oracle.com 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, Christian Thalinger christian.thalin...@oracle.com wrote: You

Re: RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members

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 john.r.r...@oracle.com wrote: On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: John, I don't see

Re: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity

Thank you for doing this; it is much clearer now. Looks good. On Oct 1, 2013, at 10:19 PM, John Rose john.r.r...@oracle.com 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.,

Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector

On Sep 20, 2013, at 5:09 PM, John Rose john.r.r...@oracle.com wrote: On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 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

Re: RFR (M): 8024635: Caching MethodType's descriptor string improves lambda linkage performance

Looks good. On Sep 27, 2013, at 5:39 AM, Sergey Kuksenko sergey.kukse...@oracle.com 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

Re: RFR (S): 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()

On Sep 26, 2013, at 1:22 AM, Peter Levart peter.lev...@gmail.com 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: This is a race in MemberName's

Re: RFR: Caching MethodType's descriptor string improves lambda linkage performance

On Sep 26, 2013, at 9:22 AM, Sergey Kuksenko sergey.kukse...@oracle.com 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:

Re: RFR (S): 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()

On Sep 26, 2013, at 11:50 AM, Christian Thalinger christian.thalin...@oracle.com wrote: On Sep 26, 2013, at 1:22 AM, Peter Levart peter.lev...@gmail.com wrote: On 09/26/2013 01:27 AM, Christian Thalinger wrote: http://cr.openjdk.java.net/~twisti/8019192/webrev/ 8019192

Re: RFR (S): 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()

On Sep 26, 2013, at 2:28 PM, John Rose john.r.r...@oracle.com wrote: On Sep 26, 2013, at 1:13 PM, Christian Thalinger christian.thalin...@oracle.com wrote: On Sep 26, 2013, at 11:50 AM, Christian Thalinger christian.thalin...@oracle.com wrote: On Sep 26, 2013, at 1:22 AM, Peter

Re: RFR (S): 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()

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 christian.thalin...@oracle.com wrote

Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError

necessary to get the error, so it is not only shell-free, it can also be run outside jtreg. On 2013-09-12, at 2:34 PM, Christian Thalinger christian.thalin...@oracle.com wrote: On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com wrote: New webrev, commented line removed

Re: RFR (S) 8001108: an attempt to use init as a method name should elicit NoSuchMethodException

On Sep 19, 2013, at 2:31 PM, John Rose john.r.r...@oracle.com wrote: On Sep 18, 2013, at 5:05 PM, Christian Thalinger christian.thalin...@oracle.com wrote: src/share/classes/java/lang/invoke/MethodHandles.java: + * methods as if they were normal methods, but the JVM verifier

RFR (S): 8019192: StringIndexOutOfBoundsException: in Class.getSimpleName()

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

Re: RFR (S) 8001108: an attempt to use init as a method name should elicit NoSuchMethodException

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. + * em(Note: JVM internal methods named {@code init} not visible to this API, + * even

Re: RFR (S) 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException

Looks good. On Sep 12, 2013, at 6:02 PM, John Rose john.r.r...@oracle.com 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

Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError

+ // err.initCause(ex); Why is this commented? -- Chris On Sep 6, 2013, at 4:59 PM, David Chase david.r.ch...@oracle.com 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

Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError

exceptions 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 christian.thalin...@oracle.com wrote: + // err.initCause(ex); Why is this commented? -- Chris

Re: RFR (S) 8019417: JSR 292 javadoc should clarify method handle arity limits

On Sep 12, 2013, at 4:34 PM, John Rose john.r.r...@oracle.com 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

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 !

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 !

Re: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability

On Jun 11, 2013, at 7:16 PM, Christian Thalinger christian.thalin...@oracle.com wrote: On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 06/11/2013 10:24 PM, Christian Thalinger wrote: On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev aleksey.shipi

Re: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability

On Jun 13, 2013, at 12:09 PM, Aleksey Shipilev aleksey.shipi...@oracle.com 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: [unchecked] unchecked

Re: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability

On Jun 11, 2013, at 1:47 AM, Aleksey Shipilev aleksey.shipi...@oracle.com 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-threaded

Re: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability

On Jun 11, 2013, at 9:03 AM, Aleksey Shipilev aleksey.shipi...@oracle.com 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 kind

Re: RFR (S) CR 7177472: JSR292: MethodType interning penalizes scalability

On Jun 11, 2013, at 2:21 PM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 06/11/2013 10:24 PM, Christian Thalinger wrote: On Jun 11, 2013, at 9:08 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 06/11/2013 08:06 PM, Christian Thalinger wrote: Anyway, let's push

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 27, 2013, at 8:01 PM, Mandy Chung mandy.ch...@oracle.com 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 mandy.ch...@oracle.com wrote

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 27, 2013, at 10:35 AM, Mandy Chung mandy.ch...@oracle.com 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:

Re: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 19, 2013, at 6:02 PM, Christian Thalinger christian.thalin...@oracle.com wrote: On Mar 19, 2013, at 5:21 PM, John Rose john.r.r...@oracle.com wrote: On Mar 14, 2013, at 8:31 PM, Christian Thalinger christian.thalin...@oracle.com wrote: [This is the HotSpot part of JEP 176

Re: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK

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 for the review! -- Chris Mandy On 3/14/13 8:31 PM, Christian Thalinger wrote: [This is the HotSpot part of JEP 176

Re: RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 19, 2013, at 5:21 PM, John Rose john.r.r...@oracle.com wrote: On Mar 14, 2013, at 8:31 PM, Christian Thalinger christian.thalin...@oracle.com wrote: [This is the HotSpot part of JEP 176] http://cr.openjdk.java.net/~twisti/7198429 7198429: need checked categorization of caller

RFR (M): 7198429: need checked categorization of caller-sensitive methods in the JDK

[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

Re: Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

On Feb 8, 2013, at 10:38 AM, Krystal Mo krystal...@oracle.com 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

Re: Request for review: 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86

On Jan 11, 2013, at 10:19 AM, Ulf Zibis ulf.zi...@cosoco.de 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

Re: Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message

On Nov 30, 2012, at 10:48 AM, Krystal Mo krystal...@oracle.com 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:

RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp

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

Re: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp

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/~twisti/6771058 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp

Re: RFR (S): 8000999: backport of JSR 292 to 7u

are 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 (which are backported in one changeset): 6983728: JSR 292

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

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

crash in Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl on solaris-sparcv9

While testing one of my changes with CompileTheWorld I hit a problem: CompileTheWorld (1411) : com/sun/java/swing/plaf/motif/ MotifInternalFrameTitlePane$Title = = = = = = Unexpected Error

Re: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) StrictMath.ceil(double)

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, to

Re: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) StrictMath.ceil(double)

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-delayed nice

Re: Character.java methods are slower than Surrogate.java's

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

Re: JSR-292: Why not java.lang.dyn?

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: Math trig intrinsics and compiler options

gustav trede wrote: Hello, You should better ask these questions on hotspot-dev. -- Christian

Re: Rewrite of IBM doublebyte charsets

On Sun, 2009-05-17 at 22:11 +0200, Ulf Zibis wrote: it is not faster than the existing one, actually my not that accurate benchmark shows it is slower... Maybe XOR is not covered by Bug ID 6797305 ... Christian Thalinger? No, it's not covered. There is not really a possible performance

BigInteger and MutableBigInteger should use Integer bit-twiddling methods

Hi! Could someone take care about CR 6832035? -- Christian

Re: review request for 6622432

On Mon, 2009-02-16 at 14:33 -0800, Xiaobin Lu wrote: Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ 6622432: RFE: Performance improvements to java.math.BigDecimal snip As you know, the division operation is expensive and the algorithm to compare with the ten's power array

inefficient Des3DkCrypto/DigestMD5Base.setParityBit()

Hi! While looking at the bitCount() thing I mentioned in the other thread, I noticed that Des3DkCrypto and DigestMD5Base are using a very inefficient implementation of setParityBit(). The one from DESKeyGenerator is much better and uses Integer.bitCount(), which could benefit from a

Re: inefficient Des3DkCrypto/DigestMD5Base.setParityBit()

On Tue, 2009-02-17 at 15:18 +, Alan Bateman wrote: Christian Thalinger wrote: Hi! While looking at the bitCount() thing I mentioned in the other thread, I noticed that Des3DkCrypto and DigestMD5Base are using a very inefficient implementation of setParityBit(). The one from