On Mon, 23 May 2022 12:27:40 GMT, Jorn Vernee wrote:
> Bring in changes from the panama-foreign repo
>
> These changes pertain to explicitly rejecting unsupported call shapes on
> macos-aarch64.
>
> Original PRs:
> 1. https://github.com/openjdk/panama-foreign/pull/676
> 2. https://github.com/o
On Mon, 16 May 2022 07:21:27 GMT, Ningsheng Jian wrote:
> This is the REDO of JDK-8269559 and JDK-8275448. Those two backouts finally
> turned to be some system zlib issue in AArch64 macOS, and is not related to
> the patch itself. See [1][2] for details.
>
> This patch is generally the same a
On Thu, 12 May 2022 14:53:03 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This PR updates the VM implementation of the foreign linker, by bringing
>> over commits from the panama-foreign repo.
>>
>> This is split off from the main JEP integration for 19, since we have
>> limited resources to handle t
On Thu, 12 May 2022 13:07:24 GMT, David Holmes wrote:
>> I think the Arm Ltd one was probably changed by me in one of the PRs in the
>> Panama repo.
>
> That's fine, just needed to check. But as these are now being committed to
> mainline the year does need to change to 2022 - at least in Oracl
On Thu, 12 May 2022 03:34:19 GMT, David Holmes wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 26 commits:
>>
>> - Block async exceptions during upcalls
>> - Merge branch 'foreign-preview-m' into JEP-19-VM-
On Thu, 5 May 2022 05:47:47 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> Patch adds the planned support for new vector operations and APIs targeted
>> for [JEP 426: Vector API (Fourth
>> Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>>
>> Following is the brief summary of chang
On Thu, 25 Nov 2021 11:57:52 GMT, Stuart Monteith wrote:
> Fix java/lang/ThreadOnSpinWaitProducerConsumer by waiting for consumer thread
> to finish before restarting trial method.
Marked as reviewed by ngasson (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6560
On Thu, 4 Nov 2021 15:56:46 GMT, Paul Sandoz wrote:
>> This PR improves the performance of vector operations that accept masks on
>> architectures that support masking in hardware, specifically Intel AVX512
>> and ARM SVE.
>>
>> On architectures that do not support masking in hardware the same
On Wed, 20 Oct 2021 00:22:30 GMT, Paul Sandoz wrote:
>> This PR improves the performance of vector operations that accept masks on
>> architectures that support masking in hardware, specifically Intel AVX512
>> and ARM SVE.
>>
>> On architectures that do not support masking in hardware the sam
On Thu, 14 Oct 2021 09:31:11 GMT, Andrew Haley wrote:
> It might be a spurious failure, then. I guess we need to see the test logs.
I'll revert it for in now in case we missed something.
-
PR: https://git.openjdk.java.net/jdk/pull/5941
On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote:
> This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE"
> which caused some unknown failures in Oracle's CI.
This pull request has now been integrated.
Changeset: 333c4692
Author:Nick Gass
On Thu, 14 Oct 2021 08:24:41 GMT, Andrew Haley wrote:
> > The issue is only on (some of) our macOS Aarch64 systems. Let me know if I
> > can provide more info on hardware etc.
>
> Any info about what failed? A reproducer would be nice.
I just ran tier1 on an M1 Mac with no failures - perhaps i
On Thu, 14 Oct 2021 06:48:18 GMT, David Holmes wrote:
>> This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE"
>> which caused some unknown failures in Oracle's CI.
>
> Thanks for attending to this so quickly @nick-arm !
>
> The issue is only on (some of) our macOS Aarch64
This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE"
which caused some unknown failures in Oracle's CI.
-
Commit messages:
- 8275262: Backout JDK-8269559
Changes: https://git.openjdk.java.net/jdk/pull/5941/files
Webrev: https://webrevs.openjdk.java.net/?repo=
On Thu, 14 Oct 2021 01:17:17 GMT, TatWai Chong wrote:
>> This patch implements string_compare intrinsic in SVE.
>> It supports all LL, LU, UL and UU comparisons.
>>
>> As we haven't found an existing benchmark to measure performance impact,
>> we created a benchmark derived from the test [1] for
On Mon, 30 Aug 2021 06:26:01 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(
On Mon, 30 Aug 2021 06:26:01 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(
On Fri, 6 Aug 2021 09:50:54 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(s
On Mon, 23 Aug 2021 21:48:01 GMT, TatWai Chong
wrote:
>> This patch implements string_compare intrinsic in SVE.
>> It supports all LL, LU, UL and UU comparisons.
>>
>> As we haven't found an existing benchmark to measure performance impact,
>> we created a benchmark derived from the test [1] fo
On Mon, 16 Aug 2021 20:59:55 GMT, TatWai Chong
wrote:
> This patch implements string_compare intrinsic in SVE.
> It supports all LL, LU, UL and UU comparisons.
>
> As we haven't found an existing benchmark to measure performance impact,
> we created a benchmark derived from the test [1] for thi
On Tue, 3 Aug 2021 13:33:07 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(s
On Fri, 30 Jul 2021 10:36:01 GMT, Andrew Haley wrote:
>
> I was (still am) tempted to approve it, but Nick says there are still bugs in
> corner cases.
>
I meant the earlier String.compareTo that this is partially replacing. This one
might be fine but I just wanted to check it had be thoroug
On Wed, 28 Jul 2021 09:29:25 GMT, Wu Yan wrote:
>
> We are testing on HiSilicon TSV110, maybe we can enable this optimization by
> default on the verified platforms.
We don't really want to have different implementations for each
microarchitecture, that would be a testing nightmare.
The exi
On Thu, 15 Jul 2021 03:30:46 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(
On Wed, 14 Jul 2021 08:47:56 GMT, Nick Gasson wrote:
> I tried that on N1 and it's very slightly slower than with the 16B alignment
Sorry, ignore that, the result is actually the other way round. Not sure what's
going on there, but there's no significant difference.
--
On Tue, 13 Jul 2021 07:37:31 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark |(
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote:
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either reg
On Fri, 4 Jun 2021 11:07:27 GMT, Jorn Vernee wrote:
>> test/jdk/java/foreign/valist/VaListTest.java line 706:
>>
>>> 704: vaList.skip(BigPoint_LAYOUT);
>>> 705: assertEquals((long) vaList.vargAsLong(C_LONG), 42);
>>> 706: })},
>>
>> Looks
On Fri, 4 Jun 2021 12:57:17 GMT, Maurizio Cimadamore
wrote:
>
> That fix has a switch on the ABI type in the SystemLookup class (a new class
> introduced by that fix). I believe that switch will no longer compile with
> the changes in this PR as the ABI enum constants have changed - hopefully
on macOS AArch64, Linux AArch64, and Linux X86_64.
>
> [1]
> https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
Nick Gasson has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains ten commits:
on macOS AArch64, Linux AArch64, and Linux X86_64.
>
> [1]
> https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
Nick Gasson has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains seven commits:
-
on macOS AArch64, Linux AArch64, and Linux X86_64.
>
> [1]
> https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
Nick Gasson has updated the pull request incrementally with one additional
commit since the last revision:
Update test/jdk/java/forei
On Wed, 2 Jun 2021 13:42:22 GMT, Jorn Vernee wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on
On Thu, 3 Jun 2021 03:09:58 GMT, Nick Gasson wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> i
on macOS AArch64, Linux AArch64, and Linux X86_64.
>
> [1]
> https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
Nick Gasson has updated the pull request incrementally with one additional
commit since the last revision:
No variadic upcalls
Cha
on macOS AArch64, Linux AArch64, and Linux X86_64.
>
> [1]
> https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
Nick Gasson has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains three c
On Mon, 3 May 2021 15:37:44 GMT, Jorn Vernee wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/macos/StackVaList.java
>> line 131:
>>
>>> 129: MemorySegment struct = allocator.allocate(layout);
>>> 130: struct.copyFrom(seg
On Mon, 26 Apr 2021 12:52:54 GMT, Jorn Vernee wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on
On Mon, 26 Apr 2021 14:27:49 GMT, Maurizio Cimadamore
wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either regist
On Tue, 27 Apr 2021 02:07:50 GMT, Nick Gasson wrote:
>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/aapcs/AapcsLinker.java
>> line 50:
>>
>>> 48: * the ARM 64-bit Architecture".
>>> 49: */
>>> 50: public class
On Mon, 26 Apr 2021 14:29:43 GMT, Maurizio Cimadamore
wrote:
>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI. The differences are outlined in [1]. In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either regist
On Thu, 22 Apr 2021 08:19:53 GMT, Nick Gasson wrote:
> macOS on Apple silicon uses slightly different ABI conventions to the
> standard AArch64 ABI. The differences are outlined in [1]. In
> particular in the standard (AAPCS) ABI, variadic arguments may be passed
> in either reg
macOS on Apple silicon uses slightly different ABI conventions to the
standard AArch64 ABI. The differences are outlined in [1]. In
particular in the standard (AAPCS) ABI, variadic arguments may be passed
in either registers or on the stack following the normal calling
convention. To handle this
On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>>
On Thu, 8 Apr 2021 09:05:43 GMT, Dong Bo wrote:
> Hi @nick-arm, are you also ok with the newest commit?
It looks ok to me but I'm not a Reviewer.
-
PR: https://git.openjdk.java.net/jdk/pull/3228
On Sat, 27 Mar 2021 09:53:37 GMT, Andrew Haley wrote:
>
> There's a lot of unrolling, particularly in the non-SIMD case. Please
> consider taking out some of the unrolling; I suspect it'd not increase time
> by very much but would greatly reduce the code cache pollution. It's very
> tempting
On Sat, 27 Mar 2021 09:54:57 GMT, Andrew Haley wrote:
>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic
>> idea can be found at
>> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwor
On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo wrote:
> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea
> can be found at
> http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>
>
On Wed, 9 Dec 2020 08:20:38 GMT, Nick Gasson wrote:
> This is more-or-less a straight port of the x86 code to AArch64.
> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker()
> to generate a blob that jumps to the native function entry point. This
> simply switche
On Fri, 11 Dec 2020 09:29:57 GMT, Andrew Haley wrote:
>> Nick Gasson has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four addi
/op
> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750
> ns/op
> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651
> ns/op
>
> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326
Nick Gasson has updated t
On Thu, 10 Dec 2020 10:47:48 GMT, Andrew Haley wrote:
>> Should we have a separate RegSet type for FloatRegisters to avoid mixing
>> them up?
>
> Absolutely. I'd make an AbstractRegSet and use it as a base type
> for both RegSet and FloatRegSet, then we can get rid of the casts
> altogether.
OK
On Thu, 10 Dec 2020 13:45:21 GMT, Jorn Vernee wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments
>
> src/hotspot/cpu/aarch64/sharedRuntime_aar
/op
> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750
> ns/op
> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651
> ns/op
>
> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326
Nick Gasson has update
On Thu, 10 Dec 2020 10:21:09 GMT, Andrew Haley wrote:
>> Er... no. But not because of the cast. The `push(fp_spills)` below should be
>> `push_fp(fp_spills)`. I'll add a FloatRegister constructor to RegSet so it
>> doesn't need that any more. There's one other place that does it in
>> cpu/aarc
On Thu, 10 Dec 2020 09:36:44 GMT, Andrew Haley wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments
>
> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 3192:
>
&g
On Wed, 9 Dec 2020 09:58:26 GMT, Andrew Haley wrote:
>> Nick Gasson has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments
>
> src/hotspot/cpu/aarch64/aarch64.ad line 16057:
>
>> 1605
On Wed, 9 Dec 2020 08:20:38 GMT, Nick Gasson wrote:
> This is more-or-less a straight port of the x86 code to AArch64.
> GraphKit::make_native_call() calls SharedRuntime::make_native_invoker()
> to generate a blob that jumps to the native function entry point. This
> simply switche
/op
> CallOverhead.panama_identity_struct avgt 30 3206.829 ? 175.750
> ns/op
> CallOverhead.panama_identity_trivial avgt 30 7.849 ? 1.651
> ns/op
>
> [1] https://github.com/openjdk/panama-foreign/pull/279#issuecomment-679172326
Nick Gasson has u
This is more-or-less a straight port of the x86 code to AArch64.
GraphKit::make_native_call() calls SharedRuntime::make_native_invoker()
to generate a blob that jumps to the native function entry point. This
simply switches the thread state from Java to native and handles the
safepoint poll on retu
On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson wrote:
> I ran this test on a machine with 224 logical CPUs and it fails with:
>
> ITERATION 3
> test TestHandshake.testHandshake("SegmentMismatchAccessor",
> TestHandshake$$Lambda$57/0x000100
On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson wrote:
> I ran this test on a machine with 224 logical CPUs and it fails with:
>
> ITERATION 3
> test TestHandshake.testHandshake("SegmentMismatchAccessor",
> TestHandshake$$Lambda$57/0x000100
I ran this test on a machine with 224 logical CPUs and it fails with:
ITERATION 3
test TestHandshake.testHandshake("SegmentMismatchAccessor",
TestHandshake$$Lambda$57/0x0001000e7968@37c4b344): failure
java.lang.OutOfMemoryError: Cannot reserve 100 bytes of direct buffer
memory (all
On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the first incubation round
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
>> access support (see JEP 393 [
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
On 05/15/20 03:39 am, Alexey Semenyuk wrote:
> Looks good.
>
> - Alexey
Thanks Alexey. Can I get another reviewer to look at it before pushing?
Nick
>> Hi,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8244981
>> Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/
>>
>> Several
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8244981
Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/
Several jpackage jtreg tests fail on Debian/Ubuntu with this error:
Running [fakeroot, dpkg-deb, --verbose, -b, <..snip..>]
dpkg-deb: error: parsing file '/tmp/<..snip.
On 30/01/2020 23:57, Maurizio Cimadamore wrote:
Pushed to jdk/jdk
Great, thanks for your help!
Nick
Hi David,
On 01/25/20 06:34 am, David Holmes wrote:
>>
>> I've done this here:
>>
>> http://cr.openjdk.java.net/~ngasson/8237521/webrev.02/
>>
>> Need to check bytes >= 0 before aligning up so that allocateMemory(-1)
>> still throws an IllegalArgumentException.
>
> That looks good to me.
>
>> Test
Hi David,
On 01/24/20 14:35 pm, David Holmes wrote:
>>
>> How about we align the size up to ADDRESS_SIZE (== HeapWordSize) in
>> Unsafe.allocateMemory() before the call to allocateMemoryChecks(). Like:
>>
>>bytes = ((bytes + ADDRESS_SIZE - 1) & ~(ADDRESS_SIZE - 1));
>>
>> Then it will throw an
Hi David,
On 01/24/20 12:17 pm, David Holmes wrote:
>>
>> That said, memory segments are not the only clients of
>> Unsafe::allocateMemory - so if we decided that overflow is an issue
>> that should be handled in clients, fine, but at least it should be
>> evident somewhere in the javadoc of Unsaf
Hi David,
On 01/23/20 15:46 pm, David Holmes wrote:
>
> So on 32-bit size_t is 32-bit and so may have ~half the capacity allowed
> for by the jlong size variable. On 64-bit overflow is not possible
> because jlong is signed and size_t is not.
>
> So we only need an overflow check on 32-bit.
OK.
Hi Maurizio,
Yes, for jdk/jdk. Do I need another Reviewer?
Thanks,
Nick
On 01/22/20 20:46 pm, Maurizio Cimadamore wrote:
> Fixes look good to me - I assume this is for JDK 15, right?
>
> Maurizio
>
> On 22/01/2020 08:43, Nick Gasson wrote:
>> Hi,
>>
>> B
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8237521
Webrev: http://cr.openjdk.java.net/~ngasson/8237521/webrev.01/
This is a follow-up to JDK-8236634 which just contained changes to the
tests to make them build/pass on 32-bit systems for JDK 14. This patch
removes the test workarounds an
Hi Leonid,
On 11/01/2020 02:06, Leonid Mesnik wrote:
--- a/test/jdk/java/foreign/TestArrays.java Wed Jan 01 03:08:45 2020 +0100
+++ b/test/jdk/java/foreign/TestArrays.java Fri Jan 10 09:51:51 2020 -0800
@@ -76,8 +76,8 @@
static VarHandle shortHandle = shorts.varHandle(short.class,
Hi Aleksey,
On 13/01/2020 03:33, Aleksey Shipilev wrote:
Looks fine.
The long/doubleHandle changes probably clash with JDK-8236939.
The test changes probably benefit from cleaner accessors like in JDK-8236920.
But whatever, having any fix in jdk14 that unbreaks 32-bit platforms before
RDP2 h
Hi Maurizio,
On 08/01/2020 18:23, Maurizio Cimadamore wrote:
I'm happy to split it into two patches. One with the build/test fixes
for jdk/jdk14 and another with the Unsafe and
internal/foreign/Utils.java change for jdk/jdk (or panama/dev?). I
think the most important change for jdk14 is the bu
Hi Maurizio,
On 07/01/2020 19:06, Maurizio Cimadamore wrote:
As for integrating this - what are your plans? JDK 14 or panama repo? I
see you have targeted 14 in the issue, which is fine, but the priority
is P4. Needs to be at least a P3 to be pushed in the RDP1 period (and I
think a case can be
Hi,
Please review this set of fixes for the new memory access API on 32-bit
Arm/x86.
Bug: https://bugs.openjdk.java.net/browse/JDK-8236634
Webrev: http://cr.openjdk.java.net/~ngasson/8236634/webrev.0/
libNativeAccess.c fails to build with warnings enabled due to casting
pointers to integers o
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8229912
Webrev: http://cr.openjdk.java.net/~ngasson/8229912/webrev.0/
This test should be skipped if IPv6 is disabled on the host, and it
already has a shouldRun field to support this. But at the moment the
the setUp() method will throw inside Ht
Hi,
Any update on this one? Or do we want to give up on it until JDK-8165620
is implemented?
Thanks,
Nick
On 28/11/2018 11:33, Martin Buchholz wrote:
>
>
> On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson <mailto:nick.gas...@arm.com>> wrote:
>
> > I missed one
Hi Alan, Martin,
Do you want me to make any more changes to this patch, or is it OK to go in
with just the modified #ifdef?
Thanks,
Nick
From: Martin Buchholz
Sent: 28 November 2018 11:33
To: Nick Gasson
Cc: Alan Bateman ; Magnus Ihse Bursie
; build-dev ;
core-libs-dev@openjdk.java.net; nd
t
#endif
Nick
> -Original Message-
> From: Alan Bateman
> Sent: 28 November 2018 03:14
> To: Nick Gasson ; Magnus Ihse Bursie
> ; build-dev ;
> core-libs-dev@openjdk.java.net
> Cc: nd
> Subject: Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on
.openjdk.java.net/~njian/8214077/webrev.3/
Thanks,
Nick
> -Original Message-
> From: Alan Bateman
> Sent: 23 November 2018 19:42
> To: Nick Gasson ; Magnus Ihse Bursie
> ; build-dev ;
> core-libs-dev@openjdk.java.net
> Cc: nd
> Subject: Re: RFR: 8214077: test j
VERFLOW case.
Thanks,
Nick
> -Original Message-
> From: Alan Bateman
> Sent: 23 November 2018 19:01
> To: Nick Gasson ; Magnus Ihse Bursie
> ; build-dev ;
> core-libs-dev@openjdk.java.net
> Cc: nd
> Subject: Re: RFR: 8214077: test java/io/File/SetLastModified.j
;t (e.g. libnio/ch/FileDispatcherImpl.c). I don't have access
to an OS X machine to test, but I guess it doesn't matter too
much as AFAIK Apple haven't supported 32-bit for a long time?
Thanks,
Nick
> -Original Message-
> From: Alan Bateman
> Sent: 22 November 2018 19
on?
> I'd say this is preferred to adding compiler flags, yes. The code will
> make it unambiguously clear that it's correct.
Here is the updated webrev that uses stat64:
http://cr.openjdk.java.net/~njian/8214077/webrev.1/
Thanks,
Nick
> -Original Message-
> From: Magnu
ge-
> From: Alan Bateman
> Sent: Wednesday, November 21, 2018 4:55 PM
> To: Nick Gasson ; build-dev d...@openjdk.java.net>; core-libs-dev@openjdk.java.net
> Cc: nd
> Subject: Re: RFR: 8214077: test java/io/File/SetLastModified.java fails on
> ARM32
>
> On 21
Hi,
Can someone please help me review this small makefile patch to
fix an issue with java.io.File::setLastModified on 32-bit
systems?
https://bugs.openjdk.java.net/browse/JDK-8214077
http://cr.openjdk.java.net/~njian/8214077/webrev.0/
If the file size is > 2GB so that the size won't fit in a sig
me commit this?
http://cr.openjdk.java.net/~njian/8214078/webrev.1/
Nick
> -Original Message-
> From: Alan Bateman
> Sent: Tuesday, November 20, 2018 3:51 PM
> To: Nick Gasson ; nio-...@openjdk.java.net
> Cc: nd ; core-libs-dev@openjdk.java.net
> Subject: Re: RFR: 8214078: Jt
Hi,
Could someone please review this small patch?
Bug: https://bugs.openjdk.java.net/browse/JDK-8214078
Webrev: http://cr.openjdk.java.net/~njian/8214078/webrev.0/
This fixes a failure of the java/nio/file/DirectoryStream/SecureDS.java
Jtreg test on ARM32.
Glibc by design does not expose symbol
91 matches
Mail list logo
