Re: More memory-efficient internal representation for Strings: call for more data

irection > altogether? .NET for example stores the bytes inline with the instance. > > Sent from my phone > > On Dec 2, 2014 4:59 PM, "Aleksey Shipilev" <mailto:aleksey.shipi...@oracle.com>> wrote: > > Hi, > > As you may already know, we are looki

More memory-efficient internal representation for Strings: call for more data

Hi, As you may already know, we are looking into more memory efficient representation for Strings: https://bugs.openjdk.java.net/browse/JDK-8054307 As part of preliminary performance work for this JEP, we have to collect the empirical data on usual characteristics of Strings and char[]-s normal

Re: RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

Hi Martin, On 11/24/2014 11:56 PM, Martin Buchholz wrote: > Review carefully - I am trying to learn about fences by explaining them! > I have borrowed some wording from my reviewers! > > https://bugs.openjdk.java.net/browse/JDK-8065804 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-i

Re: [9, 8u40] RFR (M): 8063135: Enable full LF sharing by default

Looks good now. -Aleksey. On 11/19/2014 01:30 PM, Vladimir Ivanov wrote: > Hm, I remember I fixed that long time ago... Seems like I chose a stale > patch. Sorry for that. Updated webrev in place. > > Best regards, > Vladimir Ivanov > > On 11/19/14, 3:38 AM, Aleksey Shipil

Re: RFR: 8065138 - Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8'

On 11/19/2014 02:17 PM, Daniel Fuchs wrote: > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8065138/webrev.00/ Looks good. (not a Reviewer) > The root of the issue is with > jaxp/src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties > > It contains a spe

Re: [9, 8u40] RFR (M): 8063135: Enable full LF sharing by default

On 11/18/2014 11:23 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8063135/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8063135 Broken array index here: 69 TRACE_METHOD_LINKAGE = (Boolean) values[3]; 70 COMPILE_THRESHOLD = (Integer) value

Re: [9, 8u40] RFR (XXS): 8059880: Get rid of LambdaForm interpretation

On 11/19/2014 12:01 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8059880/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059880 Yes, for the love of God, GO FOR IT. -Aleksey.

Re: RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

er of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> > Sent from my iPad > > On Nov 17, 2014, at 5:35 AM, Aleksey Shipilev > mailto:aleksey.shipi...@or

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 11/17/2014 03:23 PM, Claes Redestad wrote: > > On 2014-11-17 12:54, Aleksey Shipilev wrote: >>> Perhaps rewriting to something like this would make the code >>> cleaner: >>> >>>index(s, m.start(1), m.end(1)); >&

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 11/17/2014 02:49 PM, Claes Redestad wrote: > On 2014-11-17 11:45, Aleksey Shipilev wrote: >> On 11/17/2014 02:09 AM, Claes Redestad wrote: >>> http://cr.openjdk.java.net/~redestad/8065070/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8065070 >> (Not

Re: RFR: 8064846: Lazy-init thread safety problems in core reflection

On 11/15/2014 12:38 AM, Martin Buchholz wrote: > I've implemented your suggestions and regenerated the webrev. Looks good, thanks! -Aleksey.

Re: RFR (S): 8065070: (fmt) Avoid creating substrings when building FormatSpecifier

On 11/17/2014 02:09 AM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8065070/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8065070 (Not a Reviewer) The change looks very sane given the capture ranges are already available in Matcher. I wonder if you want to cache m.start() a

RFR (XS) 8065096: java.net.Authenticator.theAuthenticator should be properly synchronized

Hi, Please review and commit this trivial change: http://cr.openjdk.java.net/~shade/8065096/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8065096 "volatile" should nominally fix the the data race on theAuthenticator field. Thanks, -Aleksey.

Re: Inconsistent access/ synchronization on Authenticator.theAuthenticator

On 11/17/2014 12:56 PM, Dawid Weiss wrote: > This is very minor, but java.net.Authenticator has the following > static field for the default authenticator: > > private static Authenticator theAuthenticator; > > This field is set from a synchronized method setDefault(..), but > accessed withou

Re: AnnotationInvocationHandler - null check for hashCode / equals / toString computation?

On 11/17/2014 12:52 PM, Aleksey Shipilev wrote: > Like Rafael, I wonder if we can/should throw the > IncompleteAnnotationException when accessing the annotation member > implicitly with equals(), not with the named accessor. This should be "*as well as explicitly* with the

Re: AnnotationInvocationHandler - null check for hashCode / equals / toString computation?

Hi Joe, I am missing something. Of course, JLS requires the reference types members of annotations to be non-null. But IncompleteAnnotationEx is here to cover the case when the annotation is mis-constructed. Therefore, I think the original Rafael's question is still unanswered. I can see how the

Re: RFR: 8064846: Lazy-init thread safety problems in core reflection

Hi Martin, On 11/14/2014 03:03 AM, Martin Buchholz wrote: > I'd like you to do a code review. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-volatile/ > https://bugs.openjdk.java.net/browse/JDK-8064846 Looks good and sane, thanks for taking care of it. Not a big fan of

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

On 11.11.2014 17:40, Aleksey Shipilev wrote: > On 11/09/2014 09:45 PM, Aleksey Shipilev wrote: >> Thread.getName() returns String, and does new String instantiation every >> time, because the thread name is stored in char[]. Even though we use a >> private String constructor

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Hi David, On 12.11.2014 07:48, David Holmes wrote: > On 12/11/2014 12:40 AM, Aleksey Shipilev wrote: > All looks good to me. Thanks for the review! > But I also noticed this strange (to me) assertion in javaClasses.cpp > > void java_lang_Thread::set_name(oop java_t

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Thanks Staffan! -Aleksey. On 11.11.2014 23:38, Staffan Larsen wrote: > SA changes look good. > > /Staffan > >> On 11 nov 2014, at 15:40, Aleksey Shipilev >> wrote: >> >> Hi, >> >> On 11/09/2014 09:45 PM, Aleksey Shipilev wrote: >>

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

On 11/11/2014 07:10 PM, Chris Hegarty wrote: > On 11 Nov 2014, at 14:40, Aleksey Shipilev > wrote: >> Updated webrevs: >> http://cr.openjdk.java.net/~shade/8059677/webrev.02.jdk/ > > Looks good. > >> http://cr.openjdk.java.net/~shade/8059677/webrev.02.hs/ &

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Hi, On 11/09/2014 09:45 PM, Aleksey Shipilev wrote: > Thread.getName() returns String, and does new String instantiation every > time, because the thread name is stored in char[]. Even though we use a > private String constructor that shares the char[] array without copying > it, this

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Hi David, Updated webrevs will follow after I respin the tests. Meanwhile, some comments below: On 11.11.2014 10:06, David Holmes wrote: > On 11/11/2014 12:19 AM, Aleksey Shipilev wrote: >> Then I speculated that having char[] name would help VM initialize the >> name if we want

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Staffan > > >> On 10 nov 2014, at 19:09, Aleksey Shipilev >> mailto:aleksey.shipi...@oracle.com>> wrote: >> >> On 10.11.2014 19:39, Staffan Larsen wrote: >>>> On 10 nov 2014, at 15:55, Aleksey Shipilev >>>> mailto:aleksey.shipi...@orac

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

On 10.11.2014 19:39, Staffan Larsen wrote: >> On 10 nov 2014, at 15:55, Aleksey Shipilev >> wrote: >> Ow, it seems very like it. >> So, what testlist have I missed to catch this? > > Probably vm.tmtools.testlist and/or nsk.sajdi.testlist. Just a warning that >

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

On 11/10/2014 06:13 PM, roger riggs wrote: > On 11/10/2014 9:54 AM, Aleksey Shipilev wrote: >> Again, I don't quite understand. Is it about storing the reference to >> String as the thread name, that can potentially be used for external >> synchronization? >> >&

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

fan > >> On 10 nov 2014, at 15:19, Aleksey Shipilev >> wrote: >> >> Hi David, Chris, >> >> On 11/10/2014 04:53 PM, Chris Hegarty wrote: >>> On 10/11/14 12:56, David Holmes wrote: >>>> On 10/11/2014 9:52 PM, Chris Hegarty wrote: >&g

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Hi Roger, On 11/10/2014 05:31 PM, roger riggs wrote: > 1) The Thread class javadoc says: > " Unless otherwise noted, passing a {@code null} argument to a constructor > * or method in this class will cause a {@link NullPointerException} to be > * thrown." > > So, NPE is already specified for set

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Hi David, Chris, On 11/10/2014 04:53 PM, Chris Hegarty wrote: > On 10/11/14 12:56, David Holmes wrote: >> On 10/11/2014 9:52 PM, Chris Hegarty wrote: >>> I have only looked at the libraries changes, and I think they make sense >>> . As in, I can find no reason why the name cannot be changed to be

Re: RFR (S) 8059677: Thread.getName() instantiates Strings

Hi Chris, Thanks for taking a look! On 11/10/2014 02:52 PM, Chris Hegarty wrote: > Trivially, after your changes will NPE be thrown if setName(null), as it > is today ? There is no way it could throw NPE now, therefore the behavior is different. The spec says nothing about NPE though, but it fee

RFR (S) 8059677: Thread.getName() instantiates Strings

Hi, Thread.getName() returns String, and does new String instantiation every time, because the thread name is stored in char[]. Even though we use a private String constructor that shares the char[] array without copying it, this still hurts some use cases (think extra-fast logging). To the extent

Re: RFR 8062180: MethodHandleImpl.makeArrays throws and swallows java.lang.NoSuchFieldError in normal flow

On 11/05/2014 12:23 PM, Claes Redestad wrote: > On 2014-11-04 22:25, Aleksey Shipilev wrote: >> On 04.11.2014 23:57, Claes Redestad wrote: >> - Would we be better off asserting (mh == null) instead of breaking and >> asserting afterwards? > > assert(mh != null)

Re: RFR 8062180: MethodHandleImpl.makeArrays throws and swallows java.lang.NoSuchFieldError in normal flow

Hi Claes, On 04.11.2014 23:57, Claes Redestad wrote: > please review this minor improvement to the initialization of > MethodHandleImpl$Lazy. Running any code which initializes > MethodHandlesImpl$Lazy will trigger throwing of > java.lang.NoSuchFieldErrors, which has a measurable impact on startup

Re: RFR: 8062771: Core reflection should use final fields whenever possible

Hi Martin, On 04.11.2014 23:11, Martin Buchholz wrote: > On Tue, Nov 4, 2014 at 11:55 AM, Aleksey Shipilev > wrote: >> On 04.11.2014 20:53, Martin Buchholz wrote: >>> On Tue, Nov 4, 2014 at 2:13 AM, Paul Sandoz wrote: >>>> On Nov 3, 2014, at 11:18 PM, Martin B

Re: RFR: 8062771: Core reflection should use final fields whenever possible

On 04.11.2014 20:53, Martin Buchholz wrote: > On Tue, Nov 4, 2014 at 2:13 AM, Paul Sandoz wrote: >> On Nov 3, 2014, at 11:18 PM, Martin Buchholz wrote: >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/reflection-final-fields/ >>> https://bugs.openjdk.java.net/browse/JDK-8062771 Looks good

Re: Loading classes with many methods is very expensive

Guys, can you please start a new RFR thread for Peter's change? You have a bug ID now, and the discussion should be searchable by bug ID. Also, you are spamming two aliases (corelibs + hotspot-runtime) instead of one ;) -Aleksey. On 10/30/2014 12:43 PM, Peter Levart wrote: > On 10/30/2014 10:29

Re: java.util.Optional: a better implementation?

On 29.10.2014 15:25, David Holmes wrote: > On 29/10/2014 10:06 PM, nicar...@gmail.com wrote: >> The JVM probably optimizes and throws away the null checks yielding in >> equal performance compared to the proposed implementation (above) ---I >> haven't done any performance tests, but why wait fo

Re: Loading classes with many methods is very expensive

On 27.10.2014 22:01, Martin Buchholz wrote: > I'm having trouble keeping up with this thread I started, but I did > update the test/benchmark > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Class.getMethods-benchmark/ >

Re: Loading classes with many methods is very expensive

Hi Peter, On 10/27/2014 03:45 PM, Peter Levart wrote: > I merged the functionality of the method-signature-key with the > linked-list node, holding just a reference to Method object and a link > to 'next' node. I think this is the most compact temporary datastructure > representation for that purp

Re: Loading classes with many methods is very expensive

On 10/27/2014 01:53 AM, Peter Levart wrote: > As you might have noticed, the number of methods obtained from patched > code differed from original code. I have investigated this and found > that original code treats abstract class methods the same as abstract > interface methods as far as multiple

Re: Loading classes with many methods is very expensive

Hi Martin, On 23.10.2014 02:53, Martin Buchholz wrote: > If you have a class with ~64k methods with a superclass that also has ~64k > methods, class loading that single class will cost you ~30sec and calling > Class.getMethods another ~10sec. Both are unacceptably slow. I think both > are due to

Re: RFR (JAXP): 8061686: Size limits in BufferAllocator should have been final

On 21.10.2014 23:09, huizhe wang wrote: > http://cr.openjdk.java.net/~joehw/jdk9/8061686/webrev/ +1 (not a Reviewer) -Aleksey

Re: RFR (XS) 8060485: (str) contentEquals checks the String contents twice on mismatch

On 14.10.2014 21:55, Alan Bateman wrote: > On 14/10/2014 18:38, Aleksey Shipilev wrote: >> Thanks guys! >> >> And of course, I managed to do two minor mistakes in a two-line change: >> the indentation is a bit wrong, and cast to String is redundant. Here is >> the

Re: RFR (XS) 8060485: (str) contentEquals checks the String contents twice on mismatch

On 14.10.2014 19:32, Stanimir Simeonoff wrote: > Hi, > > This is an unrelated issue, yet is there any reason for the inner loop > of equals to be written in such a (confusing) way? > > if (n == anotherString.value.length) { > char v1[] = value; > char v

Re: RFR (XS) 8060485: (str) contentEquals checks the String contents twice on mismatch

/~shade/8060485/8060485.changeset -Aleksey. On 14.10.2014 19:13, Chris Hegarty wrote: > On 14 Oct 2014, at 17:33, Martin Buchholz wrote: > >> Looks good to me! > > +1 'noreg-hard' > > -Chris. > >> On Tue, Oct 14, 2014 at 9:05 AM, Aleksey Shipi

RFR (XS) 8060485: (str) contentEquals checks the String contents twice on mismatch

Hi, Please review a trivial change in String.contentEquals: https://bugs.openjdk.java.net/browse/JDK-8060485 http://cr.openjdk.java.net/~shade/8060485/webrev.00/ It improves the performance drastically: http://cr.openjdk.java.net/~shade/8060485/perf.txt ...not to mention it improves the co

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

On 10/02/2014 09:26 PM, Vladimir Ivanov wrote: > Aleksey, > > Thanks for the review. > Updated version: > http://cr.openjdk.java.net/~vlivanov/8058892/webrev.02/ Looks good. >> * Since initialization order is important, why don't put the >> initialization in the existing static initializer? This

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

I have three comments: * Since initialization order is important, why don't put the initialization in the existing static initializer? This will secure for inadvertent field reordering in future. * Any reason two new fields are "private"? All other seem package-private. * Any performance problem

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

On 09/25/2014 11:40 AM, Aleksey Shipilev wrote: >> This is for HotSpot compiler guys to answer. Theoretically I think it is >> possible. But it would have to be tailored to the very specific use case >> and I don't know if such specific transformation would have wide-enough

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

Hi Peter, On 09/25/2014 02:46 AM, Peter Levart wrote: >>> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java Interesting. I have to say it once again: a) It is *an error* to use static finals as the benchmark input. They are perfectly constant-foldable in way too many cases. Bre

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

Thanks Martin! -Aleksey. On 09/24/2014 08:56 PM, Martin Buchholz wrote: > I pushed Aleksey's change to jdk9-dev. > > If it was up to me, I would give Aleksey all the commit/review bits I had... > > On Wed, Sep 24, 2014 at 4:09 AM, Aleksey Shipilev > mailto:aleksey.ship

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

Hi again, Friendly reminder: please sponsor this trivial change. :) -Aleksey. On 09/22/2014 06:29 PM, Aleksey Shipilev wrote: > Fixed: > http://cr.openjdk.java.net/~shade/8058643/webrev.02/ > http://cr.openjdk.java.net/~shade/8058643/8058643.changeset > > Since there is no per

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

On 09/23/2014 07:12 PM, Brian Burkhalter wrote: >> Ah, sorry for confusing language about "compile-time constants", I meant >> "compile-time constant expression", as per JLS 15.28. Constant >> expressions are FP-strict, so it should be just fine correctness- and >> performance-wise, and less crypti

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian, On 09/23/2014 02:34 AM, Brian Burkhalter wrote: > I created an alternate webrev using compile-time constants per your > suggestion: > > http://cr.openjdk.java.net/~bpb/4477961/webrev.01/ > Ah, sorry for confusing language about "co

Re: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be optimized

Hi Brian, Looks OK. On 09/23/2014 01:10 AM, Brian Burkhalter wrote: > Summary: Change constructs like “a * B / C” and “u / V * W” to “x * > (Y / Z)” where lower case denotes a variable and upper case a > constant. This forces the constant value (Y / Z) to be evaluated only > once per VM instance,

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

On 09/22/2014 06:13 PM, Aleksey Shipilev wrote: > On 09/22/2014 06:06 PM, Aleksey Shipilev wrote: >> Hi again, >> >> On 09/17/2014 06:28 PM, Aleksey Shipilev wrote: >>> Can I have a review and a sponsorship for this tiny readability cleanup >>> in String.hash

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

On 09/22/2014 06:06 PM, Aleksey Shipilev wrote: > Hi again, > > On 09/17/2014 06:28 PM, Aleksey Shipilev wrote: >> Can I have a review and a sponsorship for this tiny readability cleanup >> in String.hashCode()? >> http://cr.openjdk.java.net/~shade/8

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

Hi again, On 09/17/2014 06:28 PM, Aleksey Shipilev wrote: > Can I have a review and a sponsorship for this tiny readability cleanup > in String.hashCode()? > http://cr.openjdk.java.net/~shade/8058643/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8058643 I think we have en

Re: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization checks scale devastatingly poorly

On 09/17/2014 10:53 PM, Remi Forax wrote: > > On 09/17/2014 06:55 PM, Vladimir Ivanov wrote: >> >> It's not specific to U.dAC(). Regular class loaders can hit similar problem as well. >>> >>> Even better, this is even more generic. >> Please, update bug synopsis then. >> If you want to u

Re: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization checks scale devastatingly poorly

On 09/17/2014 08:55 PM, Vladimir Ivanov wrote: >>> It's not specific to U.dAC(). Regular class loaders can hit similar >>> problem as well. >> >> Even better, this is even more generic. > Please, update bug synopsis then. Thanks, did so. Also reassigned the bug, and lowered the priority. > Done:

Re: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization checks scale devastatingly poorly

On 09/17/2014 08:43 PM, Vladimir Ivanov wrote: > I don't see anything obviously wrong either with U.dAC() or with > dependency tracking in VM. What we stumbled upon is an inherent > limitation of current dependency tracking implementation. Yes, and so the question from John, which I need to follow

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

Hi Xueming, On 09/17/2014 08:13 PM, Xueming Shen wrote: > String.hashCode() has intrinsics, No, we have no intrinsics for String.hashCode. We do have a native implementation for VM internal purposes though, but it's irrelevant here. > so I don't think we are seeing the real performance "differe

Re: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

07:19 PM, Martin Buchholz wrote: > Looks good, but I would use this title: > > (str) Improve String.hashCode implementation > > On Wed, Sep 17, 2014 at 7:28 AM, Aleksey Shipilev > mailto:aleksey.shipi...@oracle.com>> wrote: > > Hi, > > Can I have a review

Re: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization checks scale devastatingly poorly

On 09/17/2014 07:02 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8058309/webrev.00/ Looks good, thanks! Sorry for not being clear earlier, but I am a bit concerned with the bug synopsis: we have sure worked around the issue with LambdaForms, but are we sure this fixed the gen

RFR (XS) CR 8058643: (str) Re-examine hashCode implementation

Hi, Can I have a review and a sponsorship for this tiny readability cleanup in String.hashCode()? http://cr.openjdk.java.net/~shade/8058643/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8058643 Thanks, -Aleksey.

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 09/10/2014 03:53 PM, Claes Redestad wrote: > Yes, this saves creating the type and wrapper object altogether, > while testing suggest it's only the getResource() == null cases we > commonly see hurting startup in our tests. I'd say let's go with your > patch. > New webrev: http://cr.openjdk.jav

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

I think lambda would not help much since target type is ambiguous (PrivilegedAction vs PrivilegedExceptionAction)? -Aleksey. On 09/10/2014 02:55 PM, Ivan Gerasimov wrote: > > If a lambda were used instead of an anonymous class, it would save us > one line of code :-) > > Sincerely yours, > Ivan

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 09/10/2014 02:11 PM, Claes Redestad wrote: > please review this simple patch to avoid raising PrivilegedActionExceptions > when failing to find a class in URLClassLoader. > > bug: https://bugs.openjdk.java.net/browse/JDK-8057936 > webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/

Re: [9] RFR (S) 8057654: Extract checks performed during MethodHandle construction into separate methods

On 09/05/2014 12:09 PM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8057654 Random style rant of the week, not particularly about this concrete patch. Can we please try to systematically use more readable/robust/secure

Re: Boolean valueOf instead of new Boolean

On 05/24/2014 06:34 PM, Otávio Gonçalves de Santana wrote: > The Boolean class has cache for true and false and using it, will save > memory and will faster than using create new instance of boolean. > Using JMH[1] with a code test[2] the result was: I agree Boolean.valueOf (whether explicit or im

Re: RFR JDK-8038178: Fix corrupt license header

On 04/16/2014 03:36 PM, David Holmes wrote: > On 16/04/2014 9:28 PM, Pavel Rappo wrote: >> P.S. Some may find this a little bit amusing. > > Indeed :) I'm guessing original code was > > private static final Unsafe U; Awww... Another thing to be cautious about when using Unsafe. -Aleksey.

Re: RFR: 8035284: (xs) Remove redundant null initialization

On 04/11/2014 11:22 PM, Mike Duigou wrote: > https://bugs.openjdk.java.net/browse/JDK-8035284 > http://cr.openjdk.java.net/~mduigou/JDK-8035284/0/webrev/ This! Thumbs up. > Redundant null initializations in other components/packages will be handled > in separate issues. I also remember seeing c

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

On 03/20/2014 11:06 AM, Peter Levart wrote: > I was thinking about last night, for question: "Why is this > double-checked non-volatile-then-volatile trick not any faster than pure > volatile variant even on ARM platform where volatile read should have > some penalty compared to normal read?", migh

Re: Unsafe: efficiently comparing two byte arrays

On 03/01/2014 02:29 AM, Martin Buchholz wrote: > Are word-size reads in ByteBuffer actually intrinsified? I could find no > evidence for that. Perhaps this is an important missing optimization for > hotspot to make? It is a missing optimization, and we will get to that: https://bugs.openjdk.jav

MutableCallSite.syncAll() (Re: RFR: Update code in java.lang to use new language features)

On 01/24/2014 06:45 PM, Paul Sandoz wrote: > I think the update to java.lang.invoke.MutableCallSite.java should be safe: > > public static void syncAll(MutableCallSite[] sites) { > if (sites.length == 0) return; > STORE_BARRIER.lazySet(0); > -for (int i = 0; i < sit

Re: JDK 8 RFC 4891331: BigInteger a.multiply(a) should use squaring code

I'm with Joe on this. I think we should keep all cases from regressing. Having that, the patch is not really acceptable if it is degrading the mag.length < 8 cases. -Aleksey. On 10/18/2013 03:52 AM, Brian Burkhalter wrote: > Hi Joe, > > Will do. > > Thanks, > > Brian > > On Oct 17, 2013, at 4

Re: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc

Hi Aleksej, On 10/13/2013 02:00 PM, Aleksej Efimov wrote: > The benchmark code: > @GenerateMicroBenchmark > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.MICROSECONDS) > public void testMethod(BlackHole bh) { > bh.consume( new XPathContext() ); > } Not ba

Re: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc

On 10/11/2013 11:57 PM, Alan Bateman wrote: > (this might be a question for Aleksey as ideally we should be > building up a suite a good micro benchmarks as we fix or improve > things). Working on it separately for some time now. It would help to have the benchmark for particular issue anyway. -A

Re: RFR: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc

On 10/11/2013 06:06 PM, Aleksej Efimov wrote: > I don't think we need a regression test for it, but we need to make sure > the regression is gone. In attempt to prove it, I have done two simple > hprof run [2] on a test app [3] that creates 10 instances of > XPathContext in a cycle. While I a

Re: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks

On 10/09/2013 12:05 AM, Brian Burkhalter wrote: > Based on previous comments by Aleksey and Paul I created this test > > http://cr.openjdk.java.net/~bpb/7189139/PrimeTest.java > > and ran it with the list of primes supplied by Aleksey, N=6000, and > certainty=100. This is the output: > > --

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

On 10/08/2013 12:36 AM, Peter Levart wrote: >> That said, this is a 13 year old issue that hasn't come up very often >> (to my knowledge anyway, perhaps because those making heavy use of >> direct buffers are pooling buffers rather than allocating and >> unreferencing). In additional we are close t

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

Hi Peter, On 10/07/2013 02:56 AM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk8-tl/DyrectBufferAlloc/webrev.01/ The 1 hour run of this on my 1x2x2 i5, directMem=16m, original DirectByteBufferTest yields no failures! Oh my. Good job! Comments on the code: Bits.java: - Thread.cu

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

Hi Peter, On 10/04/2013 04:43 PM, Peter Levart wrote: > http://cr.openjdk.java.net/~plevart/jdk8-tl/Cleaners/webrev.02/ So you are taking on assisting the ReferenceHandler directly. Nice idea. I can only glimpse over the changes at this point... - You can't add the public methods to java.ref.*

Re: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks

On 10/04/2013 11:18 AM, Aleksey Shipilev wrote: > On 10/04/2013 03:34 AM, Brian Burkhalter wrote: >> Here is an alternative solution: http://cr.openjdk.java.net/~bpb/7189139.2/. > > Seems OK with me, as long as Miller-Rabin test tolerates the > lower-entropy PRNG. > >&g

Re: JDK 8 RFC 7189139 version 2: BigInteger's staticRandom field can be a source of bottlenecks

On 10/04/2013 03:34 AM, Brian Burkhalter wrote: > Here is an alternative solution: http://cr.openjdk.java.net/~bpb/7189139.2/. Seems OK with me, as long as Miller-Rabin test tolerates the lower-entropy PRNG. > If this seems reasonable, does anyone have suggestions as to testing? I would like to

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

On 10/03/2013 04:32 PM, Paul Sandoz wrote: > Alexsey, what do you observe if you revert back Cleaner to a > PhantomReference and retain QUEUE/CLEANERS but not > assistCleanupSlow? I observed the minuscule probability (my estimate is <0.1%) we hit the OOME with the original test. This is literally

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

On 10/02/2013 09:15 PM, Peter Levart wrote: > On 10/02/2013 06:31 PM, Alan Bateman wrote: >> One thing that I'd like to understand is the implication of moving >> from phantom to weak references. > > I think Cleaners as WeakReferences are not correct. > > Imagine the following code: > >

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

On 10/02/2013 08:31 PM, Alan Bateman wrote: > On 02/10/2013 07:43, Aleksey Shipilev wrote: >> http://cr.openjdk.java.net/~shade/6857566/webrev.00/ >> > I'd like to review, I just don't have time at the moment. Thanks Alan, we can wait. > One thing that I'd l

Re: RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

Hi Peter, On 10/02/2013 07:58 PM, Peter Levart wrote: > I briefly skimmed over the changes. If I understand them correctly, > they change they way Cleaners are processed. Without any assistance > from other threads, Cleaners (WeakReferences now) are 1st enqueued by > the ReferenceHandler thread, a

RFR (S) CR 6857566: (bf) DirectByteBuffer garbage creation can outpace reclamation

Hi, There is the issue that annoys me all the time: https://bugs.openjdk.java.net/browse/JDK-6857566 Please review the rework of DirectByteBuffer cleanup mechanics fixing that issue. Since DBB uses sun.misc.Cleaner as the infrastructure to clean up things, we focus there: http://cr.openjdk.ja

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

On 09/17/2013 04:41 AM, John Rose wrote: > But, please don't hand-inline methods (checkPtype, checkSlotCount). > That is usually the wrong answer. If there is a JIT inlining > decision that isn't going right, we need to fix that, not distort the > Java code. I thought this issue is one of those r

Re: RFR: 8024826: (s) : Remove alt-rt.jar, used by +AggressiveOps"

On 09/17/2013 04:16 AM, Mike Duigou wrote: > http://cr.openjdk.java.net/~mduigou/JDK-8024826/0/webrev/ I, for one who is responsible for eliminating the need for alt-rt.jar, greatly applaud this change. -Aleksey.

Re: RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed

On 09/16/2013 09:02 PM, Doug Lea wrote: > (This might stand as a record for the most expert attention > spent on the least important issue ever in JDK :-)! +1. -Aleksey.

Re: review request 7097386: Correct error in Predicate javadoc example

On 09/16/2013 03:12 PM, Lance Andersen - Oracle wrote: > Changes are at http://cr.openjdk.java.net/~lancea/7097386/webrev.01/ Thumbs up. -Aleksey.

Re: RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed

On 09/15/2013 08:32 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/tl/JDK-8024253-tlr-seed/webrev/ +1. -Aleksey.

Re: review request 7097386: Correct error in Predicate javadoc example

On 09/15/2013 10:38 PM, Lance Andersen - Oracle wrote: > I added a webrev > http://cr.openjdk.java.net/~lancea/7097386/webrev.00/ as it might be > a bit easier for this review. Notes: - change C-style "int v[]" declarations to Java-ish "int[] v". - catching SQLException should probably return

Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings

On 13.09.2013, at 0:49, Brian Burkhalter wrote: > I updated the webrev to include a comment for MAX_NDIGITS sans both hyperlink > and the foregoing verbiage: > > http://cr.openjdk.java.net/~bpb/8024356/ Thumbs up. -Aleksey

Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings

On 09/12/2013 09:17 AM, Dmitry Nadezhin wrote: > The patch is correct when decimal ULP of kept digits is pow(10,-1075) > of less. pow(2,53) has 17 decimal decimal digits. MAX_NDIGITS = 1100 > > 1075 + 17 . OK. That makes more sense. Can we please add the short comment in the code (maybe next time

Re: JDK 7u-dev review request 8024356: Double.parseDouble() is slow for long Strings

On 09/11/2013 12:58 AM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8024356 > Webrev: http://cr.openjdk.java.net/~bpb/8024356/ "MAX_NDIGITS = 1100" Stupid question. Why exactly this mag

Re: RFR: Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance

On 09/11/2013 08:53 PM, Sergey Kuksenko wrote: >> On 09/11/2013 08:23 PM, Sergey Kuksenko wrote: >>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/ >> >> * webrev metadata: "invokation" -> "invocation" > misprint. Should I fix it right now, or may it be done later? I think later i

<    4   5   6   7   8   9   10   11   >