Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

* Magnus Ihse Bursie: > Maybe we should have a common library for all native code where we > supply our own string operation functions? It will then be much easier > to make sure the implementation passes different compiler versions, > and that we provide sane semantics (which isn't really the  c

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

> On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie > wrote: > > On 2020-09-01 11:46, Kim Barrett wrote: >> I really hate -Wstringop-truncation. It's been a constant source of churn >> for us ever since it appeared. The changes being made to getIndex and >> getFlags (NetworkInterface.c) are modif

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

> On Sep 2, 2020, at 3:19 AM, Florian Weimer wrote: > > * Magnus Ihse Bursie: > >> Maybe we should have a common library for all native code where we >> supply our own string operation functions? It will then be much easier >> to make sure the implementation passes different compiler versions,

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

Hi, On 02/09/2020 08:19, Florian Weimer wrote: At least one of the bugs was in theory user-visible: the network interface code would return data for an interface that does not actually exist on the system. WRT NetworkInterface.c, I might support using `strnlen` to check the length before hand,

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

Hi Aleksei, On 09/01/20 19:41 pm, Aleksei Voitylov wrote: > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Propos

Re: RFR(S): 8252407: Build failure with gcc-8+ and asan

On 2020-09-02 09:50, Kim Barrett wrote: On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie wrote: On 2020-09-01 11:46, Kim Barrett wrote: I really hate -Wstringop-truncation. It's been a constant source of churn for us ever since it appeared. The changes being made to getIndex and getFlags (

RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Hi, here's a patch for [1], which is currently unassigned. Anybody willing to sponsor it? The fix is based on "Hacker's Delight" (2nd ed), section 9.3 and makes use of longs only, no BigInteger, no garbage to collect. It is faster and "greener" than the current code. Contrary to the dramat

Re: jpackage: support for environment variables in --java-options

Yes - environment variables are not a good answer for this, not just mac, but even on windows the env variables at run time are different if launched from a shell (the env variables of that shell) vs. when run from a shortcut (the system-wide or user env variables set in Control Panel or Settin

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Hi Raffaello, I can take a look. Did you write any (JMH?) microbenchmarks? Thanks, Brian > On Sep 2, 2020, at 5:52 AM, Raffaello Giulietti > wrote: > > here's a patch for [1], which is currently unassigned. Anybody willing to > sponsor it? > > The fix is based on "Hacker's Delight" (2nd ed

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Hi Brian, thanks for taking a look. I didn't write JMH benchmarks. Greetings Raffaello On 2020-09-02 16:25, Brian Burkhalter wrote: Hi Raffaello, I can take a look. Did you write any (JMH?) microbenchmarks? Thanks, Brian On Sep 2, 2020, at 5:52 AM, Raffaello Giulietti mailto:raffaello

Re: jpackage: support for environment variables in --java-options

> On Sep 2, 2020, at 9:04 AM, Andy Herrick wrote: > > Yes - environment variables are not a good answer for this, not just mac, but > even on windows the env variables at run time are different if launched from > a shell (the env variables of that shell) vs. when run from a shortcut (the >

Re: RFR 8252538: Replace @exception with @throws java.rmi package

Hi Roger, On Tue, Sep 1, 2020 at 10:49 PM Roger Riggs wrote: > Hi Vipin, > > Looks fine. > > Though I would also correct the indentation and join source lines in a > few cases. > > MasrshalledObject.java. Continuation lines should be indented. Lines > 110 and 164, 166. > Fixed. > > Naming.java

Re: jpackage: support for environment variables in --java-options

Not sure if it was clear from my previous messages, but what I am asking for is that the environment variables are expanded with the values they have on the user's machine (not on the machine where jpackage has been executed). Am Di., 1. Sept. 2020 um 08:37 Uhr schrieb Serban Iordache < serban.ior

Re: jpackage: support for environment variables in --java-options

Thanks, Michael! I maintain two Gradle plugins that help creating custom images and packages with jlink and jpackage (https://github.com/beryx/badass-jlink-plugin and https://github.com/beryx/badass-runtime-plugin). The request for supporting environment variables came from my users. They have act

Re: jpackage: support for environment variables in --java-options

If your app need to use environment variables to configure something for runtime it is probably best to have your own stub launcher and launch a sub-process. It can be tricky to have a smooth user experience with that though. You would want to avoid an extra icon in the dock/start bar. You do

Re: jpackage: support for environment variables in --java-options

> On Sep 2, 2020, at 12:14 PM, Scott Palmer wrote: > > If your app need to use environment variables to configure something for > runtime it is probably best to have your own stub launcher and launch a > sub-process. They need to be available at runtime for external native that expects th

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Hello, I also suggest taking a look at the existing regression tests in     test/jdk/java/lang/Long/Unsigned.java to see if more cases should be added with the new algorithm. Potentially, the existing algorithm could retire to serve as a reference in the regression tests. Thanks, -Joe On

RFR 8251989: Hex formatting and parsing

Please review the updated API in the Javadoc. http://cr.openjdk.java.net/~rriggs/hex-formatter/java.base/java/util/Hex.html A few offline contacts encouaged me to explore expanding the support for formatting and parsing of primitive types. Adding formatting toHex methods and [arsing fromHex metho

Re: RFR 8252538: Replace @exception with @throws java.rmi package

Hi Vipin, Looks fine. I see you filed separate tasks for the other packages in java.rmi. [1] That's unnecessarily fine grained. It would be more efficient to do them all in one code review, saving your time and reviewers time. Also, I noticed that those files still use the markup. Convertin

Re: RFR: 8188055: (ref) Add Reference.refersTo predicate

On 8/25/20 10:11 PM, Kim Barrett wrote: Finally getting back to this after some internal discussion that dragged along because folks have been busy. On Apr 8, 2020, at 12:05 PM, Gil Tene wrote: Lifting out of response from the JIRA issue: I always worry when proposing a change to an exist

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Hi Joe, will do in the next days, hopefully before the transition to Skara. I'll also add JMH results. Greetings Raffaello On 2020-09-02 21:17, Joe Darcy wrote: Hello, I also suggest taking a look at the existing regression tests in     test/jdk/java/lang/Long/Unsigned.java to see if mo

Re: RFR 8251989: Hex formatting and parsing

I still want to know how to format a byte sequence where each byte has a prefix (or suffix). Eg. { 0x00, 0x01, 0x02, 0xOD, 0x0E, 0x0F } Douglas > On Sep 2, 2020, at 2:26 PM, core-libs-dev-requ...@openjdk.java.net wrote: > > Date: Wed, 2 Sep 2020 16:26:07 -0400 > From: Roger Riggs mail

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Good move. ;-) Brian > On Sep 2, 2020, at 2:26 PM, Raffaello Giulietti > wrote: > > will do in the next days, hopefully before the transition to Skara.

Re: jpackage: support for environment variables in --java-options

There is already a way to supply a custom Info.plist. That can have the LSEnvironment entries you want. https://bugs.openjdk.java.net/browse/JDK-8233175 I was under the impression that we were after something that would allow different values

Re: RFC: 8229469 JEP 386: Alpine Linux/x64 Port

Hi Aleksei, Overall this all seems okay. A few minor comments below. On 1/09/2020 9:41 pm, Aleksei Voitylov wrote: Hi, JEP 386 is now Candidate [1] and as we resolved all outstanding issues within the Portola project I'd like to ask for comments from HotSpot, Core Libs (changes in libjli/java_