Re: RFR 8234147 : Avoid looking up standard charsets in core libraries

Hi Ivan, you may compare your proposal with: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6790402 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6850361 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6796087 -Ulf Am 27.11.19 um 05:39 schrieb Ivan Gerasimov: Hello! It is a

Re: CharsetEncoder.maxBytesPerChar()

Hey Martin, great, that you got my issue. The link you shared is an interesting basis for this discussion. Maybe at some places e.g. in the "upfront specifications", additionally the term "UTF-16 char" or "UTF-16 code unit" could be helpful and then determining "char" or "{@code char}" as a short

Re: CharsetEncoder.maxBytesPerChar()

Am 21.09.19 um 00:03 schrieb mark.reinh...@oracle.com: > To avoid this confusion, a more verbose specification might read: > * Returns the maximum number of $otype$s that will be produced for each > * $itype$ of input. This value may be used to compute the worst-case > size > * o

Re: RFR: Some patches for sherman

Fine enhancement! See also: JDK-6862158 : Make sun.nio.cs.* charset objects light-weight JDK-6796087 : Speed-up sun.nio.cs.StandardCharsets JDK-6790402

Re: RFR: 8197594 - String and character repeat

Am 18.02.2018 um 06:10 schrieb Stuart Marks: Fair enough. I'll be less unhappy if there is a way to convert from a code point to a String, as requested by JDK-4993841. This will reduce new String(Character.toChars(codepoint)).repeat(count) to Character.toString(codepoint).repeat(cou

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

Hi, what is the difference of: - class StringCoding - class StringCoder - class StringCoding.StringDecoder - class StringCoding.StringEncoder Why we need so much variants of redundant code? I think it would be useful to have some explanation in the javadoc. Missing indentation in StringCoder.

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

have been a startup optimization in the past, it is now mainly a workaround to method bytecode limits, see https://bugs.openjdk.java.net/browse/JDK-8185104 /Claes On 2018-01-30 01:10, Ulf Zibis wrote: Hi, you may can construct the lookup table as a static String constant to slim down the footprint an

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

Hi, you may can construct the lookup table as a static String constant to slim down the footprint and treat it as a byte[] as we do in the Charset coders. -Ulf Am 29.01.2018 um 22:04 schrieb Claes Redestad: I'll experiment and analyze a bit more tomorrow to see if I can find a good explana

Re: RFR JDK-8186751: Add ISO-8859-16 Charset support

Hi again, Am 31.08.2017 um 23:29 schrieb Xueming Shen: The 8859-16 aliases are the copy/paste from https://www.iana.org/assignments/character-sets/character-sets.xhtml From the same page we have the followings for 8859-15 ISO_8859-15 Latin-9 csISO885915 It appears only the first one is listed

Re: [10] RFR: 8185104: Generate CharacterDataLatin1 lookup tables directly

Hi, Am 23.07.2017 um 15:37 schrieb Claes Redestad: 1. it reduces the size of the generated bytecode, which is necessary to keep code below method bytecode limits if the arrays generated are very large I always was wondering why filling large lookup tables is done by static java code in the

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

Am 02.03.2017 um 18:16 schrieb Vitaly Davidovich: When the optimization applies, there shouldn't be *any* instructions for the null check on the path - it's done via signal handling. Thanks for clarification. This is Sufficiently Smart Compiler territory. It's much better to hand-code this pr

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

Am 02.03.2017 um 14:55 schrieb Vitaly Davidovich: Implicit null checks ... generally don't cost anything. Any additional byte of code in CPU cache prevents other code from staying there. I can't imagine, if any programmer would rely on such contract, instead of doing the check expli

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

HI, first sorry for missing the class wide definition. Am 02.03.2017 um 12:45 schrieb Vitaly Davidovich: On Thu, Mar 2, 2017 at 6:38 AM Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: In any case, what's the reasonable of checking an argument, which is not used in tha

Re: [NEW BUG]: Avoid allocations in String.replace(CharSequence, CharSequence) in case no replacement happened

Hi Vitaly, I don't see any contract to throw an NPE: https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence- In any case, what's the reasonable of checking an argument, which is not used in that case? Am 02.03.2017 um 00:18 schrie

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Hi, I would prefer a "normal" class instead a convolut of static methods. Via a normal constructor, we could pass some custom parameters e.g. capital/uppercase letters for "abcdef", prefix a header line, width of the index counter, bytes per line, i.e. have all the parameters, you have hardcode

Re: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char

Am 08.12.2016 um 09:28 schrieb Peter Levart: On 12/07/2016 11:28 PM, Roger Riggs wrote: AbstractStringBuilder: I agree with Claes' comment suggesting that IAE for negative lengths is a pain and defining it to append 0 would be natural in many use cases. OTOH, inserting a simple Math.m

Re: RFC: System.console().encoding()

Am 15.09.2016 um 17:56 schrieb Aleksey Shipilev: ...which opens a way to poll this without a Reflection hack. Extended the JMH hack with it, but it still fragile: http://hg.openjdk.java.net/code-tools/jmh/rev/8c20adb08b2d Maybe keep it simple - no need for (prop != null) - and in design line

Re: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS

Am 05.06.2016 um 21:30 schrieb Ulf Zibis: And I still think, moving the string concatenation to ZipPath constructor would be a good idea. I believe, this would make things more simple and less redundant: ZipPath(ZipFileSystem zfs, String first, String... more) E.g. you could reuse the

Re: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS

Am 05.06.2016 um 21:30 schrieb Ulf Zibis: Is this the answer to my # 3.) ? I really often see Windows-1252 coded zip files for download in the web. Maybe you see them rarely as american, but if there are german Umlaute in the file names, it' really painful to convert all the paths here o

Re: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS

Sherman, thanks for your consideration. Am 31.05.2016 um 19:08 schrieb Xueming Shen: Ulf, thanks for the suggestions! On 5/31/16 6:27 AM, Ulf Zibis wrote: Hi Sherman, 1.) wouldn't it be better to have a public getBytes() in AbstractStringBuilder? Then you could save the array copy

Re: RFR: JDK-8061777, , (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS

Hi Sherman, 1.) wouldn't it be better to have a public getBytes() in AbstractStringBuilder? Then you could save the array copy with sb.toString() here: 178 return new ZipPath(this, sb.toString(), zc.isUTF8()); 525 return zfs.getBytes(to.toString()); You could simplify even mor

Re: RFR: 8155795: Optimize Integer/Long.reverse by using reverseBytes

Am 02.05.2016 um 17:00 schrieb Claes Redestad: The reverseBytes changes were motivated by seeing slightly better performance on the micro with the suggested changes, but after discussing this a bit I think we should revert to the original code alone and investigate if there's some compiler quirk

Re: RFR: 8154231: Simplify access to System properties from JDK code

Hi Claes, thanks. Am 20.04.2016 um 18:12 schrieb Claes Redestad: Thanks for looking at this, Ulf! - Isn't the "theProp" naming style something from an old usage where all members have been named myXyz? I more would like "propName" or just "property". I chose to go with keeping names in line

Re: RFR: 8154231: Simplify access to System properties from JDK code

Hi, here my comments: Am 20.04.2016 um 16:44 schrieb Claes Redestad: Hello, now that the sun.security.action package is encapsulated we can simplify internal code to get System properties. Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 Webrev: http://cr.openjdk.java.net/~redestad/815

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Hi, good point! As a convenience we could have something like: ByteBuffer#allocateDirect(Path path) ByteBuffer#allocateDirect(int size, Path path, Option options) What is the logical difference between a memory and a byte buffer, as both provide the facility to save bytes? Couldn't Intel just p

Re: RFR: 8145680: Remove unnecessary explicit initialization of volatile variables in java.base

Am 21.12.2015 um 11:31 schrieb Ulf: Am 21.12.2015 um 00:06 schrieb Claes Redestad: Hi all, On 2015-12-20 20:43, Ulf wrote: Hi Claes, I had a very short look and found in j.l.Thread: 211 * Java thread status for tools, 0 indicate thread 'not yet started' I guess you meant: 211 *

Re: RFR (S) 8145428: Optimize StringUTF16 compress/copy methods for C1

Am 17.12.2015 um 08:54 schrieb Aleksey Shipilev: On 12/17/2015 02:34 AM, Ulf wrote: I'm wondering why moving the increment operation to an extra line wound enhance performance. Because C1 is very straightforward, and code movement like that is a poor man's instruction scheduling, that pads out

Re: RFR: 8085984 Add JDBC Sharding API

Hi, Isn't it "i_f_Valid not implemented" instead "i_s_Valid not implemented" or eventually "setShardingKeyIfValid not implemented"? -Ulf Am 24.11.2015 um 00:01 schrieb Lance Andersen: Hi all, Need a reviewer for 8085984, which adds support for Sharding. The CCC has been approved. The w

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

Am 08.09.2015 um 20:37 schrieb Andrew Haley: I think that MR is referring to Windows when he talks about race conditions. Andrew. Couldn't we introduce a unmap() method which throws an UnsupportedOperationException if the underlying OS isn't able to unmap the the buffer safely in the mean time

Re: RFR 8124977 cmdline encoding challenges on Windows

Am 08.07.2015 um 18:50 schrieb Kirk Shoop: Valery prepared a new webrev which I placed here: http://cr.openjdk.java.net/~kshoop/8124977/webrev.01 May be better to avoid potetially superfluous lookup of UTF-8: public static Charset defaultUnicodeCharset() { if (defaultUnicodeCharset ==

Re: String.contains(CharSequence) calls toString on argument

. If I have to apply one of proposed changes I would choose first or third. Regards, Tomasz On Thu, May 28, 2015 at 12:35 PM, Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: Hi, I more would like: 2199 return (s instanceof String) 2200 ? indexOf((Str

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

Hi, Am 31.05.2015 um 18:03 schrieb Ivan Gerasimov: On 31.05.2015 18:54, Ivan Gerasimov wrote: I fixed the code and added the case to the regression test in the new webrev. Which is right here: http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/ Shoudn't the user be informed via javado

Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)

Am 31.05.2015 um 08:38 schrieb Peter Levart: Hi, Yes, this one is much easier to grasp. As I understand the check is to avoid overflow in calculation of StringBuilder initial capacity (newLenHint). If overflow happened, newLenHint would be negative and StringBuilder construction would fail w

Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

Am 30.05.2015 um 03:26 schrieb Xueming Shen: On 5/29/15 4:02 PM, Ulf Zibis wrote: Am 29.05.2015 um 19:42 schrieb Xueming Shen: But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it

Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext

Am 29.05.2015 um 19:42 schrieb Xueming Shen: But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm, is it mandatory, that each charset pr

Re: Why isn't Object.notify() a synchronized method?

ome change since I expect the cost of recursive lock acquisition is nonzero. On 05/28/2015 11:08 AM, Ulf Zibis wrote: Hi all, in the Javadoc of notify(), notifyAll() and wait(...) I read, that this methods should only be used with synchronisation on it's instance. So I'm wondering, why

Why isn't Object.notify() a synchronized method?

Hi all, in the Javadoc of notify(), notifyAll() and wait(...) I read, that this methods should only be used with synchronisation on it's instance. So I'm wondering, why they don't have the synchronized modifier out of the box in Object class. Also I think, the following note should be moved f

Re: String.contains(CharSequence) calls toString on argument

Hi, I more would like: 2199 return (s instanceof String) 2200 ? indexOf((String) s) >= 0; 2201 : indexOf(value, 0, value.length, s, 0, s.length(), 0) >= 0; or: 2199 return (s instanceof String 2200 ? indexOf((String) s) 2201

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

Am 08.05.2015 um 13:28 schrieb Aleksey Shipilev: On 05/07/2015 06:00 PM, Ulf Zibis wrote: May be: ..., then a new internal array becomes allocated and refilled with greater capacity. ... to give a hint, that this action may be expensive. The Javadoc already says "If the current capaci

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

May be: ..., then a new internal array becomes allocated and refilled with greater capacity. ... to give a hint, that this action may be expensive. -Ulf Am 05.05.2015 um 19:47 schrieb Aleksey Shipilev: Hi again, Here is a new webrev: http://cr.openjdk.java.net/~shade/8076759/webrev.01/ P

Re: RFR (XS) 8076759: AbstractStringBuilder.append(...) should ensure enough capacity for the upcoming "trivial" append calls

Hi Aleksey, I like this approach and to me the webrev looks good. -Ulf Am 24.04.2015 um 20:05 schrieb Aleksey Shipilev: Hi, This seems to be a simple one-liner fix, but the background is more complicated. See the bug: https://bugs.openjdk.java.net/browse/JDK-8076759 http://cr.openjdk.

Re: Places we should use the new ByteBuffer intrinsics

Am 16.04.2015 um 15:25 schrieb Paul Sandoz: They look like good candidates. I did a quick search in the JDK src code (usages of getByte/Short/Int/Long) and could not find any others. I guess there are plenty of candidates in coders of sun.nio.cs. Additionally: For some coders it may be reason

Re: Places we should use the new ByteBuffer intrinsics

Am 16.04.2015 um 15:25 schrieb Paul Sandoz: They look like good candidates. I did a quick search in the JDK src code (usages of getByte/Short/Int/Long) and could not find any others. I guess there are plenty of candidates in coders of sun.nio.cs. At the end it wouldn't make me wonder if we co

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

Am 17.02.2015 um 04:35 schrieb John Rose: On Feb 14, 2015, at 12:01 AM, Andrew Haley wrote: On 02/14/2015 12:09 AM, John Rose wrote: We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. Indeed. I'm intending to prototype a des

Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

Am 17.02.2015 um 11:53 schrieb Andrew Haley: On 02/17/2015 10:49 AM, Florian Weimer wrote: That is, the byte array is supplied by the caller, and if we wanted to use a ByteBuffer, we would have to allocate a fresh one on every iteration. In this case, neither of the two alternatives you list a

Re: RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

Am 16.02.2015 um 19:46 schrieb Xueming Shen: On 2/16/15 4:11 AM, Alan Bateman wrote: 2. Hasher.java is showing up in the webrev as a new file, was this build.tools.hasher.Hasher and so we know have two copies? "This" Hasher.java has a different use interface and works on a pair of key/value list

Re: 8072909: TimSort fails with ArrayIndexOutOfBoundsException on arrays longer than 1073741824

Am 11.02.2015 um 23:57 schrieb David Holmes: So where did the new magic number 49 come from? And how do we know this is now "big enough"? Thanks, David +1 Ulf

Re: Charset.lookupViaProviders uses new ServiceLoader instance on each miss.

Am 12.01.2015 um 20:42 schrieb Martin Buchholz: Historical notes: I added the two-element cache many years ago, assuming that code that repeatedly accessed more than 2 charsets would be rare. I suspect this opinion, see: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6795535 -Ulf

Re: RFR 8060068 : Remove the static initializer block from DriverManager

Hi Lance, to me it's irritating, why there are 2 methods: - initDriversIfNeeded() - loadInitialDrivers() I would combine both to one method. In lines 90 + 92 there are double spaces. -Ulf Am 01.12.2014 um 17:52 schrieb Lance Andersen: Hi all, Looking for a review for this change to DriverMan

Re: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters

Am 12.11.2014 um 08:19 schrieb Otávio Gonçalves de Santana: Thank you Ulf. http://cr.openjdk.java.net/~weijun/8055723/webrev.01/ <http://cr.openjdk.java.net/%7Eweijun/8055723/webrev.01/> On Sat, Nov 8, 2014 at 3:46 PM, Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: H

Re: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters

gt; wrote: Thank you Ulf. I removed the fix in toString method and in debug classes: http://cr.openjdk.java.net/~weijun/8055723/webrev.00/ <http://cr.openjdk.java.net/%7Eweijun/8055723/webrev.00/> On Mon, Oct 20, 2014 at 10:26 PM, Ulf Zibis mailto:ulf.zi...@cosoco.de>

Re: Review request: JDK-8055723 Replace concat String to append in StringBuilder parameters

Am 21.10.2014 um 01:02 schrieb Otávio Gonçalves de Santana: BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055723 WEBREV: http://cr.openjdk.java.net/~weijun/8055723/client/webrev.02/ WEBREV: http://cr.openjdk.java.net/~weijun/8055723/core/webrev.03/ I did not look through all sources. In

Re: RFR JDK-6321472: Add CRC-32C API

Am 18.10.2014 um 00:38 schrieb Staffan Friberg: Hi Ulf, Since the default method only calls a single method it will most likely be inlined. After inlining the check will be if (0 < 0 || b.length < 0 || 0 > b.length - b.length) { throw new ArrayIndexOutOfBoundsException();

Re: RFR JDK-6321472: Add CRC-32C API

Am 17.10.2014 um 20:58 schrieb Staffan Friberg: Here is a new webrev with the updates from Alan's and Peter's suggestions. http://cr.openjdk.java.net/~sfriberg/JDK-6321472/webrev.01 I would not remove: 86 public void update(byte[] b) { 87 adler = updateBytes(adler, b, 0, b.l

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

Am 24.09.2014 um 22:25 schrieb Peter Levart: Hi, String.hashCode() caches the result, so repeatable call to same String instance is faster for 2nd and further invocations. But the computation of hash code itself could be accelerated for a factor of 2 or more on todays CPUs. How? By paralleliz

Re: Lower overhead String encoding/decoding

Compare with https://bugs.openjdk.java.net/browse/JDK-6695386 Maybe that would help a little. -Ulf Am 22.09.2014 um 13:25 schrieb Richard Warburton: Hi all, A long-standing issue with Strings in Java is the ease and performance of creating a String from a ByteBuffer. People who are using nio

Re: RFR: 8058550: Clarify that TimerTasks are not reusable

Am 18.09.2014 um 20:54 schrieb Alan Bateman: On 18/09/2014 18:52, Martin Buchholz wrote: Hi Chris, I'd like you to do a code review. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/ https://bugs.openjdk.java.net/browse/JDK-8058550 This looks okay. If I were wording

Re: Missing clarity in TimerTask doc

Am 16.09.2014 um 00:47 schrieb Martin Buchholz: Maybe it could be extentend to: IllegalStateException - if task was already scheduled, cancelled or already done, timer was cancelled, or timer thread terminated. ... as I assume a TimerTask instance is never reusable. It's alrea

Re: Missing clarity in TimerTask doc

already done? -Ulf On Mon, Sep 15, 2014 at 10:47 AM, Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: Hi all, I'm missing clarity, if a j.u.TimerTask object can be scheduled more than once. Especially, can it be scheduled again with Timer.schedule(...) after it has been ca

Missing clarity in TimerTask doc

Hi all, I'm missing clarity, if a j.u.TimerTask object can be scheduled more than once. Especially, can it be scheduled again with Timer.schedule(...) after it has been cancelled, or has a new TimerTask object to be instantiated? What happens if a TimerTask is scheduled again before the first sc

Re: RFR: 8058230: Improve java.sql toString formatting

Maybe consider https://bugs.openjdk.java.net/browse/JDK-6914113 Especially note the last comment there. -Ulf Am 11.09.2014 um 16:44 schrieb Claes Redestad: Hi, requesting reviews for this patch which optimizes java.sql.Date/Time/Timestamp::toString by avoiding some unnecessary object allocati

Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

Am 08.09.2014 um 20:53 schrieb Jonathan Gibbons: For example, in the first few lines of the patch, I found this: Do you see any semantics change here? diff -r dde9f5cfde5f src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java --- a/src/share/classes/sun/tools/jconsole/inspector

Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

ave already partially modified the string buffer. -- Jon On 08/29/2014 01:53 PM, Ulf Zibis wrote: Hi compiler people, is there some chance that javac could be enhanced to optimize better as discussed in this thread? Than refactoring of up to now better readable code to ugly StringBuilder@appen

Re: Impact of code difference in Collection#contains() worth improving?

Zibis wrote: Am 30.08.2014 um 01:33 schrieb John Rose: On Aug 29, 2014, at 1:05 PM, Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: Thanks for explaining this, but a very little nit: the immediate (I.e. -1) uses additional 32/64 bits in code which must be loaded from memory and wastes sp

Re: Impact of code difference in Collection#contains() worth improving?

.net/browse/JDK-8056951 Can haz review please? On Fri, Aug 29, 2014 at 1:05 PM, Ulf Zibis wrote: Am 28.08.2014 um 19:46 schrieb Vitaly Davidovich: There's no register pressure - the immediate (I.e. -1) is encoded directly into the instruction, just like 0 would be. The time when 0 is particu

Re: Impact of code difference in Collection#contains() worth improving?

Am 29.08.2014 um 23:56 schrieb Martin Buchholz: Just think - one whole byte saved for each individual change! I have a webrev! http://cr.openjdk.java.net/~martin/webrevs/openjdk9/pico-optimize-contains/ https://bugs

Re: Impact of code difference in Collection#contains() worth improving?

Am 30.08.2014 um 01:33 schrieb John Rose: On Aug 29, 2014, at 1:05 PM, Ulf Zibis mailto:ulf.zi...@cosoco.de>> wrote: Thanks for explaining this, but a very little nit: the immediate (I.e. -1) uses additional 32/64 bits in code which must be loaded from memory and wastes space in CPU ca

Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

re like choosing the correct implementation rather than an optimization. I don't expect to see big change on this in the near future, so shall we go on with the current enhancement? Thanks Max On Aug 29, 2014, at 2:17, Ulf Zibis wrote: I mean: It does not output byte code that only us

Re: Impact of code difference in Collection#contains() worth improving?

code is unlikely to make any difference, unless jit is turned off and you're running this through a tight loop in the interpreter (but if one does that, perf conversation is moot :)). Sent from my phone On Aug 28, 2014 1:28 PM, "Ulf Zibis" mailto:ulf.zi...@cosoco.de>> wrote:

Re: Impact of code difference in Collection#contains() worth improving?

h existing code. That's what I wanted to point on. Does the original thread opener want to open a bug e.g. "Unify code of contains()"? If not, the discussion doesn't make sense anymore. -Ulf On Thu, Aug 28, 2014 at 10:27 AM, Ulf Zibis mailto:ulf.zi...@cosoco.de>>

Re: Replace concat String to append in StringBuilder parameters

gBuilder. -Ulf Am 27.08.2014 um 14:02 schrieb Pavel Rappo: Could you please explain what you mean by "javac optimization fails" here? -Pavel On 27 Aug 2014, at 10:41, Ulf Zibis wrote: 4.) Now we see, that javac optimization fails again if StringBuilder, concatenation, toSt

Re: Impact of code difference in Collection#contains() worth improving?

Am 27.08.2014 um 17:51 schrieb Martin Buchholz: The ArrayList version saves one byte of bytecode, and is therefore very slightly better. We should bless that version and use it consistently. +1 Additional argument: The LinkedList code requires to load 32/64-Bit -1 into CPU. This may take some

Re: RFR: 8055949: ByteArrayOutputStream capacity should be maximal array size permitted by VM

Am 25.08.2014 um 19:37 schrieb Martin Buchholz: https://bugs.openjdk.java.net/browse/JDK-8055949 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ByteArrayOutputStream-MAX_ARRAY_SIZE/ The 2x capacity gap was noticed by real users! Hi Martin, the MAX_ARRAY_SIZE code now is copied to many pl

Re: Replace concat String to append in StringBuilder parameters

uot;) should be translated to .append('x') + Javac could calculate a reasonable buffer size init value. -Ulf Am 11.08.2014 um 16:01 schrieb Ulf Zibis: Am 11.08.2014 um 15:12 schrieb Andrej Golovnin: In the most classes I mentioned in my previous mail only the #toString()-methods would be

Re: new StringBuilder(char)

Additionally nice to have: (initial capacity with initial char(s)) StringBuilder(int,char) StringBuilder(int,CharSequence) -Ulf Am 08.08.2014 um 22:53 schrieb Eddie Aftandilian: Hi all, We recently realized that calling new StringBuilder(char) does not do what you would think it does. Since

Re: new StringBuilder(char)

Good catch ;-) -Ulf Am 08.08.2014 um 22:53 schrieb Eddie Aftandilian:

Re: Replace concat String to append in StringBuilder parameters

Am 11.08.2014 um 16:33 schrieb Pavel Rappo: Unfortunately, neither java.util.StringJoiner nor String.join have perfect (but who has?) APIs. So it's up to us to figure out the best way of joining elements. Maybe remember my thoughts from here: http://mail.openjdk.java.net/pipermail/core-libs-d

Re: Replace concat String to append in StringBuilder parameters

Am 11.08.2014 um 15:12 schrieb Andrej Golovnin: In the most classes I mentioned in my previous mail only the #toString()-methods would be affected by the proposal. And in the most cases, maybe in all cases, the #toString()-methods in this classes exists only to provide nice output. So why not

Re: Replace concat String to append in StringBuilder parameters

Am 11.08.2014 um 01:03 schrieb Claes Redestad: - in places like src/share/classes/sun/security/provider/PolicyFile.java you end up with a sequence of String literal appends which could be merged into one: -sb.append(principalInfo[i][0] + " " + -"\"" + prin

Re: Replace concat String to append in StringBuilder parameters

Hi Otávio, this is a great proposal. Little nit: In cases where only 1 character is to append, I guess append(char) would be faster and at least will save footprint in contrast to append(String). -Ulf Am 10.08.2014 um 23:33 schrieb Otávio Gonçalves de Santana: *Motivation:* Make another ap

Re: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

Additionally I think, instead of retrieving String lang = locale.getLanguage() multiple times in chain, we could pass "lang" to the methods instead "locale". -Ulf Am 17.07.2014 11:54, schrieb Ulf Zibis: There is again another little optimization possible: instead

Re: RFR: JDK-8042589: String.toLowerCase do not work for some concatenated strings

There is again another little optimization possible: instead hasSurr = true; we could use first = ~first; and save variable hasSurr. If there is register pressure (especially on older CPUs), this might be a performance advantage. Also I think we should not grow the result array for any

Re: Covariant overrides on the Buffer Hierachy

Am 02.05.2014 18:13, schrieb Joe Darcy: On 5/2/2014 9:10 AM, Ulf Zibis wrote: Am 01.05.2014 02:20, schrieb Joe Darcy: If from an API perspective the new code is preferable, I would say that should take precedence over an at most marginal performance degradation. I guess you meant

Re: Covariant overrides on the Buffer Hierachy

Am 01.05.2014 02:20, schrieb Joe Darcy: Hello, I'm reminded of Professor Knuth's observation that "Premature optimization is the root of all evil." If from an API perspective the new code is preferable, I would say that should take precedence over an at most marginal performance degradation.

Re: Covariant overrides on the Buffer Hierachy

Hi Peter, Am 21.04.2014 13:10, schrieb Peter Levart: Since the public part of Buffer type hierarchy is (mostly) just two-level, an alternative would be to generify java.nio.Buffer: Hey wow, some time ago I also tried to find a compiling and working code in that sense, but I stranded. But wha

Re: Covariant overrides on the Buffer Hierachy

Hi again, one additional reason on top of my list from yesterday why I would prefer the language change: - Removing "final" is a performance decrease. -Ulf Am 20.04.2014 20:56, schrieb Richard Warburton: Hi, It looks to me like there are no obvious problems with changing the buffer subclas

Re: Covariant overrides on the Buffer Hierachy

Am 19.04.2014 10:09, schrieb Richard Warburton: Thanks for the feedback guys - its most appreciated and I'll take a look through the detailed linked you provided. Ulf posted several links, but these seem mostly related to language change Not all of them, but yes, mostly. proposals related to

Re: Covariant overrides on the Buffer Hierachy

Hi, Am 15.04.2014 10:05, schrieb Richard Warburton: Hi, I'd like to have a discussion about tidying up a few core library method signatures in a way that (I think) is backwards compatible. I've been using ByteBuffer quite a lot recently which is designed to be a fluent API. Unfortunately its q

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Am 10.04.2014 21:53, schrieb Tim Bell: On 04/10/14 19:26, Ulf Zibis wrote: BTW, where are these links gone: This part of the question I can handle. The six digit Bug numbers came from the legacy OpenJDK bugzilla instance. Before it was shut down, those bug reports were transferred to JBS

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Am 10.04.2014 21:53, schrieb Tim Bell: On 04/10/14 19:26, Ulf Zibis wrote: BTW, where are these links gone: This part of the question I can handle. The six digit Bug numbers came from the legacy OpenJDK bugzilla instance. Before it was shut down, those bug reports were transferred to JBS

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Am 10.04.2014 17:20, schrieb Xueming Shen: Looks fine. Personally I would prefer the "canonicalized/real" name "ISO-8859-1" though. Yep, using the canonical name guarantees best performance for the charset lookup. BTW, where are these links gone: Bug 100092 -- Speed-up FastCharsetProvider

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Correction ... Am 10.04.2014 12:03, schrieb Ulf Zibis: Hi Chris, Am 10.04.2014 11:04, schrieb Chris Hegarty: Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. In earlier tests Sherman and I have found

Re: JDK 9 RFR of 8039474: sun.misc.CharacterDecoder.decodeBuffer should use getBytes(iso8859-1)

Hi Chris, Am 10.04.2014 11:04, schrieb Chris Hegarty: Trivially, you could ( but of not have to ) use java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String to CharSet lookup. In earlier tests Sherman and I have found out, that the cost of initialization of a new charsets

Re: Implicit 'this' return for void methods

Hi, Am 02.04.2014 11:08, schrieb Andrew Haley: On 04/01/2014 10:20 PM, Eirik Lygre wrote: What is the relationship between this "naked dot" proposal and the "chaining of void methods" proposal? The reason for asking is not to be negative, but rather to find out if these issues are best dealt wi

Re: Implicit 'this' return for void methods

Am 01.04.2014 11:28, schrieb Bruce Chapman: Slightly preceding Ulf's coin proposal by a few hours was http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001134.html Where I suggested the "naked dot" notation (coined in http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000855.

Re: Implicit 'this' return for void methods

Am 28.03.2014 11:05, schrieb Florian Weimer: String mySub = myVeryLongNamedString.substring(.indexOf("C"),.indexOf("Q")); You can already write String mySub = apply(myVeryLongNamedString, (s) -> s.substring(s.indexOf("C"), s.indexOf("Q"))) with a helper function like this:

Re: Implicit 'this' return for void methods

Am 27.03.2014 23:05, schrieb Eirik Lygre: With this suggested change, the only behavior that will change is that some code which used to not compile will start compiling, with a reasonable result. No code that used to compile will change. Yes, this is one of the great advantages of this "simpl

Re: Implicit 'this' return for void methods

oid. So +1 for the language to figure this out. On Wed, Mar 26, 2014 at 10:51 AM, Guy Steele <mailto:guy.ste...@oracle.com>> wrote: On Mar 26, 2014, at 4:17 AM, Ulf Zibis wrote: > See also: > . . . > http://mail.openjdk.java.net/pipermail/coin-dev/2009-Mar

Re: Implicit 'this' return for void methods

See also: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001512.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-April/001365.html http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html -Ulf Am 25.03.2014 21:19, schrieb Victor Polischuk: Good day,

Re: Implicit 'this' return for void methods

See: https://bugs.openjdk.java.net/browse/JDK-6472931 https://bugs.openjdk.java.net/browse/JDK-6373386 https://bugs.openjdk.java.net/browse/JDK-6479372 https://bugs.openjdk.java.net/browse/JDK-4774077 https://bugs.openjdk.java.net/browse/JDK-6451131 https://bugs.openjdk.java.net/browse/JDK-5082736

  1   2   3   4   5   6   7   8   9   10   >