Re: RFR: Some patches for sherman

On Tue, Mar 27, 2018 at 6:48 AM, Ulf Zibis wrote: > Fine enhancement > Thanks. > See also: > JDK-6862158 : Make > sun.nio.cs.* charset objects light-weight > JDK-6796087

Re: RFR: Some patches for sherman

On Tue, Mar 27, 2018 at 9:24 AM, Xueming Shen wrote: > >> 8200124: Various cleanups in jar/zip >> http://cr.openjdk.java.net/~martin/webrevs/jdk/zip-cleanup/ < >> http://cr.openjdk.java.net/%7Emartin/webrevs/jdk/zip-cleanup/> >>

Re: RFR: {@docRoot} reference need to be updated to reflect new module structure

On Tue, Mar 27, 2018 at 8:34 AM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > On 3/27/18 8:30 AM, Martin Buchholz wrote: > > > > On Tue, Mar 27, 2018 at 2:00 AM, Alan Bateman <alan.bate...@oracle.com> > wrote: > >> On 27/03/2018 01:01, Jonathan

Re: RFR: {@docRoot} reference need to be updated to reflect new module structure

On Tue, Mar 27, 2018 at 2:00 AM, Alan Bateman wrote: > On 27/03/2018 01:01, Jonathan Gibbons wrote: > >> This is fixing up some links in the java.base module, following a recent >> change >> in javadoc to the organization of the generated files. While the change >> was

RFR: Some patches for sherman

8200116: ConstructInflaterOutput, ConstructDeflaterInput still spamming test logs http://cr.openjdk.java.net/~martin/webrevs/jdk/ConstructInflaterOutput/ https://bugs.openjdk.java.net/browse/JDK-8200116 8200124: Various cleanups in jar/zip

Re: Inefficient indexOf called inside of CopyOnWriteArrayList$COWSubList.remove(Object)

I filed https://bugs.openjdk.java.net/browse/JDK-8200258 and added comment: I agree that CopyOnWriteArrayList subList code can be improved. We should stop subclassing AbstractList. We should add more tests. We should have more guidance about when to use index-based API - only when quiescent or

Re: [PATCH] Duplicated indexOf/lasIndexOf in array-based collections

Сергей, I'm sort of maintaining all those collection classes, and I have on occasion also wanted to have indexOf methods in Array.java. But: Arrays are generally discouraged. Any new static methods on Arrays (or, where I actually want them, on the array object itself! Requires a java language

Re: Is a peculiar structural modification permissible while iterating a List using the fail-fast iterator?

https://docs.oracle.com/javase/9/docs/api/java/util/ConcurrentModificationException.html On Sat, Mar 24, 2018 at 11:13 AM, kedar mhaswade wrote: > I apologize in advance if this has been asked before or if I am making a > rookie mistake. > > Consider the program [1].

Re: [PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

ue avgt 50 5,141 ± 0,080 > ns/op > EqualsIgnoreCaseBenchmark.betterMethod false avgt 50 3,436 ± 0,049 > ns/op > EqualsIgnoreCaseBenchmark.betterMethodnull avgt 50 3,085 ± 0,048 > ns/op > > EqualsIgnoreCaseBenchmark.defaultMethod true avgt 50 9,931 ± 0,25

Re: [PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

If parseBoolean is worth optimizing (barely, but only because Boolean is very popular), then let's do the usual ASCII bit-twiddling: public static boolean parseBoolean(String s) { // return "true".equalsIgnoreCase(s); return s != null && s.length() == 4

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Hmmm... it's a hard problem because we intentionally have invalid html in our private javadoc, since it's designed primarily for human readers, e.g. error: malformed HTML [javadoc] * Precondition and postcondition: 0 <= i < modulus. jsr166 has: [javadoc] 86 errors [javadoc] 780

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On Wed, Mar 21, 2018 at 1:59 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > > I think that maybe we should establish a convention such that user-defined > anchors can never conflict with javadoc-generated anchors. Using an > embedded "-" (as in this proposal) in user-defined anchors

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On Wed, Mar 21, 2018 at 2:03 PM, David Lloyd wrote: > On Wed, Mar 21, 2018 at 3:39 PM, mandy chung > wrote: > > On 3/21/18 10:26 AM, David Lloyd wrote: > > > > I see it with IntelliJ IDEA when I pop up "quick JavaDoc" on, say, > > defineClass and

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Found it. https://bugs.openjdk.java.net/browse/JDK-8199947

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Hi David. I'll take this one. - * Returns a {@code Package} of the given name that + * Returns a {@code Package} of the given name that Do Packages (I should really learn about Packages) actually have binary names? I'm confused by the subject. There is no such bug 9053056: Anchor

Re: [PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

> > */ > public boolean equals(Object obj) { > if (obj instanceof Boolean) { > - return value == ((Boolean)obj).booleanValue(); > + return value == (Boolean) obj; > } > > This is not correct, since we might have multiple Boolean objects that are equals, but not ==. Do

Re: [PATCH] unnecessary null check inside of java.lang.Boolean.valueOf(String)

On Sun, Mar 18, 2018 at 2:57 AM Сергей Цыпанов wrote: Сергей, Спасибо. https://bugs.openjdk.java.net/browse/JDK-8199800

Re: RFR 8199616: Fix @module declarations in tier1 tests

wrote: > Martin, > > > On Mar 15, 2018, at 4:30 PM, Martin Buchholz <marti...@google.com> wrote: > > How did you find the missing module dependencies? > > > I have a tool which runs tests one by one like this (I am simplifying): > - run test with -javaoption

Re: RFR 8199616: Fix @module declarations in tier1 tests

How did you find the missing module dependencies? Why was it only noticed now? Can we automatically prevent backsliding? On Thu, Mar 15, 2018 at 3:40 PM Alexandre (Shura) Iline < alexandre.il...@oracle.com> wrote: > Hi, > > Please take a quick look on fix adding missing module dependencies to >

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

Thanks Ian and Sherman for the excellent presentation and memories of ancient efforts. Yes, Sherman, I still have vague memory that attempts to touch any implementation detail in this area was asking for trouble and someone would complain. I was happy to let you deal with those problems!

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Thanks - looks good. On Fri, Mar 2, 2018 at 3:37 PM, wrote: > Thanks for comments, Martin, Roger. Updated the fix as follows: > > http://cr.openjdk.java.net/~naoto/4993841/webrev.04/ > > Naoto > > > On 3/1/18 6:47 PM, naoto.s...@oracle.com wrote: > >> Hi, >> >> Please

Re: RFR: Here are some URLClassPath patches

e > the summary and description. > When it is done, close it as 'delivered'. > > Thanks, Roger > > [1] https://bugs.openjdk.java.net/browse/JDK-8198956 > > > > On 3/1/2018 10:32 PM, Martin Buchholz wrote: > >> On Wed, Feb 28, 2018 at 3:58 PM, Martin Buchholz <marti..

Re: RFR: Here are some URLClassPath patches

I have a patch to move those old jdi tests out of the ProblemList jail. I thought we had an existing bug in hotspot-svc to do this, but now I can't find it. We can just use well-formed URLs. http://cr.openjdk.java.net/~martin/webrevs/jdk/jdi-tests-malformed-urls/

Re: RFR: Here are some URLClassPath patches

: URLClassLoader does not specify behavior when URL array contains null Reviewed-by: alanb, darcy, dholmes On Thu, Mar 1, 2018 at 7:32 PM, Martin Buchholz <marti...@google.com> wrote: > > > On Wed, Feb 28, 2018 at 3:58 PM, Martin Buchholz <marti...@google.com> > wrote: > >&

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

The multiple redundant bounds checks bother me, but I don't know how to fix them without abandoning a bit of modularization. if (cp >= 0) { if (COMPACT_STRINGS && cp < 0x100) return latin1encode() if (cp < MIN_SURROGATE || (cp > MAX_SURROGATE && cp < MIN_SUPPLEMENTARY_CODEPOINT) return

Re: RFR: Here are some URLClassPath patches

On Wed, Feb 28, 2018 at 3:58 PM, Martin Buchholz <marti...@google.com> wrote: > > > 8198810: URLClassLoader does not specify behavior when URL array contains > null > http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassLoader-NPE/ > https://bugs.openjdk.java.net/brows

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

+ * @param codepoint a {@code codePoint}. does not match the formal parameter. javadoc -private should give an error on that.

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

I was surprised to learn that junit has a magic assertEquals specifically for Object[] assertEquals(Object[], Object[]) but that is obviously a bad idea and junit eventually deprecated it. https://junit.org/junit4/javadoc/4.12/org/junit/Assert.html#assertEquals(java.lang.Object[],

Re: RFR: Here are some URLClassPath patches

OK, that was weird... All I did for testing was follow // This section should be uncommented if 8026517 is fixed. but ... 8026517 is marked fixed! So switching to ArrayDeque accidentally fixed 8026517 for real?! 8198810: URLClassLoader does not specify behavior when URL array contains null

Re: RFR: Here are some URLClassPath patches

On Wed, Feb 28, 2018 at 6:17 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > On 28/02/2018 03:02, Martin Buchholz wrote: > > I should probably do more testing than usual when touching classloading... > > We have a jdi test that does this (hg blame finds duke as only au

Re: RFR: Here are some URLClassPath patches

8198808: jdi tests failing after JDK-8198484 http://cr.openjdk.java.net/~martin/webrevs/jdk/jdi-ProblemList/ https://bugs.openjdk.java.net/browse/JDK-8198808

Re: RFR: Here are some URLClassPath patches

I should probably do more testing than usual when touching classloading... We have a jdi test that does this (hg blame finds duke as only author): public static ClassLoader classLoaderValue; { try { urls[0] = new URL("hi there"); } catch

Re: RFR: Here are some URLClassPath patches

On Mon, Feb 26, 2018 at 3:38 PM, mandy chung <mandy.ch...@oracle.com> wrote: > > > On 2/26/18 3:26 PM, Martin Buchholz wrote: > > > Looks okay. I also think no need to have a separate copyToArrayDeque >> method and just inline in the constructor. >> >

Re: RFR: Here are some URLClassPath patches

On Mon, Feb 26, 2018 at 3:06 PM, mandy chung <mandy.ch...@oracle.com> wrote: > > > On 2/21/18 12:30 PM, Martin Buchholz wrote: > line 63-64: ident further to the right as line 62 is the condition. > > Whitespace rejiggered. > Looks okay. I also think no need to have

Re: RFR: Here are some URLClassPath patches

On Mon, Feb 26, 2018 at 3:06 PM, mandy chung wrote: > > 8198480: Improve ClassLoaders static init block > http://cr.openjdk.java.net/~martin/webrevs/jdk/ClassLoaders-static/ > https://bugs.openjdk.java.net/browse/JDK-8198480 > > > Can you rename initialModuleName to

Re: RFR: Here are some URLClassPath patches

On Mon, Feb 26, 2018 at 9:28 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > > > > On Feb 23, 2018, at 2:09 PM, Martin Buchholz <marti...@google.com> > wrote: > > > > [+Paul] > > > > On Fri, Feb 23, 2018 at 6:28 AM, Alan Bateman <alan.bate..

Re: RFR: Here are some URLClassPath patches

[+Paul] On Fri, Feb 23, 2018 at 6:28 AM, Alan Bateman wrote: > > 8198484: URLClassPath should use an ArrayDeque instead of a Stack > http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-ArrayDeque/ > https://bugs.openjdk.java.net/browse/JDK-8198484 > > Can

Re: RFR: Here are some URLClassPath patches

On Fri, Feb 23, 2018 at 6:28 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > Just getting to the updated webrev now. > > On 21/02/2018 20:30, Martin Buchholz wrote: > > : > > > 8198480: Improve ClassLoaders static init block > http://cr.openjdk.java.net/~marti

Re: RFR: Here are some URLClassPath patches

On Wed, Feb 21, 2018 at 7:48 AM, Roger Riggs wrote: > > On the style changes in URLClassPath-ArrayDeque, about declarations like: > > ArrayList path = new ArrayList<>(); > > It had been a recommended style to use the abstract type (List) on the > left hand side > and only

Re: RFR: Here are some URLClassPath patches

OK, we have a reworked set of patches. (In my corner of openjdk we generally use real javadoc on private elements.) I reverted private doc comment style to the current maddening inconsistency, except I couldn't restrain myself from fixing -// ACC used when loading classes and resources */ +

RFR: Here are some URLClassPath patches

At Google I spend a lot of time staring unproductively at classloader code, and it's always hard for me to resist the urge to clean it up. So here are some patches that should be relatively uncontroversial, and may prepare for more radical changes later. 8198480: Improve ClassLoaders static init

Re: [11] RFR JDK-8198441: Replace native Runtime::runFinalization0 method with shared secrets

Looks good! On Tue, Feb 20, 2018 at 9:45 AM, mandy chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8198441/webrev.00 > > This is a small cleanup that replaces the native Runtime::runFinalization0 > method with shared secrets to invoke

Re: RFR: 8197594 - String and character repeat

. On Sun, Feb 18, 2018 at 11:19 AM, Martin Buchholz <marti...@google.com> wrote: > > - how many digits to consume after the escape? How much do we trust > Unicode to never ever grow beyond 5 hex digits? > Oops, I already got it wrong - it's already at 6 hex digits be

Re: Thread.interrupted() spec is confusing

One can understand the desire to keep the spec wording between Thread.interrupted and Thread.isInterrupted consistent, but we can probably improve by @linkplain-ifying "alive" and adding the word "yet". On Sun, Feb 18, 2018 at 10:16 AM, Alan Bateman wrote: > On

Re: RFR: 8197594 - String and character repeat

On Sun, Feb 18, 2018 at 1:37 AM, James Laskey wrote: > Didn’t I hear someone mentioning “\U1D11A” at some point? > Unicode codepoint escapes are still Not a Thing, apparently. Yes, it's a language feature, but an easy one to implement. Except for the usual bikeshedding

Re: RFR: 8197594 - String and character repeat

Let me join the chorus of agreement with Brian here. The most popular use case will forever be ASCII line of non-letter symbols. Another way to think about codepoints is as conversion between UTF-32 and UTF-16, or as general support for text in UTF-32 format, which is not supported well within

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On Fri, Feb 16, 2018 at 10:26 AM, mandy chung wrote: > > > On 2/16/18 6:52 AM, Peter Levart wrote: > > I think that the following now never applies (in Finalizer) since > ReferenceQueue never returns the same Reference object more than once: > > 71 if

Re: RFR: 8197812: (ref) Data race in Finalizer

Thanks, Mandy, changeset pushed. We are in agreement. On Thu, Feb 15, 2018 at 7:31 PM, mandy chung <mandy.ch...@oracle.com> wrote: > > > On 2/15/18 7:13 PM, Martin Buchholz wrote: > > > > On Thu, Feb 15, 2018 at 3:20 PM, mandy chung <mandy.ch...@oracle.com> &

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

This also changes the handling of (undeprecated) method runFinalization and that's obviously related but could be a separate changeset. We'll need to merge with my own pending change to Finalizer.java.

Re: RFR: 8197812: (ref) Data race in Finalizer

On Thu, Feb 15, 2018 at 3:20 PM, mandy chung wrote: > > I have posted RFR to remove runFinalizersOnExit. I think your patch > would become cleaner as you may keep the remove method or inline in > runFinalizer method as your original patch has. > > Do you want to wait

Re: RFR: 8197812: (ref) Data race in Finalizer

On Wed, Feb 14, 2018 at 11:47 PM, Peter Levart wrote: > > Although not strictly necessary for correctness, for the time being, it > would be nice to be consistent in marking the Finalizer object "already > finalized" in both places. Either set both next and prev to this

Re: RFR: 8197812: (ref) Data race in Finalizer

Embarrassed by my failure to take runFinalizersOnExit into account, I tried to redo the patch to be actually correct. http://cr.openjdk.java.net/~martin/webrevs/jdk/Finalizer-data-race/ even though we may succeed in making runFinalizersOnExit go away, and I'm not planning to submit any time soon.

Re: RFR: 8197812: (ref) Data race in Finalizer

Indeed I had suppressed all memory of runFinalizersOnExit. (Sorry about that.) I support removing it in jdk11. Mandy, would you like to file the CSR? On Wed, Feb 14, 2018 at 1:15 PM, mandy chung wrote: > > > On 2/14/18 1:58 AM, Peter Levart wrote: > > > I take back this

RFR: 8197893: Mistaken type check in CheckedEntrySet.toArray

http://cr.openjdk.java.net/~martin/webrevs/jdk/CheckedEntrySet-toArray/ https://bugs.openjdk.java.net/browse/JDK-8197893

RFR: 8197812: (ref) Data race in Finalizer

Unlike most fixes to data races, this one should benefit performance. http://cr.openjdk.java.net/~martin/webrevs/jdk/Finalizer-data-race/ https://bugs.openjdk.java.net/browse/JDK-8197812

Re: RFR: jsr166 jdk integration 2018-02

Hans, thanks for another great lesson! On Fri, Feb 9, 2018 at 11:19 AM, Hans Boehm wrote: > > The downside of treating "this" specially is that it makes it even harder > to explain the other cases, e.g. when the object being finalized > prematurely was an explicit parameter,

Re: Weird timezone issues with Timestamp.valueOf(String s)

[redirect to core-libs-dev] On Fri, Feb 9, 2018 at 7:08 AM, wrote: > Not that I encourage using date/time classes from the packages of either > java.util or java.sql, but sometimes it happens under the hood. > > > > We found a weird issue with timestamps. > > In our

Re: RFR: jsr166 jdk integration 2018-02

On Thu, Feb 8, 2018 at 10:39 PM, David Holmes wrote: > > Well at least it's only an issue if there does exist a finalize() method > that could interfere with the executing method. I have to assume that > somehow the VM is clever enough that if 'this' is in a register and

Re: RFR: jsr166 jdk integration 2018-02

On Thu, Feb 8, 2018 at 8:39 PM, David Holmes wrote: > > Wow! DelegatedExecutorService doesn't even have a finalize() method that > does a shutdown. So we have to put the reachabilityFence in it to prevent > the delegatee from becoming unreachable due to the delegator

Re: RFR: jsr166 jdk integration 2018-02

On Thu, Feb 8, 2018 at 7:39 PM, David Holmes <david.hol...@oracle.com> wrote: > On 9/02/2018 11:19 AM, Martin Buchholz wrote: > >> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integr >> ation/overview.html >> >> 8190324: ThreadPoolExec

RFR: jsr166 jdk integration 2018-02

http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8190324: ThreadPoolExecutor should not specify a dependency on finalization http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ThreadPoolExecutor-finalize/index.html

Re: JDK 11 RFR of JDK-8196995: java.lang.Character should not state UTF-16 encoding is used for strings

Instead of saying something specific about char[], String etc you can be more general and say something about the entire Java Platform. "The Java Platform generally processes human language text represented as sequences of {@code char} values in the UTF-16 encoding of Unicode" But doing this

Re: JDK 11 RFR of JDK-8196995: java.lang.Character should not state UTF-16 encoding is used for strings

I'm not sure about this. The LATIN-1 optimization is an implementation detail. The important thing is the API, and it remains char-oriented (although we've added codepoint APIs over the years). Strictly speaking, you can store any 16-bit integer sequences in char[], String, or StringBuffer - no

RFR: 8196609: Improve javadoc for java.time.Instant.getEpochSecond

The nanos *are* hard to describe non-confusingly - resisting the urge to fix more globally. --- a/src/java.base/share/classes/java/time/Instant.java +++ b/src/java.base/share/classes/java/time/Instant.java @@ -610,7 +610,7 @@ * * The epoch second count is a simple incrementing count

Re: Collections.addAll: remove outdated performance advice and add a note about atomicity

I tried to tackle this here: http://openjdk.markmail.org/thread/eet2zd6ig3pfpv5g and it's still on my TODO list but not likely to get to top spot soon. On Tue, Jan 30, 2018 at 7:00 PM, Tagir Valeev wrote: > Hello! > > I suggest a patch for java.util.Collections#addAll

Re: [PATCH] Inefficient ArrayList.subList().toArray()

On Mon, Jan 29, 2018 at 1:02 PM, Martin Buchholz <marti...@google.com> wrote: > I'm going to expedite this a little since we are building further changes > on top. > > 8196207: Inefficient ArrayList.subList().toArray() > http://cr.openjdk.java.net/~martin/webrevs/jdk/

Re: [PATCH] Inefficient ArrayList.subList().toArray()

On Mon, Jan 29, 2018 at 3:10 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > > > > On Jan 29, 2018, at 1:02 PM, Martin Buchholz <marti...@google.com> > wrote: > > > > I'm going to expedite this a little since we are building further changes > > on

Re: [PATCH] Inefficient ArrayList.subList().toArray()

/jsr166-integration/ArrayList-subList-toArray/index.html https://bugs.openjdk.java.net/browse/JDK-8196207 On Fri, Jan 26, 2018 at 9:12 AM, Martin Buchholz <marti...@google.com> wrote: > It may be that array-backed lists inheriting from AbstractList is not > useful except when creating

Re: RFR: 8196331: Optimize Character.digit for latin1 input

Thanks. I might try to shrink the size of the static array, by only storing values between '0' and 'z', at the cost of slightly greater lookup costs for each char. On Mon, Jan 29, 2018 at 3:15 AM, Claes Redestad wrote: > Hi, > > for the latin1 block of CharacterData

Re: RFR[JDK10]: 8195837: (tz) Support tzdata2018c

Google has been successfully running jdk8 and jdk9 with 2018c. On Mon, Jan 29, 2018 at 12:49 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2018c) into JDK10. > Bug: https://bugs.openjdk.java.net/browse/JDK-8195837 > Webrev:

Re: [PATCH] Inefficient ArrayList.subList().toArray()

wrote: > On 2018-01-26 07:20, Martin Buchholz wrote: > >> It's still possible to find simple performance improvements in classes >> like >> ArrayList. >> > > Indeed! > > It seems ArrayList.SubList delegates quite a few of its implementations > to Abstra

Re: [PATCH] Inefficient ArrayList.subList().toArray()

Yes. public Object[] toArray() { checkForComodification(); return Arrays.copyOfRange(root.elementData, offset, offset + size); } @SuppressWarnings("unchecked") public T[] toArray(T[] a) { checkForComodification();

Re: [PATCH] Inefficient ArrayList.subList().toArray()

Thanks, Сергей I filed a bug for you https://bugs.openjdk.java.net/browse/JDK-8196207 On Thu, Jan 25, 2018 at 2:02 PM, Сергей Цыпанов wrote: > Hi, > > I've run into poor performance of toArray() method called on result of > subList() taken from java.util.ArrayList. >

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Wed, Jan 10, 2018 at 3:58 PM, Paul Sandoz wrote: > > The code is skating close to the edge and is definitely making you > uncomfortable :-) so I proposed making the field non-final but annotated > with @Stable, the same optimisations should still apply. > Sorry,

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Tue, Jan 9, 2018 at 4:50 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > > > On 9 Jan 2018, at 15:11, Martin Buchholz <marti...@google.com> wrote: > > > > On Tue, Jan 9, 2018 at 2:42 PM, Paul Sandoz <paul.san...@oracle.com> > wrote: > >&g

Re: Android and Log4j

On Tue, Jan 9, 2018 at 5:11 PM, Ralph Goers wrote: > > I don’t think I got a reply to this question. I created > https://issuetracker.google.com/issues/70118537 for this but I have not > gotten any response. Is there a better mailing list where I should follow > up? >

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Tue, Jan 9, 2018 at 2:42 PM, Paul Sandoz <paul.san...@oracle.com> wrote: > > > > On 9 Jan 2018, at 14:20, Martin Buchholz <marti...@google.com> wrote: > > > > The memory model is already too hard to reason about, but here the VM > can assume that the f

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

On Tue, Jan 9, 2018 at 4:12 AM, Vladimir Ivanov < vladimir.x.iva...@oracle.com> wrote: > > In the hotspot sources I find >>// An instance field can be constant if it's a final static field >> or if >>// it's a final non-static field of a trusted class (classes in >>//

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

In general the updates to the field will only be > visible to interpreted code or recompiled code. > > I suspect the problematic field may well be that of > LambdaForm.transformCache. > > Paul. > > > On 8 Jan 2018, at 18:41, Martin Buchholz <marti...@google.com> wr

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

LambdaForm form = this.form; if (form.customized == null) { LambdaForm newForm = form.customize(this); updateForm(newForm); On Wed, Jan 3, 2018 at 1:51 PM, Martin Buchholz <marti...@google.com> wrote: > Let's try again without mail bounces ... > > > O

RFR: jsr166 jdk integration 2018-01

http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html 8191483: AbstractQueuedSynchronizer cancel/cancel race http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/AQS-cancel-cancel-race/index.html https://bugs.openjdk.java.net/browse/JDK-8191483 Lots of

Re: JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Let's try again without mail bounces ... On Wed, Jan 3, 2018 at 1:40 PM, Martin Buchholz <marti...@google.com> wrote: > Here at Google we tried to fix JDK-8145371 because it looked like it was > causing rare problems in production. But after looking at the code, I'm > not s

JDK-8145371 ClassCastException thrown in LambdaFormEditor.getInCache

Here at Google we tried to fix JDK-8145371 because it looked like it was causing rare problems in production. But after looking at the code, I'm not sure... Anyways, http://cr.openjdk.java.net/~martin/webrevs/jdk/MethodHandle.form/ https://bugs.openjdk.java.net/browse/JDK-8145371 Copying to a

Re: RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947

It would add more confusion to a something that's already difficult to understand. It's OK as a temporary measure, but I don't think we want product code just to enable tests in hotspot. Can the hotspot folks modify their test, perhaps making this code part of the test? On Wed, Dec 13, 2017 at

Re: [10!] RFR: 8193471: Startup regression due to JDK-8185582

fyi Google does some automated desugaring for lambdas using a program named ... desugar.

Re: RFR: JDK-8184947:,ZipCoder performance improvements

Fix typo: singlton Remove stray space: +ba = Arrays.copyOfRange(ba, off, off + len);

Re: RFR: JDK-8184947:,ZipCoder performance improvements

Sorry, I haven't had the time I would like to review. It would be good to make jdk10. I keep wishing what we do for performance here wouldn't get so messy. I keep thinking we should add some methods to the public Charset classes, e.g. canDecode(byte[], int, int) with one general purpose

Re: Possible bug in StackFrameInfo#getByteCodeIndex?

Out of curiosity, I looked more at StackFrameInfo, and saw: short bci is final and is only ever assigned to -1 in java code. What's up with that? Ohh, it seems to be magically frobbed in hotspot: void java_lang_StackFrameInfo::set_bci(oop element, int value) {

Re: Possible bug in StackFrameInfo#getByteCodeIndex?

Java has an unsigned 16 bit type. Could bci be of type "char" ? On Mon, Dec 11, 2017 at 1:53 PM, mandy chung wrote: > I filed https://bugs.openjdk.java.net/browse/JDK-8193325. I can sponsor > this patch for you. > > ---

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

Pushed. In future I will use the phrase "Best of a Bad Lot Practice". On Mon, Dec 4, 2017 at 4:20 PM, Stuart Marks wrote: > If you don't like my alternative, fine; it has its own set of tradeoffs >>> that might be net positive or negative. If you want to

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Should there be changes to general purpose collection testing classes like test/jdk/java/util/concurrent/tck/CollectionTest.java test/jdk/java/util/Collection/MOAT.java that would have caught this bug? (although those are mostly designed for mutable collections, but I think some immutable

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On Thu, Dec 7, 2017 at 4:47 PM, Stuart Marks wrote: > > > On 12/7/17 3:50 PM, Jonathan Bluett-Duncan wrote: > > Looking over http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/ >> src/java.base/share/classes/java/util/ArrayList.java.cdiff.html, I'm >> wondering

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

(I'm still trying to love this new API) The changes to the jsr166 tck are fine. I'm not convinced that the new implementation for ArrayList is progress. The current implementation of toArray(T[]) does // Make a new array of a's runtime type, but my contents: return (T[])

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

I'm not a logging expert, but this change Looks Good To Me. --- A bunch of "handler" should be changed to "handlers" +// Verify that exactly one of the two handler is a custom.Handler +// Verify that exactly one of the two handler is a custom.DotHandler +// Verify that

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

You went to the trouble of checking test.src. Shouldn't CONFIG_FILE be found relative to SRC_DIR? +public static final Path SRC_DIR = +Paths.get(System.getProperty("test.src", "src")); +public static final Path USER_DIR = +Paths.get(System.getProperty("user.dir",

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

On Thu, Dec 7, 2017 at 11:00 AM, Martin Buchholz <marti...@google.com> wrote: > You went to the trouble of checking test.src. Shouldn't CONFIG_FILE be > found relative to SRC_DIR? > > Oh never mind, I now see you did +Path initialProps = SRC_DIR.resolve(CONFIG_FI

RFR: jsr166 jdk integration 2017-12-XX

http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html With the change to the openjdk release model, jsr166 integrations will simply be "jdk integrations" instead of e.g. "jdk10 integrations" from now on. (Nevertheless, we try to get in important bug fixes before jdk

Re: RFR: 8191033: Regression in logging.properties: specifying .handlers= for root logger (instead of handlers=) no longer works

configure => configured +// For backward compatibility: add any handlers configure using

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

+1

Re: Review Request: JDK-8193159: Reduce the number of classes loaded due to NativeLibrary

Google decided that LinkedList is almost never the best choice, so any use of LinkedList is discouraged. ArrayDeque's backing array never shrinks, so you might want to give it an explicit initial size. On Wed, Dec 6, 2017 at 4:33 PM, mandy chung wrote: > A tiny startup

<    1   2   3   4   5   6   7   8   9   10   >