Re: Integrated: 8285736: JDK-8236128 causes validate-source failures

On Wed, 27 Apr 2022 16:53:44 GMT, Daniel D. Daugherty wrote: > A trivial fix for JDK-8236128 causes validate-source failures. Marked as reviewed by mikael (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8429

Re: RFR: 8285445: cannot open file "NUL:"

On Sat, 23 Apr 2022 01:11:56 GMT, Brian Burkhalter wrote: > Change the default value of the `jdk.io.File.enableADS` property to `true`. Marked as reviewed by mikael (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8373

Integrated: 8283059: Uninitialized warning in check_code.c with GCC 11.2

On Thu, 17 Mar 2022 20:56:34 GMT, Mikael Vidstedt wrote: > Note: this PR replaces the one I messed up earlier. > > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function > 'read_all_code': > src/java.base/share/native/libverify/chec

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2]

On Fri, 18 Mar 2022 02:10:32 GMT, David Holmes wrote: >> Mikael Vidstedt has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Use const char for check_and_push_string_utf > > src/java.base/share/native/l

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2]

on. > > To avoid having multiple ways of solving the same problem I also chose to > revert the change made in JDK-8266168, reverting the calloc back to a malloc > call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Mikael Vidstedt has updated the pull request incremental

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2

On Thu, 17 Mar 2022 20:56:34 GMT, Mikael Vidstedt wrote: > Note: this PR replaces the one I messed up earlier. > > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function > 'read_all_code': > src/java.base/share/native/libverify/chec

RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2

Note: this PR replaces the one I messed up earlier. Background, from JBS: src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] 942 |

Withdrawn: 8283059: Uninitialized warning in check_code.c with GCC 11.2

On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt wrote: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function > 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may > be used uninitiali

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2]

On Thu, 17 Mar 2022 20:36:31 GMT, Mikael Vidstedt wrote: >> Background, from JBS: >> >> src/java.base/share/native/libverify/check_code.c: In function >> 'read_all_code': >> src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' >> may

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2]

eeds to go through a > const conversion. > > To avoid having multiple ways of solving the same problem I also chose to > revert the change made in JDK-8266168, reverting the calloc back to a malloc > call. > > Testing: > > tier1 + builds-tier{2,

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2

On Thu, 17 Mar 2022 08:44:57 GMT, Kim Barrett wrote: >> src/java.base/share/native/libverify/check_code.c line 472: >> >>> 470: >>> 471: static void check_and_push(context_type *context, void *ptr, int kind); >>> 472: static void check_and_push_const(context_type *context, const void >>>

Re: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2

On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt wrote: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function > 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may > be used uninitiali

RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2

Background, from JBS: src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] 942 | check_and_push(context, lengths, VM_MALLOC_BLK);

Re: RFR: JDK-8273146: Start of release updates for JDK 19 [v2]

On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote: >> The time to get JDK 19 underway draws nigh, please review this usual set of >> start-of-release updates, including CSRs for the javac and javax.lang.model >> updates: >> >> JDK-8277512: Add SourceVersion.RELEASE_19 >>

Re: RFR: Merge jdk17 [v2]

On Mon, 2 Aug 2021 23:53:59 GMT, Jesper Wilhelmsson wrote: >> Forwardport JDK 17 -> JDK 18 > > Jesper Wilhelmsson has updated the pull request incrementally with one > additional commit since the last revision: > > Revert "8271150: Remove EA from JDK 17 version string starting with Initial

Re: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 [v2]

On Fri, 16 Apr 2021 20:12:45 GMT, Daniel D. Daugherty wrote: >> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: >> >> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 >> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 >> -

Re: RFR: 8265358: ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64

On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty wrote: > A set of trivial ProblemListing for macos-aarch64 Tier2 test failures: > > - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64 > - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64 > -

Integrated: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64

On Tue, 13 Apr 2021 06:55:33 GMT, Mikael Vidstedt wrote: > Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a > tier1 test) until JDK-8262897 is fixed. This pull request has now been integrated. Changeset: 2aae29c9 Author:Mikael Vidstedt URL:

RFR: 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64

Let's problem list java/util/concurrent/locks/Lock/TimedAcquireLeak.java (a tier1 test) until JDK-8262897 is fixed. - Commit messages: - 8265111: ProblemList java/util/concurrent/locks/Lock/TimedAcquireLeak.java on macosx-aarch64 Changes:

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

On Wed, 3 Feb 2021 20:08:28 GMT, Mikael Vidstedt wrote: >>> I wonder if this is the right choice >>> ... >>> ``` >>> OopStorageParIterPerf::~OopStorageParIterPerf() { >>> ... >>> ``` >>> >> >> The transition in OopSt

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

On Wed, 3 Feb 2021 20:05:29 GMT, Anton Kozlov wrote: >> Thank you all for your comments regarding W^X implementation. I've made a >> change that reduces the footprint of the implementation, also addressing >> most of the comments. I'll revisit them individually to make sure nothing is >>

Re: RFR: 8257450: Start of release updates for JDK 17

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote: > Start of JDK 17 updates. Marked as reviewed by mikael (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1531

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

Great to see this - thank you for all the great work you’re putting into it! The changes are in line with what I’m expecting given that I’ve looked at them before, so looks good to me! That said, I’ve looked at this so many times now - and after all even authored some of the original changes

Re: RFR: 8249612 Remove unused ISNANF and ISNAND from jdk_util_md.h

Nice find! :) Cheers, Mikael > On Jul 16, 2020, at 6:34 AM, Alexander Scherbatiy > wrote: > > Hello, > > Could you review a simple clean up of jdk_util_md.h files: > Bug: https://bugs.openjdk.java.net/browse/JDK-8249612 > Fix: http://cr.openjdk.java.net/~alexsch/8249612/webrev.00 > >

Re: RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

The makefile changes look good to me! Cheers, Mikael > On Jun 16, 2020, at 12:22 PM, Erik Joelsson wrote: > > (re-sending this as it doesn't look like it was delivered) > > There are a lot of jtreg tests that use temporary files. These temporary > files add up over time and fill up the

Re: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy

Looks good, thanks for fixing! Cheers, Mikael > On May 29, 2020, at 7:01 PM, Brian Burkhalter > wrote: > > Please review this fix [1] for [2]. It in effect just backs out the recent > fix for [3]. I’ll investigate the root cause next week. > > Thanks, > > Brian > > [1]

Re: RFR(S): 8245600: Clean up libjli

> On May 22, 2020, at 4:27 AM, Alan Bateman wrote: > > > > On 22/05/2020 04:28, Mikael Vidstedt wrote: >> Please review this change which cleans up the libjli related files a bit: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245600 >> webrev:

RFR(S): 8245600: Clean up libjli

Please review this change which cleans up the libjli related files a bit: JBS: https://bugs.openjdk.java.net/browse/JDK-8245600 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245600/webrev.00/open/webrev/ Background: During the review of JDK-8244224 it was noticed that the

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

ld be fixed in webrev.01. Cheers, Mikael > >> On May 6, 2020, at 9:43 PM, Mikael Vidstedt > <mailto:mikael.vidst...@oracle.com>> wrote: >> >> >> I have always wondered what “solinux” is supposed to mean - though not >> enough to actually ask a

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 6, 2020, at 11:41 PM, Alan Bateman wrote: > > On 07/05/2020 05:56, Mikael Vidstedt wrote: >> : >> >> * File follow-up enhancement for the removal of SO_FLOW_SA and >> jdk.net.SocketFlow > I've created JDK-8244582 to track this, we should try t

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

) and SocketImpl stuff is good as-is Cheers, Mikael > On May 3, 2020, at 10:12 PM, Mikael Vidstedt > wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: > http://cr.openjdk.java.net/~mikae

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

5/4/20 4:49 AM, Alan Bateman wrote: >> On 04/05/2020 06:12, Mikael Vidstedt wrote: >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: >>> http://cr.openjdk.java.

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 5, 2020, at 5:42 AM, Daniel Fuchs wrote: > > Hi Mikael, > > I spotted another place where a residual reference to Solaris > remains in a comment: > src/java.base/unix/native/libnet/PlainSocketImpl.c > > 857 #if defined(_AIX) > 858 if (errno == EINVAL) { > 859 //

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 4, 2020, at 9:27 AM, naoto.s...@oracle.com wrote: > > Hi Mikael, > > I took a look at i18n related files. It looks good overall. > > One nit in java/nio/charset/Charset/DefaultCharsetTest.java: If the test is > only applicable to linux (@requires os.family == "linux" in jtreg tag

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

> On May 4, 2020, at 2:33 PM, Brent Christian > wrote: > > Hi, > > Looks fine to me. I have just one minor observation: > > src/java.base/share/native/libjli/emessages.h > > *** 92,102 > #define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process from a > %d-bit JVM." > !

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

Alan, thank you for the review! New webrev coming. Meanwhile comments inline.. > On May 4, 2020, at 1:49 AM, Alan Bateman wrote: > > On 04/05/2020 06:12, Mikael Vidstedt wrote: >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

Thank you for reviewing, Max! Cheers, Mikael > On May 4, 2020, at 7:22 AM, Weijun Wang wrote: > > There are several security-related files (name.contains("security")) and they > all look fine. > > --Max > > >> On May 4, 2020, at 1:12 PM, Mikae

RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries)

Please review this change which implements part of JEP 381: JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 Note: When reviewing this, please

Re: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests

> On Jun 5, 2019, at 2:57 AM, Alan Bateman wrote: > > > > On 05/06/2019 03:29, Mikael Vidstedt wrote: >> I, too, agree. :) >> >> New webrev which adds a new ProblemList-aot.txt to be used when running >> tests with AOT. >> >> Webrev: &g

Re: RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests

them into -graal >> specific problem list. >> >> -- Igor >> >>> On Jun 4, 2019, at 1:38 PM, Mikael Vidstedt >>> <mailto:mikael.vidst...@oracle.com> wrote: >>> >>> >>> The following java/lang/invoke/VarHandles test

RFR (XS): 8225305: ProblemList java/lang/invoke/VarHandles tests

The following java/lang/invoke/VarHandles tests frequently fail when run with AOT. Until https://bugs.openjdk.java.net/browse/JDK-8222445 has been fixed they should be problem listed.

Re: RFR (T): 8224042 Add private alignDown method to MappedByteBuffer

Looks good, thanks for doing it! Cheers, Mikael > On May 16, 2019, at 7:49 AM, Andrew Dinn wrote: > > Please review this trivial change to MapperByteBuffer which encapsulates > the page align down operation in a suitably named method. > > JIRA:

Re: RFR : 8221696: MappedByteBuffer.force method to specify range

Would it be worth putting the logic in an aptly named (private) method? Something like: ... private long alignDown(long address, long alignment) { return address & ; } ... long mapBase = alignDown(address, ps); … Cheers, Mikael > On May 13, 2019, at 9:14 AM, Andrew Dinn wrote: > >

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

in-line cast then that's >>> cleaner and easier to understand than replicating that structure in 3 files. >>> And of course, add a comment. >>> To make the source more readable, the cast could be factored >>> into a macro in the same file with the comment about

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

> > Roger > > > On 02/21/2019 11:07 PM, David Holmes wrote: >> On 22/02/2019 4:55 am, Mikael Vidstedt wrote: >>> >>> The wrapper based solution looks much cleaner to me as well. webrev.01 >>> looks good. >> >> Sorry I really don'

Re: RFR(XS): 8215009: GCC 8 compilation eror in libjli

The wrapper based solution looks much cleaner to me as well. webrev.01 looks good. (not a Reviewer) Cheers, Mikael > On Feb 21, 2019, at 9:55 AM, Dmitry Chuyko wrote: > > To me thread function wrappers look preferable to platform specific JavaMain > signature. Consider this webrev with

Re: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

Mandy, Igor - thanks! Change pushed to jdk12. Cheers, Mikael > On Jan 22, 2019, at 4:34 PM, Igor Ignatyev wrote: > > looks good. > > -- Igor > >> On Jan 22, 2019, at 4:30 PM, Mandy Chung wrote: >> >> +1 >> >> Mandy >> >>

Re: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

Cheers, Mikael > On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt > wrote: > > > Thanks Igor! Pushed. > > Cheers, > Mikael > >> On Jan 17, 2019, at 2:07 PM, Igor Ignatyev wrote: >> >> Mikael, >> >> looks good and trivial to me. >

Re: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

Thanks Igor! Pushed. Cheers, Mikael > On Jan 17, 2019, at 2:07 PM, Igor Ignatyev wrote: > > Mikael, > > looks good and trivial to me. > > -- Igor > >> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt >> wrote: >> >> >> Please review

RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

Please review this change which adds java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list until the main bug has been addressed. Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 Webrev:

Re: RFR(S): 8211350: Remove jprt support

hange. Cheers, Mikael > On Oct 2, 2018, at 8:40 AM, Mandy Chung wrote: > > > > On 10/2/18 12:21 AM, Mikael Vidstedt wrote: >> Please review this change which removes support for, and references to, the >> (Oracle internal) JPRT system. >> >> bug: http

RFR(S): 8211350: Remove jprt support

Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. bug: https://bugs.openjdk.java.net/browse/JDK-8211350 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ * Background (from the issue) The Oracle

Re: Review Request JDK-8210841: test/jdk/vm/runtime/ReflectStackOverflow.java fails with NoClassDefFoundError

Looks like a clean reverse of that file. Cheers, Mikael - not a Reviewer > On Sep 17, 2018, at 10:12 PM, mandy chung wrote: > > test/jdk/vm/runtime/ReflectStackOverflow.java fails and it's caused by > JDK-8210721. I propose to revert the change in InvocationTargetException > to give us time

Re: [11] RFR(XXS): 8206436: sun/nio/cs/TestIBMBugs.java no longer compiles

Fix the typo while at it? +// and [yen] an [overscore] are encoded to 0x5c and 0x7e an -> and Cheers, Mikael > On Jul 5, 2018, at 11:56 PM, Volker Simonis wrote: > > Hi, > > can I please have a review for this trivial test fix? > >

RFR: 8202330: Add Unreferenced{FOS,FIS,RAF}ClosesFd to problem list

The java/io/*/Unreferenced{FOS,FIS,RAF}ClosesFd tests are failing quite frequently and should be added to the problem list until the issue (tracked by https://bugs.openjdk.java.net/browse/JDK-8202292 ) has been resolved: Bug:

Re: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13

Which JBS issue is now covering the work of looking at the actual failure? Cheers, Mikael > On Apr 25, 2018, at 3:11 PM, Brian Burkhalter > wrote: > > Issue:https://bugs.openjdk.java.net/browse/JDK-8202284 > Patch:

RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods

As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, and the functionality is instead provided by the VM through j.i.m.Unsafe. The Bits wrapper methods are therefore redundant and can be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8149596 Webrev:

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 2016-02-10 02:03, Paul Sandoz wrote: On 10 Feb 2016, at 04:42, Mikael Vidstedt <mikael.vidst...@oracle.com> wrote: Can I please get a quick review of these updated webrevs: hotspot: http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.05/hotspot/webrev/ jdk

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

Feb 2016, at 06:27, John Rose <john.r.r...@oracle.com> wrote: On Feb 2, 2016, at 11:25 AM, Mikael Vidstedt <mikael.vidst...@oracle.com> wrote: Please review this change which introduces a Copy::conjoint_swap and an Unsafe.copySwapMemory method to call it from Java, along with the neces

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

unrolling. In terms of code-cache efficiency the intrinsic is better. Paul. On 4 Feb 2016, at 06:27, John Rose <john.r.r...@oracle.com> wrote: On Feb 2, 2016, at 11:25 AM, Mikael Vidstedt <mikael.vidst...@oracle.com> wrote: Please review this change which introduces a Copy::c

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 2016-02-04 04:22, Andrew Haley wrote: On 02/02/2016 07:25 PM, Mikael Vidstedt wrote: Please review this change which introduces a Copy::conjoint_swap and an Unsafe.copySwapMemory method to call it from Java, along with the necessary changes to have java.nio.Bits call it instead

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

On 2016-02-03 01:43, Andrew Haley wrote: On 02/02/16 19:25, Mikael Vidstedt wrote: Please review this change which introduces a Copy::conjoint_swap and an Unsafe.copySwapMemory method to call it from Java, along with the necessary changes to have java.nio.Bits call it instead of the Bits.c

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

Just an FYI: I'm working on moving all of this to the Hotspot Copy class and bridging to it via jdk.internal.misc.Unsafe, removing Bits.c altogether. The implementation is working, and the preliminary performance numbers beat the pants off of any of the suggested Bits.c implementations

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

code seems to be needed for now. Cheers, Mikael On 2015-11-25 13:32, Mikael Vidstedt wrote: Have you looked anything at the performance of the generated code? As you may have seen I was playing around with an alternative implementation[1] which has the benefit of being pure C++ without

Re: [RFR] (XS) 8144677: jprt.properties should allow creating a user specified testset with custom build flavors and build targets

Thumbs up! Cheers, Mikael On 2015-12-07 14:27, Chris Plummer wrote: Thanks David! Can I get a second reviewer please? thanks, Chris On 12/6/15 3:52 PM, David Holmes wrote: Hi Chris, On 5/12/2015 7:00 AM, Chris Plummer wrote: Hello, Please review the following:

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

This is as far as I got before I got interrupted: http://cr.openjdk.java.net/~mikael/NioBenchmark.java I haven't had time yet to verify that the benchmark code even measures the right thing, much less figure out why I get the performance impact with my fix. I can see many reasons why that

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

Have you looked anything at the performance of the generated code? As you may have seen I was playing around with an alternative implementation[1] which has the benefit of being pure C++ without compiler specific hints. That said, when I did some initial benchmarking of that it did seem like

Re: [9] RFR 8074840: Resolve disabled warnings for libjli and libjli_static

David/Kumar - thanks a lot for the reviews! I added a comment for the unsigned cast and pushed to jdk9/dev. Cheers, Mikael On 2015-04-01 16:17, David Holmes wrote: On 2/04/2015 3:22 AM, Mikael Vidstedt wrote: New webrev available here: http://cr.openjdk.java.net/~mikael/webrevs/8074840

Re: [9] RFR 8074840: Resolve disabled warnings for libjli and libjli_static

, Mikael Vidstedt wrote: Please review the following change which fixes a number of native compilation warnings in files related to libjli. Bug: https://bugs.openjdk.java.net/browse/JDK-8074840 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.01/webrev/ Mostly looks okay, but I find

[9] RFR 8074840: Resolve disabled warnings for libjli and libjli_static

Please review the following change which fixes a number of native compilation warnings in files related to libjli. Bug: https://bugs.openjdk.java.net/browse/JDK-8074840 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.01/webrev/ I built the code across all the OracleJDK

[9] RFR 8074839: Resolve disabled warnings for libunpack and the unpack200 binary

Please review the following change which fixes a number of native compilation warnings in the jdk.pack200 code. Bug: https://bugs.openjdk.java.net/browse/JDK-8074839 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8074839/webrev.03/webrev/ Testing: A slightly earlier version [1] has been

RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level

Please review the below change which adds support for running jtreg tests from the top level test/ directory using the 'make TESTDIRS=path jtreg_tests' syntax. The TESTDIRS syntax is already used in files like hotspot/test/Makefile and jdk/test/Makefile and allows for selecting which jtreg

Re: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level

I suppose a webrev helps: http://cr.openjdk.java.net/~mikael/webrevs/8050825/webrev.00/webrev/ Sorry 'bout that. Cheers, Mikael On 2014-07-15 19:48, Mikael Vidstedt wrote: Please review the below change which adds support for running jtreg tests from the top level test/ directory using

Re: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level

Perhaps adjust the top level make test target so that it invokes the test makefile with both the contents of TEST and TESTDIRS as two separate executions? This sounds like a very reasonable follow-up! Thanks for the review. Cheers, Mikael Mike On Jul 15 2014, at 19:51 , Mikael Vidstedt

Re: RFR(XS): 8050825: Support running regression tests using jtreg_tests+TESTDIRS from top level

Correct, the path needs to be on that format! Thanks for the review! Thanks, Mikael On 2014-07-15 20:15, David Holmes wrote: Looks okay to me. To be clear, the format of the path is not flexible but must have the form ../component/test/... David On 16/07/2014 12:51 PM, Mikael Vidstedt

Re: RFR(XS): 8047154: Testset all fails because of missing jdk_beansX test groups

Alan, David - thanks for the reviews! Cheers, Mikael On 2014-07-03 05:05, David Holmes wrote: +1 David On 3/07/2014 4:29 PM, Alan Bateman wrote: On 03/07/2014 02:24, Mikael Vidstedt wrote: Please review -- the jdk_beansX targets were removed as part of moving from Makefile logic to jtreg

RFR(XS): 8047154: Testset all fails because of missing jdk_beansX test groups

Please review -- the jdk_beansX targets were removed as part of moving from Makefile logic to jtreg test groups late last year and the all testset currently fails because of that. The only remaining beans group is called jdk_beans and this change reflects that change. Bug:

Re: AWT Dev RFR: Even more gcc warnings (8035287)

. Gosh .. that code must be from 1996 or thereabouts. I hope touching it doesn't mean I own it ;) Anything else I should do/test? Cheers, Mikael -phil. On 2/15/14 8:37 AM, Mikael Vidstedt wrote: Corrected link - this webrev is based on jdk9/client: http://cr.openjdk.java.net/~mikael

Re: AWT Dev RFR: Even more gcc warnings (8035287)

Thanks for the review Phil! Cheers, Mikael On 2014-02-18 17:37, Phil Race wrote: Anything else I should do/test? No. Sounds fine. -phil. On 2/18/14 5:30 PM, Mikael Vidstedt wrote: On 2014-02-15 09:31, Phil Race wrote: Looks OK to me although I just realised there's no bug ID here Bug

RFR: Even more gcc warnings

All, A drive-by set of warning fixes: http://cr.openjdk.java.net/~mikael/webrevs/jdk-warnings/jdk-warnings/webrev.00/ Highlights: * src/share/native/com/sun/java/util/jar/pack/bands.cpp Set the size of the array explicitly to increase likelihood of enum and struct array being in sync.

Re: RFR: Even more gcc warnings

Corrected link - this webrev is based on jdk9/client: http://cr.openjdk.java.net/~mikael/webrevs/jdk-warnings/webrev.01/webrev/ Cheers, Mikael On Feb 14, 2014, at 17:54, Mikael Vidstedt mikael.vidst...@oracle.com wrote: All, A drive-by set of warning fixes: http