Re: RFR for 6443578 and 6202130: UTF-8 in Manifests

Hi Philipp, Thanks for your patience :-) I will get back to you with my feedback the next couple days. -Sherman On 5/2/18, 6:12 PM, Philipp Kunz wrote: Hi, Here is patch for 6443578 and 6202130 also in webrev form. http://files.paratix.ch/jdk/6372077and6443578/webrev.01/

[JDK 11] RFR 8202575: Remove java/lang/String/nativeEncoding/StringPlatformChars.java from ProblemList

java/lang/String/nativeEncoding/StringPlatformChars.java This test was problem listed due to execution environment issue (-nativepath was not set) on Solaris and Windows platforms (JDK-8182569). This is not an issue anymore, test PASS on all platform in CI system. Please review the patch to

Re: RFR for 6443578 and 6202130: UTF-8 in Manifests

Hi, Here is patch for 6443578 and 6202130 also in webrev form. http://files.paratix.ch/jdk/6372077and6443578/webrev.01/ http://files.paratix.ch/jdk/6372077and6443578/webrev.01.zip Hope it helps. With all the patience, can I do anything to make it easier to get feedback or find a sponsor?

Re: RFR: Here are some easy patches

On Wed, May 2, 2018 at 2:43 PM, Michael Rasmussen < michael.rasmus...@roguewave.com> wrote: > But getComponentType itself calls isArray, so you are paying the native > method overhead anyway (though it is intrinsic). > Ohhh, I had forgotten I had looked at getComponentType earlier. So calling

Re: RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue

On 4/30/18 5:49 AM, Claes Redestad wrote: Hi, please review this patch to enable caching of getCanonicalName and getSimpleName, repeated calls of which has been reported to be a performance bottleneck. The caching improves performance of these methods by up to 20x. Rather than adding new

Re: RFR: Here are some easy patches

But getComponentType itself calls isArray, so you are paying the native method overhead anyway (though it is intrinsic). I haven't dug further into the JIT generated code to see why isArray performs better though. /Michael From: Martin Buchholz

Re: RFR: Here are some easy patches

Michael, Thanks. This may be tricky. isArray is a native method, and we don't want to pay for native method overhead - we're depending on hotspot intrinsification. I suspect isArray will lose with -Xint and perhaps also with C1. In the hotspot sources I see an ominous virtual bool

Re: RFR: Here are some easy patches

Hi Martin, Did you consider using Class::isArray in the loop? Something like the following: for (Object element : a) { final int elementHash; if (element == null) { elementHash = 0; } else { final Class cl = element.getClass(); if (!cl.isArray()) elementHash =

Re: Charsets for hex/base64

FYI here’s the javadoc for a draft of the Hex API that Alan mentioned below: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.05/api/java.base/java/util/Hex.html Thanks. > On 2 May 2018, at 10:55, Jonas Konrad wrote: > > I did not know about the old HexDumpEncoder. It extends

Re: RFR: Here are some easy patches

Hi Paul, On Mon, Apr 30, 2018 at 2:03 PM, Paul Sandoz wrote: > > > On Apr 30, 2018, at 11:18 AM, Martin Buchholz wrote: > > > > On Mon, Apr 30, 2018 at 10:35 AM, Paul Sandoz > wrote: > >> An obvious optimization: >> >>

CSR 8202555: Double.toString(double) sometimes produces incorrect results

The CSR [1] of [2] is now available for review. If you have comments, please reply to this thread. If you have JBS access you can add comments directly to the issue, but please also comment here for the benefit of those who cannot receive automated JBS updates. Thanks to Raffaello for

Re: Charsets for hex/base64

> On May 2, 2018, at 4:35 PM, Jonas Konrad wrote: > > "0a0b0c".getBytes(HexCharset.getInstance()) = new byte[] { 0x0a, 0x0b, 0x0c } > new String(new byte[] { 0x0a, 0x0b, 0x0c }, HexCharset.getInstance()) = > "0a0b0c" Normally a charset is to encode a string to byte[], but here

RFR: 8202548: Use reservation Object when creating SpeciesData

Hi, a small follow-up to JDK-8202184 in line with Peter Levart's suggestion, where we can avoid instantiating two different SpeciesData objects, and should avoid creating an instance of the Function on each lookup: Webrev: http://cr.openjdk.java.net/~redestad/8202548/open.00/ Bug:

Re: RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue

On 2018-04-30 23:28, Paul Sandoz wrote: I am not quite 100% sure but you could probably replace the null sentinel value with “/“ or opportunistically “[]”, but i cannot quite tell what exactly is an invalid binary name. Anyway that is not important. I tried reading the relevant parts of the

Re: RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue

Hi, On 2018-04-30 23:50, David Holmes wrote: Hi Claes, On 30/04/2018 10:49 PM, Claes Redestad wrote: Webrev: http://cr.openjdk.java.net/~redestad/8187123/open.02/ Given String's are immune to unsafe publication races, you should be able to drop the volatile modifiers. That might save a few

Re: [11] RFR for JDK-8202544: Hide unused exports in libzip

Looks good to me, FWIW. /Magnus > 2 maj 2018 kl. 13:52 skrev Alexey Ivanov : > > Hi, > > Could you please review the following fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8202544 > webrev:

[11] RFR for JDK-8202544: Hide unused exports in libzip

Hi, Could you please review the following fix for jdk11? bug: https://bugs.openjdk.java.net/browse/JDK-8202544 webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/ The following exported functions in libzip are not used: ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock,

Re: Charsets for hex/base64

I did not know about the old HexDumpEncoder. It extends an internal class `CharacterEncoder` which seems to be pretty similar purpose-wise to what I am suggesting with CharsetEncoder. There is also the good old `DatatypeConverter.printHexBinary`, though it can't stream. But this is not really

Re: Charsets for hex/base64

On 02/05/2018 09:35, Jonas Konrad wrote: Hi, Conceptually, a 'charset' (in java) is a pair of transformations from bytes to utf-16 code units and vice versa. Could it be useful to have charset implementations that convert from bytes to the hex (or base64) representations of those? The idea

Re: RFR(XS): 8202329 [AIX] Fix codepage mappings for IBM-943 and Big5

Hi Bhaktavatsal Reddy, your change looks good. I can sponsor it. Just waiting for a second review... Thank you and best regards, Volker On Mon, Apr 30, 2018 at 11:29 AM, Bhaktavatsal R Maram wrote: > Hi All, > > Please review the fix. > > bug:

Charsets for hex/base64

Hi, Conceptually, a 'charset' (in java) is a pair of transformations from bytes to utf-16 code units and vice versa. Could it be useful to have charset implementations that convert from bytes to the hex (or base64) representations of those? The idea is as follows:

Re: Hashing files/bytes Re: RFR(JDK11/NIO) 8202285: (fs) Add a method to Files for comparing file contents

- Mail original - > De: "John Rose" > À: "Remi Forax" > Cc: "Paul Sandoz" , "nio-dev" > , "core-libs-dev" > > Envoyé: Mercredi 2 Mai 2018 07:35:38 > Objet: Re: