On Tue, 10 May 2022 14:58:28 GMT, zhw970623 wrote:
> The copyright year of
> src/java.base/share/classes/jdk/internal/vm/FillerObject.java should be 2022.
Looks good and trivial.
Thanks for spotting and fixing it.
-
Marked as reviewed by jiefu (Reviewer).
PR:
On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu wrote:
> Hi all,
>
> According to the Vector API doc, the `LSHR` operator computes
> `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
>
> The background is that one
On Wed, 27 Apr 2022 09:13:34 GMT, Jie Fu wrote:
>> Hi all,
>>
>> According to the Vector API doc, the `LSHR` operator computes
>> `a>>>(n&(ESIZE*8-1))`.
>> However, current implementation is incorrect for negative bytes/shorts.
>>
&
On Fri, 13 May 2022 02:43:55 GMT, Jie Fu wrote:
> Hi all,
>
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses
> the case of `GCCause::_codecache_GC_threshold`.
> It would be better to f
On Fri, 13 May 2022 12:27:16 GMT, Zhengyu Gu wrote:
> LGTM
Thanks @zhengyu123 for the review.
-
PR: https://git.openjdk.java.net/jdk/pull/8691
> Hi all,
>
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses
> the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
>
> Thanks.
> Best regards,
> Ji
On Fri, 13 May 2022 13:18:55 GMT, David Holmes wrote:
>>> I think I agree with @AlanBateman - in the sense that this seems to go down
>>> a slippery slope where every test would need to be executed against all
>>> possible GCs. AFAIK, there are no other foreign tests doing this.
>>
>> I think
On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman wrote:
>> Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.
>>
>> What do you mean by `if you are testing with +ShenandoahGC then it will run
>> already`?
>
> I assume you are running the tests with:
>make run-tests
On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman wrote:
> I assume you are running the tests with: make run-tests
> TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" in which case, all of the tests
> you select to run will be run with that GC.
Yes, you're right.
> What you have is not wrong but
On Fri, 13 May 2022 06:36:42 GMT, Alan Bateman wrote:
>> Hi all,
>>
>> Some tests fail with Shenandoah GC after JDK-8282191.
>> The reason is that the assert in `ShenandoahControlThread::request_gc`
>> misses the case of `GCCause::_codecache_GC_threshold`.
>> It would be better to fix it.
>>
Hi all,
Some tests fail with Shenandoah GC after JDK-8282191.
The reason is that the assert in `ShenandoahControlThread::request_gc` misses
the case of `GCCause::_codecache_GC_threshold`.
It would be better to fix it.
Thanks.
Best regards,
Jie
-
Commit messages:
-
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote:
> Hi all,
>
> The Current Vector API doc for `LSHR` is
>
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>
>
> This is misleading which may lead to bugs for Java developers.
> This is because for negative b
On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz wrote:
>> Jie Fu 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 six additi
uted by
> `LSHR` will be different from that of `>>>`.
> For more details, please see
> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>
> After the patch, the doc for `LSHR` is
>
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz wrote:
>> Jie Fu 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 six additi
On Thu, 28 Apr 2022 19:48:18 GMT, Paul Sandoz wrote:
> It should be possible for you finalize now.
Done.
Thanks @PaulSandoz .
-
PR: https://git.openjdk.java.net/jdk/pull/8291
On Thu, 28 Apr 2022 00:08:41 GMT, Paul Sandoz wrote:
> I created one, filled it in, and assigned it to you (for other examples you
> can search in the issue tracker, this one quite is simple so i thought it was
> quicker to do myself to show you). For any specification change we need to
>
On Wed, 27 Apr 2022 20:23:32 GMT, Naoto Sato wrote:
> Java runtime has been detecting the Windows system locale encoding using
> `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`,
> but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English.
> In order
On Wed, 27 Apr 2022 17:17:55 GMT, Paul Sandoz wrote:
> Thanks, looks good, we will need to create a CSR. Have you done that before?
No, and I don't know much about a CSR.
Is there any example for a doc fix CSR to follow?
Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/8291
On Tue, 26 Apr 2022 17:31:40 GMT, Jatin Bhateja wrote:
> > > According to the Vector API doc, the LSHR operator computes
> > > a>>>(n&(ESIZE*8-1))
>
> Documentation is correct if viewed strictly in context of subword vector
> lane, JVM internally promotes/sign extends subword type scalar
uted by
> `LSHR` will be different from that of `>>>`.
> For more details, please see
> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>
> After the patch, the doc for `LSHR` is
>
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
On Tue, 26 Apr 2022 21:41:37 GMT, Paul Sandoz wrote:
> After talking with John here's what we think is a better approach than what I
> originally had in mind:
>
> 1. In the class doc of `VectorOperators` add a definition for `EMASK`
> occurring after the definition for `ESIZE`:
>
> ```
> *
On Wed, 20 Apr 2022 17:24:56 GMT, Paul Sandoz wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the
On Wed, 20 Apr 2022 17:24:56 GMT, Paul Sandoz wrote:
> We can raise attention to that:
>
> ```
> /** Produce {@code a>>>(n&(ESIZE*8-1))}
> * (The operand and result are converted if the operand type is {@code byte}
> or {@code short}, see below). Integral only.
> * ...
> */
> ```
It
uted by
> `LSHR` will be different from that of `>>>`.
> For more details, please see
> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>
> After the patch, the doc for `LSHR` is
>
> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral only.
On Tue, 19 Apr 2022 08:41:50 GMT, Jie Fu wrote:
> Hi all,
>
> The Current Vector API doc for `LSHR` is
>
> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>
>
> This is misleading which may lead to bugs for Java developers.
> This is because for negative b
On Wed, 20 Apr 2022 00:25:26 GMT, Paul Sandoz wrote:
> I am yet to be convinced we a 3rd vector right shift operator. We are talking
> about narrow cases of correct use which i believe can be supported with the
> existing operators. The user needs to think very careful when deviating from
>
On Wed, 20 Apr 2022 00:46:32 GMT, Paul Sandoz wrote:
> The intended pattern for the operator tokens is to present a short symbolic
> description using Java operators and common methods. It would be good to try
> and keep with this pattern, and clarify for the extra cases. Here's what i
> had
On Tue, 19 Apr 2022 16:11:37 GMT, Paul Sandoz wrote:
> I need to think a little more about this. The specification is not accurate
> and likely requires a CSR.
>
> My initial thoughts are I would prefer the operation to retain reference to
> the succinct definition using the logical right
On Tue, 19 Apr 2022 17:40:07 GMT, Paul Sandoz wrote:
> Not yet talked with John, but i investigated further. The implementation of
> the `LSHR` operation is behaving as intended, but is under specified with
> regards to `byte` and `short` as you noted in #8291.
>
> This is a subtle area, but
On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu wrote:
> Hi all,
>
> According to the Vector API doc, the `LSHR` operator computes
> `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
>
> The background is that one
Hi all,
The Current Vector API doc for `LSHR` is
Produce a>>>(n&(ESIZE*8-1)). Integral only.
This is misleading which may lead to bugs for Java developers.
This is because for negative byte/short elements, the results computed by
`LSHR` will be different from that of `>>>`.
For more details,
On Tue, 19 Apr 2022 02:43:33 GMT, Quan Anh Mai wrote:
> I see, however, I preserve the opinion that the API doc implies the extended
> unsigned right shift not the original `>>>` (or the output types would be
> wrong). So, I think you can create another operator that perform the scalar
>
On Mon, 18 Apr 2022 08:29:52 GMT, Jie Fu wrote:
>>> @DamonFool
>>>
>>> I think the issue is that these two cases of yours are not equal
>>> semantically.
>>
>> Why?
>> According to the vector api doc, they should com
On Mon, 18 Apr 2022 05:14:25 GMT, Jie Fu wrote:
>>> > However, just image that someone would like to optimize some code
>>> > segments of bytes/shorts `>>>`
>>>
>>> Then that person can just use signed shift (`VectorOperators.ASHR`)
On Mon, 18 Apr 2022 05:09:33 GMT, Jie Fu wrote:
>>> However, just image that someone would like to optimize some code segments
>>> of bytes/shorts `>>>`
>>
>> Then that person can just use signed shift (`VectorOperators.ASHR`), right?
>> Shiftin
On Mon, 18 Apr 2022 04:25:23 GMT, Quan Anh Mai wrote:
> > However, just image that someone would like to optimize some code segments
> > of bytes/shorts `>>>`
>
> Then that person can just use signed shift (`VectorOperators.ASHR`), right?
> Shifting on masked shift counts means that the shift
On Mon, 18 Apr 2022 03:48:13 GMT, Quan Anh Mai wrote:
> Because unsigned cast should operate on unsigned types, the more appropriate
> usage is `(src[i] & 0xFF) >>> 3`, with the `&` operation is the cast from
> unsigned byte to int. Actually, I fail to understand the intention of your
>
On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu wrote:
> Hi all,
>
> According to the Vector API doc, the `LSHR` operator computes
> `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
>
> The background is that one
On Mon, 18 Apr 2022 02:32:39 GMT, Quan Anh Mai wrote:
> What I try to convey here is that `src[i] >>> 3` is not a byte unsigned
> shift, it is an int unsigned shift following a byte-to-int promotion. This is
> different from the Vector API that has definition for the shift operations of
>
On Sun, 17 Apr 2022 23:53:49 GMT, Quan Anh Mai wrote:
> According to JLS section 5.8, any operand in a numeric arithmetic context
> undergoes a promotion to int, long, float or double and the operation is only
> defined for values of the promoted types. This means that `>>>` is not
> defined
On Sun, 17 Apr 2022 17:25:57 GMT, Quan Anh Mai wrote:
> Hi,
>
> The `>>>` operator is not defined for subword types, what the code in line 28
> does vs what it is supposed to do are different, which is more likely the bug
> here. An unsigned shift should operate on subword types the same as
Hi all,
According to the Vector API doc, the `LSHR` operator computes
`a>>>(n&(ESIZE*8-1))`.
However, current implementation is incorrect for negative bytes/shorts.
The background is that one of our customers try to vectorize `urshift` with
`urshiftVector` like the following.
13 public
On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong wrote:
>> The current vector `"NEG"` is implemented with substraction a vector by zero
>> in case the architecture does not support the negation instruction. And to
>> fit the predicate feature for architectures that support it, the masked
>>
On Tue, 15 Mar 2022 02:47:20 GMT, Xiaohong Gong wrote:
> > Note that in terms of Java semantics, negation of floating point values
> > needs to be implemented as subtraction from negative zero rather than
> > positive zero:
> > double negate(double arg) {return -0.0 - arg; }
> > This is to
On Tue, 22 Mar 2022 09:58:23 GMT, Xiaohong Gong wrote:
>> The current vector `"NEG"` is implemented with substraction a vector by zero
>> in case the architecture does not support the negation instruction. And to
>> fit the predicate feature for architectures that support it, the masked
>>
On Mon, 21 Mar 2022 01:19:57 GMT, Xiaohong Gong wrote:
> The compiler can get the real type info from `Op_NegVI` that can also handle
> the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs
> which also need more match rules in the ad files.
>
> > Is there any performance
On Sat, 19 Mar 2022 03:11:12 GMT, Jie Fu wrote:
>>> Note that in terms of Java semantics, negation of floating point values
>>> needs to be implemented as subtraction from negative zero rather than
>>> positive zero:
>>>
>>>
On Wed, 23 Mar 2022 09:27:07 GMT, Severin Gehwolf wrote:
>> Please review this container test improvement. The test in question only
>> makes sense iff the total swap space size as reported by the container aware
>> OperatingSystemMXBean is `0`. If that's not the case, then something else
>>
On Thu, 17 Mar 2022 13:40:53 GMT, Severin Gehwolf wrote:
> Please review this container test improvement. The test in question only
> makes sense iff the total swap space size as reported by the container aware
> OperatingSystemMXBean is `0`. If that's not the case, then something else
>
On Tue, 15 Mar 2022 02:47:20 GMT, Xiaohong Gong wrote:
> Note that in terms of Java semantics, negation of floating point values needs
> to be implemented as subtraction from negative zero rather than positive zero:
>
> double negate(double arg) {return -0.0 - arg; }
>
> This is to handle
On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong wrote:
> The current vector `"NEG"` is implemented with substraction a vector by zero
> in case the architecture does not support the negation instruction. And to
> fit the predicate feature for architectures that support it, the masked
> vector
On Tue, 30 Nov 2021 23:31:21 GMT, Paul Sandoz wrote:
>> Remove Vector API scripts for building and running tests. `jtreg` should be
>> used instead.
>>
>> Also updated the test generation script to remove options that assume
>> mercurial as the code repository.
>
> Paul Sandoz has updated the
On Tue, 30 Nov 2021 19:22:53 GMT, Paul Sandoz wrote:
> Remove Vector API scripts for building and running tests. `jtreg` should be
> used instead.
>
> Also updated the test generation script to remove options that assume
> mercurial as the code repository.
Shall we also update the copyright
On Tue, 31 Aug 2021 09:40:14 GMT, xpbob
wrote:
> 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302
LGTM
Thanks for fixing it.
-
Marked as reviewed by jiefu (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5315
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote:
>> Hi all,
>>
>> could you please review this big tedious and trivial(-ish) patch which moves
>> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>>
>> the majority of the patch is the following substitutions:
>>
On Wed, 16 Jun 2021 15:29:19 GMT, Paul Sandoz wrote:
>> Test that when the jdk.incubator.vector module is present that libsvml.so is
>> present, and test the opposite case.
>
> Paul Sandoz has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Mon, 14 Jun 2021 16:06:04 GMT, Paul Sandoz wrote:
> Test that when the jdk.incubator.vector module is present that libsvml.so is
> present, and test the opposite case.
The test logic should be changed.
If C2 is absent, libsvml.so would not be generated after JDK-8268643.
Thanks.
On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote:
> Relevant declarations modified and tested with -Werror, no longer see
> unchecked conversion warnings.
>
> Kindly review and approve.
LGTM
-
Marked as reviewed by jiefu (Reviewer).
PR:
On Wed, 7 Apr 2021 03:34:15 GMT, Jie Fu wrote:
> Hi all,
>
> test-lib fails to build due to three javac warnings:
This pull request has now been integrated.
Changeset: 88eb2919
Author: Jie Fu
URL: https://git.openjdk.java.net/jdk/commit/88eb2919
Stats: 5 lines in 3 file
On Wed, 7 Apr 2021 13:48:57 GMT, Roger Riggs wrote:
>> Hi all,
>>
>> test-lib fails to build due to three javac warnings:
>
> Looks good.
> It seems only the build-test-lib make rule has error on warnings set.
> When running the tests, the compiles do not fail. (though the warnings are
>
Hi all,
test-lib fails to build due to three javac warnings:
-
Commit messages:
- 8264809: test-lib fails to build due to some warnings in ASN1Formatter and
jfr
Changes: https://git.openjdk.java.net/jdk/pull/3367/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3367=00
On Mon, 18 Jan 2021 13:32:24 GMT, Jie Fu wrote:
> Hi all,
>
> For this reproducer:
>
> import jdk.incubator.vector.ByteVector;
> import jdk.incubator.vector.VectorSpecies;
>
> public class Test {
> static final VectorSpecies SPECIES_128 = ByteVector.SPE
On Thu, 25 Feb 2021 09:31:01 GMT, Jie Fu wrote:
> Hi all,
>
> Vector API fails to work when:
> - case 1: MaxVectorSize is set to <=8, or
> - case 2: C2 is disabled
>
> The reason is that {max/preferred} VectorShape initialization fails in both
>
On Tue, 2 Mar 2021 17:17:37 GMT, Paul Sandoz wrote:
>> Jie Fu has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Add VectorShape.getMaxVectorBitSize
>
> Marked as reviewed by psandoz (Reviewer).
> The
On Sun, 28 Feb 2021 13:31:38 GMT, Jie Fu wrote:
>> `@requires vm.compiler2.enabled` had been added.
>> Thanks.
>
> @PaulSandoz , are you also OK with the latest version?
> Thanks.
> @DamonFool I think Vladimir is correct in the layering, in this respect i
> think w
ize=default/8 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
On Sat, 27 Feb 2021 11:15:06 GMT, Jie Fu wrote:
>> test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java line 42:
>>
>>> 40: * @modules jdk.incubator.vector java.base/jdk.internal.vm.vector
>>> 41: * @run testng/othervm -XX:MaxVectorSize=8 PreferredSpeciesTest
ize=default/8 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
On Sat, 27 Feb 2021 10:58:16 GMT, Vladimir Ivanov wrote:
>> Jie Fu 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 seven
On Fri, 26 Feb 2021 15:48:18 GMT, Vladimir Ivanov wrote:
> > I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <=
> > VectorSupport.getMaxLaneCount(double.class) for Java programmers since the
> > VectorSupport_GetMaxLaneCount is used to implement a Java API.
>
> It doesn't make much
ize=default/8 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
Jie Fu has updated the pull request with a new target base due to a merge or a
rebase. The incremental webrev exclu
On Fri, 26 Feb 2021 13:55:15 GMT, Vladimir Ivanov wrote:
> IMO the fix should be in
> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`.
>
> JVM does the right job when it signals vector support is absent (by returning
> `-1`).
>
> `jdk.incubator.vector`
ize=default/8 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision
On Fri, 26 Feb 2021 02:28:55 GMT, Paul Sandoz wrote:
> In that case I think we can remove the execution with
> `-XX:TieredStopAtLevel=x`.
Fixed. Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/2722
ize=default/8 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Update th
On Fri, 26 Feb 2021 00:30:45 GMT, Paul Sandoz wrote:
> Thanks, was the test `VectorShapeInitTest` passing prior to the fix of the
> numerator?
Yes. It also passed with min_lane_count = 64 / type2aelembytes(bt).
> Perhaps we should be testing more directly on
>
On Thu, 25 Feb 2021 17:23:11 GMT, Paul Sandoz wrote:
>> Jie Fu has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> The numerator should be 8 (byte)
>
> src/hotspot/share/prims/vectorSupport.cpp line 368:
&g
ize=default/8 on Linux/x64
>
> Thanks.
> Best regards,
> Jie
>
> [1]
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
On Fri, 19 Feb 2021 15:15:05 GMT, Roger Riggs wrote:
>> Jie Fu has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Catch exception and return the accumulated string
>
> Catching and ignoring the exception has
On Thu, 18 Feb 2021 02:28:01 GMT, Jie Fu wrote:
> Hi all,
>
> ASN1Formatter.annotate should be able to throw an IOException according to
> this comment [1].
> But it fails to do so due to the return [2] in the finally block, which would
> swallow the IOException.
>
On Fri, 19 Feb 2021 01:56:19 GMT, Roger Riggs wrote:
> The formattters are a test component used both standalone and in the context
> of the HexPrinter test utilities.
> In typical use, the stream is a wrapped byte array, so there are no
> exceptions other than EOF.
> The choice of
/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120
> [3]
> https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning
Jie Fu has updated the pull request incrementally with one additional commit
since the last re
On Thu, 18 Feb 2021 14:53:17 GMT, Roger Riggs wrote:
>> Jie Fu has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Update the copyright year
>
> An EOFException can occur during the call to annotate() and
/openjdk/jdk/blob/master/test/lib/jdk/test/lib/hexdump/ASN1Formatter.java#L120
> [3]
> https://stackoverflow.com/questions/17481251/finally-block-does-not-complete-normally-eclipse-warning
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Hi all,
ASN1Formatter.annotate should be able to throw an IOException according to this
comment [1].
But it fails to do so due to the return [2] in the finally block, which would
swallow the IOException.
Generally, it seems not good to put a return statement in a finally block
because it
On Tue, 26 Jan 2021 18:20:00 GMT, Paul Sandoz wrote:
> Hi Jie, Thanks for the detailed analysis. I suspect the difference outside of
> loops is because of expression "length - (vlen - 1)”. We need to make
> intrinsic Objects.checkFromIndexSize. Is that something you might be
> interested in
On Thu, 21 Jan 2021 16:54:36 GMT, Paul Sandoz wrote:
> The intrinsic enables C2 to more reliably elide bounds checks. I don't know
> the exact details but at a high-level it transforms signed values into
> unsigned values (and therefore the signed comparisons become unsigned
> comparisons),
On Thu, 21 Jan 2021 16:54:36 GMT, Paul Sandoz wrote:
>>> Unfortunately it is still problematic because you have replaced the
>>> intrinsic check (that performed by `Object.checksIndex`, or more
>>> specifically
>>>
On Thu, 21 Jan 2021 16:54:36 GMT, Paul Sandoz wrote:
> The intrinsic enables C2 to more reliably elide bounds checks. I don't know
> the exact details but at a high-level it transforms signed values into
> unsigned values (and therefore the signed comparisons become unsigned
> comparisons),
On Wed, 20 Jan 2021 19:30:41 GMT, Paul Sandoz wrote:
> Unfortunately it is still problematic because you have replaced the intrinsic
> check (that performed by `Object.checksIndex`, or more specifically
>
tOfBoundsException message (length -7) is unreasonable.
>
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out
> of bounds for length -7
>
> It might be better to fix it like this.
>
> Exception in thread "main" java.lang.IndexOut
On Tue, 19 Jan 2021 21:40:24 GMT, Paul Sandoz wrote:
>> Hi all,
>>
>> For this reproducer:
>>
>> import jdk.incubator.vector.ByteVector;
>> import jdk.incubator.vector.VectorSpecies;
>>
>> public class Test {
>> static final VectorSpecies SPECIES_128 = ByteVector.SPECIES_128;
>>
Hi all,
For this reproducer:
import jdk.incubator.vector.ByteVector;
import jdk.incubator.vector.VectorSpecies;
public class Test {
static final VectorSpecies SPECIES_128 = ByteVector.SPECIES_128;
static byte[] a = new byte[8];
static byte[] b = new byte[8];
public static void
On Thu, 17 Dec 2020 12:11:33 GMT, Jie Fu wrote:
> Hi all,
>
> java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'.
> The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms.
> The current implementation only supports maximum 3800M on 32
On Mon, 21 Dec 2020 15:34:16 GMT, Roger Riggs wrote:
>> Jie Fu has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Ignore OOME for testOOME
>> - Revert the change
>
> Completely ignoring the excepti
ub.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Skip OOME
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1817/files
- new: https://git.openjdk.java.
On Thu, 17 Dec 2020 16:14:56 GMT, Roger Riggs wrote:
> Disabling all of the tests on 32 bit is not a good idea.
>
> Instead the HexFormatTest.testOOME test should be skipped or the OOME should
> be ignored.
> Checking Runtime.getRuntime().maxMemory() should provide enough info to skip
> it.
ub.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567
Jie Fu has updated the pull request incrementally with two additional commits
since the last revision:
- Ignore OOME for testOOME
- Revert the change
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1817/files
Hi all,
java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'.
The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms.
The current implementation only supports maximum 3800M on 32-bit systems [1].
I've tried to reduce the -Xmx size, but it still fails even
1 - 100 of 162 matches
Mail list logo
