Re: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux

> On Dec 2, 2019, at 2:54 AM, Julia Boes wrote: > > Updated webrev: http://cr.openjdk.java.net/~jboes/webrevs/8234964/webrev.01/ > LGTM -- Igor

Re: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux

Hi Julia, changes looks good to me. Thanks, Vyom On Mon, Dec 2, 2019 at 4:24 PM Julia Boes wrote: > Hi, > > > > to make it more consistent w/ other tools, I'd move all ifconfig (incl. > one on macOS) to 'net' category, i.e. rename them to net.ifconfig, this > will require also moving all netsta

Re: RFR: JEP 359: Records (Preview) (full code)

Hi Vicente, These comments are based on http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/ I looked over the core-libs and javax.lang.model changes. As a non-essential cleanup, in src/java.base/share/classes/java/io/ObjectOutputStream.java: 1444 final boolean

Re: RFR: JEP 359: Records (Preview) (full code)

On 3/12/2019 11:08 am, John Rose wrote: On Dec 2, 2019, at 4:36 PM, David Holmes > wrote: You are using CHECK_0 in RecordComponent::create but that method returns oop. That seems wrong to me, but I see many other oop returning methods also use CHECK_0 so I'll ta

Re: RFR: JEP 367: Remove the Pack200 Tools and API

Hi Vicente, It looks like the update to make/data/symbols/symbols removes the jdk.pack module from the history JDKs 9, 10, and 11 when --release is used. If that is the case, it would be incorrect since historically the jdk.pack module was present in those releases. Thanks, -Joe On 11/22/

Re: RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

Hi Christoph, Can you please post your updated patch for review and I will use it to check the fix for our internal build. Once you have your fix reviewed I will push both fixes together. Thanks, David On 25/11/2019 10:41 pm, David Holmes wrote: Hi Christoph, On 25/11/2019 10:38 pm, Langer

Re: RFR: JEP 359: Records (Preview) (full code)

On Dec 2, 2019, at 4:36 PM, David Holmes wrote: > > You are using CHECK_0 in RecordComponent::create but that method returns oop. > That seems wrong to me, but I see many other oop returning methods also use > CHECK_0 so I'll take that up separately. (It's only a cosmetic issue.) CHECK_NULL is

Re: RFR: JEP 359: Records (Preview) (full code)

Hi Vicente, I have also re-examined all the hotspot related code and everything looks fine - and very neat (kudos to you and Harold!). A couple of nits: src/hotspot/share/classfile/classFileParser.cpp src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp Typo: + //u2 attributs_count;

[JDK 8] Class.getName() slows down String concatenation chain

Hello, recently I've run into an issue regarding String concatenation. This benchmark summarizes it: @OutputTimeUnit(TimeUnit.NANOSECONDS) public class BrokenConcatenationBenchmark { @Benchmark public String slow(Data data) { final Class clazz = data.clazz; return "class " + clazz.g

request for sponsor: wavl based alternative to red-black TreeMap

Hello, is anybody interested in sponsoring me on exploring a wavl tree implementation of TreeMap [1]? For some reason related to gmail, I'm not able to get messages targeted to the mailing list alone, so please cc: me as well. Greetings Raffaello (Here are some highlights of wavl trees:

Re: RFR: JEP 359: Records (Preview) (full code)

I've looked over the hotspot code again as well.  Looks good, you have my review! Lois On 12/2/2019 11:52 AM, coleen.phillim...@oracle.com wrote: (resending to all the lists) Hi, I've looked at the hotspot code again, and it looks good. Nice work, Harold and Vincente! Coleen On 11/27/19 1

Re: RFR: JEP 359: Records (Preview) (full code)

Hi Vicente, I’ve looked at the Javadoc changes again, everything looks good to me. Hannes > Am 28.11.2019 um 05:37 schrieb Vicente Romero : > > Hi, > > Please review the code for the records feature at [1]. This webrev includes > all: APIs, runtime, compiler, serialization, javadoc, and more!

Re: RFR: JEP 359: Records (Preview) (full code)

thanks Joe, Vicente On 12/2/19 1:17 AM, Joe Darcy wrote: Hi Vicente, I took the liberty of adding the necessary directory-level jtreg config files to enable the feature and updated the tests accordingly:     https://hg.openjdk.java.net/amber/amber/rev/c91826d62310 (The feature is enabled b

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

> On Dec 2, 2019, at 3:33 PM, Severin Gehwolf wrote: > > On Mon, 2019-12-02 at 14:26 -0500, Bob Vandette wrote: >>> On Dec 2, 2019, at 2:03 PM, Severin Gehwolf wrote: >>> >>> Hi Bob, >>> >>> On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: Sorry for the delay in responding. See

Re: New candidate JEP: 370: Foreign-Memory Access API

On Dec 1, 2019, at 8:07 AM, David Lloyd wrote: > > Okay, anyway I'm glad that I'm not the first person to have thought of > these use cases. The API looks good! Thanks for reviewing and commenting! We need to “shake out” our designs exactly like that. — John

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

On Mon, 2019-12-02 at 14:26 -0500, Bob Vandette wrote: > > On Dec 2, 2019, at 2:03 PM, Severin Gehwolf wrote: > > > > Hi Bob, > > > > On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: > > > Sorry for the delay in responding. See comments below: > > > > Thanks very much for taking a look a

RE: [EXTERNAL] Re: JDK-8234076 bug fix candidate

Hi Alan and Henry, Thank you for reviewing my email! Henry's observation matches mine, the shared common code for all platforms in checkArg (src/java.base/share/native/libjli/args.c) can potentially leave the firstAppArgIndex static set to -1, if all passed command line arguments are prefixed

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

> On Dec 2, 2019, at 2:03 PM, Severin Gehwolf wrote: > > Hi Bob, > > On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: >> Sorry for the delay in responding. See comments below: > > Thanks very much for taking a look at this! > >>> On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: >>

Re: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation

This makes it very difficult to do more than a cursory re-review. There is one thing I just spotted. I believe these two scripts http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jdk/tools/jpackage/test_jpackage.sh.html http://cr.openjdk.java.net/~herrick/8212780/webrev.EA-11/test/jd

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

Hi Bob, On Mon, 2019-12-02 at 12:13 -0500, Bob Vandette wrote: > Sorry for the delay in responding. See comments below: Thanks very much for taking a look at this! > > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: > > > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: > > > H

Re: JDK-8234076 bug fix candidate

The fix looks reasonable to me, basically, if the command argument format is not legal, it’s possible we won’t find the main class when doing argument file expansion, and the index is -1 which could cause crash on Windows platform for the wildcard processing. I think we should add a test case f

Re: [PING] RFR: 8231111: Cgroups v2: Rework Metrics in java.base so as to recognize unified hierarchy

Sorry for the delay in responding. See comments below: > On Nov 29, 2019, at 4:05 AM, Severin Gehwolf wrote: > > On Fri, 2019-11-15 at 17:51 +0100, Severin Gehwolf wrote: >> Hi, >> >> Could I please get reviews of these core-libs, Linux-only, changes to >> the Metrics subsystem? This patch imp

Re: RFR: JEP 359: Records (Preview) (full code)

(resending to all the lists) Hi, I've looked at the hotspot code again, and it looks good.  Nice work, Harold and Vincente! Coleen On 11/27/19 11:37 PM, Vicente Romero wrote: Hi, Please review the code for the records feature at [1]. This webrev includes all: APIs, runtime, compiler, seri

RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi, I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport): https://bugs.openjdk.java.net/browse/JDK-8220348 Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer. jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires

Re: [14] RFR (S): 8234923: Missed call_site_target nmethod dependency for non-fully initialized ConstantCallSite instance

Thank you, John. Best regards, Vladimir Ivanov On 30.11.2019 02:30, John Rose wrote: Reviewed. On Nov 29, 2019, at 7:55 AM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8234923/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8234923

Re: RFR: 8234964: failure_handler: gather more environment information on Windows, Solaris and Linux

Hi, to make it more consistent w/ other tools, I'd move all ifconfig (incl. one on macOS) to 'net' category, i.e. rename them to net.ifconfig, this will require also moving all netstat.* on macOS and solaris to 'net' as well. I don't insist on it, though. Good point, I made those changes.

Re: JDK-8234076 bug fix candidate

On 20/11/2019 19:42, Nikola Grcevski wrote: : Please let me know if this approach is acceptable for the current bug report and I'll make a webrev and include appropriate launcher tests. I was thinking the tests should do extra validation on the output from _JAVA_LAUNCHER_DEBUG on Windows. I