On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman wrote:
>> This patch adds an alternative virtual thread implementation where each
>> virtual thread is backed by an OS thread. It doesn't scale but it can be
>> used by ports that don't have continuations support in the VM. Aside from
>>
On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev wrote:
> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch
> of tests into problemlist. Those lists basically exclude every test that runs
> with --enable-preview.
> [JDK-8287437](https://bugs.open
stdebug; mostly pass, some non-Loom
> failures
> - [x] Linux x86_32 fastdebug `tier1`
> - [x] GHA run
Aleksey Shipilev 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
On Tue, 31 May 2022 16:54:41 GMT, Boris Ulasevich
wrote:
> I expected this change to fix the broken ARM32 port, but it doesn't work.
It would not fix ARM32, because the interpreter stubs need to be predicated on
`Continuations::enabled()`. Also, as my ARM32 experiments show
On Tue, 31 May 2022 11:44:27 GMT, Alan Bateman wrote:
>> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a
>> bunch of tests into problemlist. Those lists basically exclude every test
>> that runs with --enable-preview.
>>
On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev wrote:
> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch
> of tests into problemlist. Those lists basically exclude every test that runs
> with --enable-preview.
> [JDK-8287437](https://bugs.open
On Tue, 24 May 2022 21:10:29 GMT, David Holmes wrote:
> Just FYI. There is a mistake in this changeset. The JDK ProblemList already
> contained:
>
> `java/nio/channels/FileChannel/LargeMapTest.java 8286980 windows-all`
>
> and this change then added:
>
>
On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev wrote:
> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot
> of x86_32 code. The x86_32 porting is done under
> [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile,
> we can
On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev wrote:
>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot
>> of x86_32 code. The x86_32 porting is done under
>> [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile,
>
On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev wrote:
>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot
>> of x86_32 code. The x86_32 porting is done under
>> [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile,
>
ther patches.
> This should also make GHA runs cleaner.
>
> Additional testing:
> - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
> - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
> - [x] Linux x86_32 fastdebug `tier3` (clean now)
>
ther patches.
> This should also make GHA runs cleaner.
>
> Additional testing:
> - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
> - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
> - [x] Linux x86_32 fastdebug `tier3` (clean now)
>
On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote:
> It would be beneficial to bring over the Loom-specific test groups from the
> loom repo to aid development/porting work.
>
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.c
On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote:
> It would be beneficial to bring over the Loom-specific test groups from the
> loom repo to aid development/porting work.
>
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.c
On Mon, 23 May 2022 15:34:11 GMT, Alan Bateman wrote:
>> Those tests *do* run with preview enabled:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11
>> -- and I know that because I basically copy-pasted all jtreg failures that
>> lead to
On Mon, 23 May 2022 15:13:02 GMT, Alan Bateman wrote:
>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot
>> of x86_32 code. The x86_32 porting is done under
>> [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile,
>> we can problemlist the
[JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of
x86_32 code. The x86_32 porting is done under
[JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we
can problemlist the failing tests to get cleaner runs for other patches. This
should also
On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote:
> It would be beneficial to bring over the Loom-specific test groups from the
> loom repo to aid development/porting work.
>
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.c
On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote:
> It would be beneficial to bring over the Loom-specific test groups from the
> loom repo to aid development/porting work.
>
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.c
It would be beneficial to bring over the Loom-specific test groups from the
loom repo to aid development/porting work.
https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev wrote:
>> There are plenty of tests failing on many architectures due to
>> `--enable-preview` VM code introduced by Loom. This improvements eliminates
>> some of the redundant `--enable-preview` clauses from the Recor
On Tue, 10 May 2022 12:03:09 GMT, Aleksey Shipilev wrote:
> There are plenty of tests failing on many architectures due to
> `--enable-preview` VM code introduced by Loom. This improvements eliminates
> some of the redundant `--enable-preview` clauses from the Record tests, since
On Tue, 10 May 2022 14:58:15 GMT, Aleksey Shipilev wrote:
>> There are plenty of tests failing on many architectures due to
>> `--enable-preview` VM code introduced by Loom. This improvement eliminates
>> some of the redundant `--enable-preview` clauses from the Sealed Classe
On Tue, 10 May 2022 12:07:31 GMT, Aleksey Shipilev wrote:
> There are plenty of tests failing on many architectures due to
> `--enable-preview` VM code introduced by Loom. This improvement eliminates
> some of the redundant `--enable-preview` clauses from the Sealed Classes
>
On Tue, 10 May 2022 12:47:08 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review comments
>
> test/jdk/java/lang/reflect/sealed_classes/SealedClasses
ew in JDK 17.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug, affected tests still pass
> - [x] Linux x86_32 fastdebug, affected tests start to pass
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Review comments
On Tue, 10 May 2022 14:43:06 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review comments
>
> test/jdk/java/nio/Buffer/BulkPutBuffer.java line 57:
&g
;
> Additional testing:
> - [x] Linux x86_64 fastdebug, affected tests still pass
> - [x] Linux x86_32 fastdebug, affected tests start to pass
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Review comments
---
There are plenty of tests failing on many architectures due to
`--enable-preview` VM code introduced by Loom. This improvement eliminates some
of the redundant `--enable-preview` clauses from the Sealed Classes tests,
since Sealed Classes have been graduated from preview in JDK 17.
Additional
There are plenty of tests failing on many architectures due to
`--enable-preview` VM code introduced by Loom. This improvements eliminates
some of the redundant `--enable-preview` clauses from the Record tests, since
Records have been graduated from preview in JDK 16.
Additional testing:
-
On Thu, 5 May 2022 18:54:49 GMT, Alan Bateman wrote:
> We mailed porters-dev in Sep 2021 to give a heads up that this feature would
> require porting work so it shouldn't be a surprise. We have been open to
> including other ports with the initial integration but it was never a goal to
> have
On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview).
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default
On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview).
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default
On Wed, 30 Mar 2022 11:38:59 GMT, Aleksey Shipilev wrote:
> See bug report for more details. This change improves
> SPECjvm2008:xml.validation for about +3%:
>
>
> baseline: 298.353 ± 1.008 ops/min
> patched: 309.912 ± 1.347 ops/min
>
> Of course, the real im
On Wed, 6 Apr 2022 07:48:04 GMT, Aleksey Shipilev wrote:
>> Any other reviews? I would like someone else to confirm my investigation
>> that we don't use the stack traces out of these exceptions too...
>
>> Hello @shipilev, do you think this stackless na
On Wed, 6 Apr 2022 09:42:21 GMT, Claes Redestad wrote:
> Do I need a second reviewer for the hotspot changes?
FWIW, I think hotspot changes are quite simple, so maybe no need for second
reviewer?
-
PR: https://git.openjdk.java.net/jdk/pull/8089
On Mon, 4 Apr 2022 09:58:35 GMT, Claes Redestad wrote:
> As an alternative to #7667 I took a look at injecting an empty class array
> from the VM. Turns out we already do this for exception types - see
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L918
> - and
On Fri, 1 Apr 2022 08:10:48 GMT, Aleksey Shipilev wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update LastModified
>
> Any other reviews? I would like someone el
See bug report for more details. This change improves
SPECjvm2008:xml.validation for about +3%:
baseline: 298.353 ± 1.008 ops/min
patched: 309.912 ± 1.347 ops/min
Of course, the real improvements might be even higher, as exception might be
thrown from much deeper call hierarchy.
On Wed, 23 Mar 2022 02:03:26 GMT, Fei Yang wrote:
>> This PR implements JEP 422: Linux/RISC-V Port [1].
>> The PR starts as a squashed merge of the
>> https://openjdk.java.net/projects/riscv-port branch.
>>
>> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive
>> Unmatched
On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu wrote:
> Please review this trivial patch to correct last parameter of
> `GetStringChars()` call, which should be a `jboolean*`, instead of `jboolean`
Looks fine to me.
-
Marked as reviewed by shade (Reviewer).
PR:
On Thu, 3 Feb 2022 07:20:28 GMT, Aleksey Shipilev wrote:
> I was looking for easy things to do to improve `java.lang.invoke` cold
> performance. One of the things is inlining `VarForm.getMemberName` a bit, so
> that interpreter does not have to call through `getMemberN
On Tue, 8 Feb 2022 17:39:37 GMT, Mandy Chung wrote:
> This change looks okay. One biggest cold startup overhead we measured for JEP
> 416 is due to the overhead of spinning and loading classes of MH/VH. This
> micro-optimization focuses on the performance of VH invocation. Do you see
> class
On Tue, 8 Feb 2022 14:16:15 GMT, Vladimir Ivanov wrote:
>> Aleksey Shipilev 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 contain
gt; # (server, default)
> # Patched
> VarHandleExact.exact_exactInvocation avgt 30 0.621 ± 0.070 ns/op
> VarHandleExact.generic_exactInvocationavgt 30 0.601 ± 0.061 ns/op
> VarHandleExact.generic_genericInvocation avgt 30 10.499 ± 0.070 ns/op
>
>
> Additional testing:
> - [x] Linu
On Mon, 7 Feb 2022 13:34:24 GMT, Claes Redestad wrote:
> Looks reasonable.
Thanks. Any more reviews needed, or I am pushing?
-
PR: https://git.openjdk.java.net/jdk/pull/7333
I was looking for easy things to do to improve `java.lang.invoke` cold
performance. One of the things is inlining `VarForm.getMemberName` a bit, so
that interpreter does not have to call through `getMemberNameOrNull`.
There is direct VarHandle benchmark in our corpus:
$
On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote:
> Recent test regression after adding new cases in the test. Without compressed
> oops, ~1G elements `Object[]` array takes >8G of memory, which fails the
> test. The fix cuts it down to 512M when reference siz
On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote:
> Recent test regression after adding new cases in the test. Without compressed
> oops, ~1G elements `Object[]` array takes >8G of memory, which fails the
> test. The fix cuts it down to 512M when reference siz
Recent test regression after adding new cases in the test. Without compressed
oops, ~1G elements `Object[]` array takes >8G of memory, which fails the test.
The fix cuts it down to 512M when reference size is 8 bytes. Additionally,
`ObjectAlignmentInBytes=32` is excessive for new test configs.
On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote:
> While working on JDK-8280003, I noticed that
> java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays
> with more than 1-byte size elements, and no large arrays (past 4G limit) are
> tested eith
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that cas
On Tue, 25 Jan 2022 16:33:10 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value;
On Tue, 25 Jan 2022 16:12:11 GMT, Aleksey Shipilev wrote:
> > This looks good, although I don't know whether the additional check for
> > strongReferent != null is needed in clearStrong(). This is all racy code
> > and you have already got a non-null return from getSt
> Attention @rkennke, @plevart.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass`
> - [x] Linux x86_64 fastdebug `tier1`
> - [x] Linux x86_64 fastdebug `tier2`
> - [x] Linux x86_64 fastdebug `tier3`
Aleksey Shipilev has updated the
On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote:
>> Aleksey Shipilev 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 contai
On Tue, 18 Jan 2022 20:07:10 GMT, Roger Riggs wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry loop
On Mon, 24 Jan 2022 21:32:16 GMT, Peter Levart wrote:
> This looks good, although I don't know whether the additional check for
> strongReferent != null is needed in clearStrong(). This is all racy code and
> you have already got a non-null return from getStrong() in case you are
> calling
On Fri, 21 Jan 2022 16:19:07 GMT, Leonid Mesnik wrote:
> Please update copyright years.
Updated, thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/7132
Additional testing:
> - [x] Linux x86_64 fastdebug, affected test still passes
> - [x] Linux x86_32 fastdebug, affected test still passes
> - [x] Linux AArch64 fastdebug, affected test still passes
> - [x] Linux PPC64 fastdebug, affected test still passes
Aleksey Shipilev has updated the
On Fri, 21 Jan 2022 15:19:38 GMT, Aleksey Shipilev wrote:
> Found by Sonar. See details in the bug.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `tier1`
> - [x] Linux x86_64 fastdebug `java/util/Hashtable`
Thanks for reviews!
-
PR: https://git.openj
On Fri, 21 Jan 2022 15:19:38 GMT, Aleksey Shipilev wrote:
> Found by Sonar. See details in the bug.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `tier1`
> - [x] Linux x86_64 fastdebug `java/util/Hashtable`
This pull request has now been integrated.
Changeset:
Found by Sonar. See details in the bug.
Additional testing:
- [x] Linux x86_64 fastdebug `tier1`
- [x] Linux x86_64 fastdebug `java/util/Hashtable`
-
Commit messages:
- Fix
Changes: https://git.openjdk.java.net/jdk/pull/7178/files
Webrev:
Additional testing:
> - [x] Linux x86_64 fastdebug, affected test still passes
> - [x] Linux x86_32 fastdebug, affected test still passes
> - [x] Linux AArch64 fastdebug, affected test still passes
> - [x] Linux PPC64 fastdebug, affected test still passes
Aleksey Shipilev has updated the
On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote:
> WDYT?
I like the idea of holding to a value strongly for a brief period of time, in
order to guarantee progress! The sample code was a bit hard to follow, so I
rewrote the loop a bit with comments, see new commit. This still passes
> Attention @rkennke, @plevart.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass`
> - [x] Linux x86_64 fastdebug `tier1`
> - [x] Linux x86_64 fastdebug `tier2`
> - [x] Linux x86_64 fastdebug `tier3`
Aleksey Shipilev has updated the
On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote:
>> While working on JDK-8280003, I noticed that
>> java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays
>> with more than 1-byte size elements, and no large arrays (past 4G limit) are
>> tested either. It would be
On Wed, 19 Jan 2022 10:42:02 GMT, Peter Levart wrote:
> So, this patch is fine for making ClassCache more robust as a re-usable
> component inside JDK (checking for non-null return of computeValue). The 2nd
> change, that apparently shields against unbounded accumulation of garbage,
> might
> Attention @rkennke, @plevart.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass`
> - [x] Linux x86_64 fastdebug `tier1`
> - [x] Linux x86_64 fastdebug `tier2`
> - [x] Linux x86_64 fastdebug `tier3`
Aleksey Shipilev has updated the pul
On Tue, 18 Jan 2022 20:07:10 GMT, Roger Riggs wrote:
> It may not be worth it. If not, add the label "noreg-hard".
Added.
> It is possible for add to the test description the modules to be opened:
> ```
> * @modules java.base/java.io:open
> ```
>
> jtreg will add the appropriate command line
> Attention @rkennke, @plevart.
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `java/io/ObjectStreamClass`
> - [x] Linux x86_64 fastdebug `tier1`
> - [x] Linux x86_64 fastdebug `tier2`
> - [x] Linux x86_64 fastdebug `tier3`
Aleksey Shipilev has updated the
On Tue, 18 Jan 2022 19:36:18 GMT, Chris Plummer wrote:
>> While working on JDK-8280003, I noticed that
>> java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays
>> with more than 1-byte size elements, and no large arrays (past 4G limit) are
>> tested either. It would be
On Tue, 18 Jan 2022 18:22:26 GMT, Roger Riggs wrote:
> Can a test be written to verify the correct handling of nulls.
`java.io.ClassCache` is not public (for a reason), I struggle to find a way to
access it from a jtreg test...
-
PR: https://git.openjdk.java.net/jdk/pull/7092
While working on JDK-8280003, I noticed that
java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays with
more than 1-byte size elements, and no large arrays (past 4G limit) are tested
either. It would be better to add those test cases.
Additional testing:
- [x] Linux
On Fri, 14 Jan 2022 20:50:24 GMT, Roman Kennke wrote:
> One additional improvement would be to change r.get() == null to
> r.refersTo(null) to check for cleared reference, that avoids reviving the
> referent, e.g. in SATB GCs. I leave that up to you.
I think that does not work, because we
JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
issues with it:
- The cache cannot disambiguate between cleared SoftReference and the
accidental passing of `null` value; in that case, the retry loop would spin
indefinitely;
- If retry loop would spin several
On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote:
> Tests were fatally failing (windows) on Github actions. Pumping up the memory
> requirements will hopefully alleviate.
Looks fine.
-
Marked as reviewed by shade (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7086
On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote:
> Seems like a missing include. C++ docs say `offsetof` is from ``,
> adding that include explicitly fixes the build. Seems to only happen with
> older GCCs, but it seems to be a happy accident it works on newer ones,
> prob
On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote:
> Seems like a missing include. C++ docs say `offsetof` is from ``,
> adding that include explicitly fixes the build. Seems to only happen with
> older GCCs, but it seems to be a happy accident it works on newer ones,
> prob
On Mon, 3 Jan 2022 08:10:27 GMT, Aleksey Shipilev wrote:
> Seems like a missing include. C++ docs say `offsetof` is from ``,
> adding that include explicitly fixes the build. Seems to only happen with
> older GCCs, but it seems to be a happy accident it works on newer ones,
> prob
On Tue, 11 Jan 2022 13:02:21 GMT, Claes Redestad wrote:
>> In `String.encodeUTF8_UTF16`, making the `char c` local to each loop helps
>> the performance of the method by helping C2 optimize each individual loop
>> better.
>>
>> Results on the updated micros:
>> 19-b04:
>>
>> Benchmark
On Tue, 4 Jan 2022 16:46:09 GMT, Aleksey Shipilev wrote:
> The real problem is Y2038
> ([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does
> not look solvable at this time. So for test cleanliness, we might just
> disable this test on 32-b
On Tue, 4 Jan 2022 16:46:09 GMT, Aleksey Shipilev wrote:
> The real problem is Y2038
> ([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does
> not look solvable at this time. So for test cleanliness, we might just
> disable this test on 32-b
On Mon, 3 Jan 2022 21:18:12 GMT, Victor Dyakov wrote:
> it requires @alexeysemenyukoracle review (owner of JDK-8274856 changeset)
Well, this looks trivial to me. Should we really wait @alexeysemenyukoracle,
who, I assume, might be on NY holiday break?
-
PR:
The real problem is Y2038
([JDK-8279444](https://bugs.openjdk.java.net/browse/JDK-8279444)), which does
not look solvable at this time. So for test cleanliness, we might just disable
this test on 32-bit platforms.
Additional testing:
- [x] Linux x86_64 fastdebug, affected test still passes
-
Seems like a missing include. C++ docs say `offsetof` is from ``,
adding that include explicitly fixes the build. Seems to only happen with older
GCCs, but it seems to be a happy accident it works on newer ones, probably
through the transitive include somewhere.
Additional testing:
- [x]
On Tue, 7 Dec 2021 13:12:13 GMT, Maurizio Cimadamore
wrote:
> When doing some unrelated performance measurements, I realized that segments
> backed by global scope were still paying a relatively high cost for liveness
> checks - that's because GlobalScopeImpl extends from SharedScopeImpl, and
On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev wrote:
> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all
> tests not defined in the lower tiers. `hotspot:tier4` has lots of them,
> mostly long-running vmTestbase tests, which take many hours even
On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev wrote:
> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all
> tests not defined in the lower tiers. `hotspot:tier4` has lots of them,
> mostly long-running vmTestbase tests, which take many hours even
On Fri, 3 Dec 2021 07:34:16 GMT, Alan Bateman wrote:
> No objection to the change, I think it is just a re-balancing of tiers for CI
> systems.
Yes, quite. @dholmes-ora, are you happy with Alan's assessment?
-
PR: https://git.openjdk.java.net/jdk/pull/6619
On Thu, 2 Dec 2021 12:15:51 GMT, David Holmes wrote:
> I've solicited feedback from core-libs folk as this affects them the most. At
> present we, Oracle, run the jdk_svc tests as part of hotspot testing, but
> this change will suddenly cause jdk testing to include them. That is probably
>
On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev wrote:
> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all
> tests not defined in the lower tiers. `hotspot:tier4` has lots of them,
> mostly long-running vmTestbase tests, which take many hours even
On Tue, 30 Nov 2021 23:35:08 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 Wed, 1 Dec 2021 02:29:14 GMT, David Holmes wrote:
> Hi @shipilev , We need to have someone look at the impact of this on our CI.
> I don't think we run the tier4 group as defined in our tier 4 so we may not
> see those execution time savings that offset the extra cost to tier3.
OK, I can
OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests
not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly
long-running vmTestbase tests, which take many hours even on a very parallel
machines.
This, unfortunately, has a chilling effect on
On Thu, 18 Nov 2021 07:40:34 GMT, David Holmes wrote:
>> Do we even have to have a flag on Java side? It looks like these calls are
>> only done as the upcalls from VM, so we might just keep the flag on VM side?
>
> @shipilev not sure what you mean by "a flag on the Java side". The Java code
On Thu, 18 Nov 2021 07:13:55 GMT, David Holmes wrote:
>> Huh, good catch! This was mostly left over from an earlier version of the
>> flag that used system properties, which aren't initialized until after the
>> Finalizer class is initialized.
>>
>> It might be the case that the Holder can be
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote:
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so
On Tue, 16 Nov 2021 05:24:38 GMT, Vicente Romero wrote:
> Please review this PR which aims to optimize the implementation of the
> `toString` method we provide for records. A benchmark comparing the
> implementation we are providing for records with lombok found out that lombok
> is much
On Fri, 22 Oct 2021 08:03:34 GMT, Hendrik Schreiber
wrote:
> Trivial improvement.
>
> Explicitly show how to create a `Cleaner` instance using `Cleaner.create()`.
> Repeat (again) in the code example that the `State` `Runnable `should be
> implemented as static class and not reference the
1 - 100 of 1039 matches
Mail list logo
