On Mon, 21 Aug 2023 06:15:07 GMT, Jaikiran Pai wrote:
> if multiple tests are running and try to acquire this file lock, then they
> might end up interfering with each other, but it's surprising that in some
> cases even after multiple attempts the file lock doesn't become available.
How long
On Mon, 21 Aug 2023 06:18:15 GMT, Vladimir Petko wrote:
> realpath call in getJavaPath() function translates the symbolic link into the
> binary path.
Okay so a specific API makes this work as intended.
What I can't determine is whether this may have an adverse effect on anyone
using an "unus
On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.3,1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVers
On Mon, 21 Aug 2023 04:38:56 GMT, David Holmes wrote:
> I get the sense from the comment in jexec.c that it is only intended to be
> launched via a full path, so having it in the $PATH seems like a usage error
> to me.
Unfortunately this executable is linked in /usr/bin and is assumed to work
> 8314491: Linux: jexec launched via PATH fails to find java
Vladimir Petko 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 additional
commits sin
On Wed, 16 Aug 2023 13:36:38 GMT, Matthias Baesken wrote:
> We run into some BackingStoreException: Couldn't get file lock. e.g. here :
>
> [JShell] Exception in thread "main" java.lang.IllegalStateException:
> java.util.prefs.BackingStoreException: Couldn't get file lock.
> [JShell] at
> jdk.
On Fri, 18 Aug 2023 12:30:45 GMT, Matthias Baesken wrote:
> errno 11 seems to be EAGAIN.
Sounds like the native code should be retrying in this case.
-
PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1685653886
On Fri, 18 Aug 2023 10:06:19 GMT, Vladimir Petko wrote:
> 8314491: Linux: jexec launched via PATH fails to find java
I get the sense from the comment in jexec.c that it is only intended to be
launched via a full path, so having it in the $PATH seems like a usage error to
me.
That said this ch
> Added a bunch of different implementations for Vector API Matrix
> Multiplications:
>
> - Baseline
> - Blocked (Cache Local)
> - FMA
> - Vector API Simple Implementation
> - Vector API Blocked Implementation
>
> Commit was discussed with @PaulSandoz
Martin Stypinski has updated the pull reque
On Fri, 18 Aug 2023 03:57:24 GMT, Martin Stypinski wrote:
> Added a bunch of different implementations for Vector API Matrix
> Multiplications:
>
> - Baseline
> - Blocked (Cache Local)
> - FMA
> - Vector API Simple Implementation
> - Vector API Blocked Implementation
>
> Commit was discussed w
On Fri, 18 Aug 2023 10:06:19 GMT, Vladimir Petko wrote:
> 8314491: Linux: jexec launched via PATH fails to find java
When jexec is found in the PATH, e.g. we run ``$jexec myjar.jar``, the
`argv[0]` contains `jexec` and Java can not be found.
Running updated test without fix in jexec.c:
$make
8314491: Linux: jexec launched via PATH fails to find java
-
Commit messages:
- Use /proc/self/exec to identify path to the executable.
- Create failing test for jexec in PATH issue
Changes: https://git.openjdk.org/jdk/pull/15343/files
Webrev: https://webrevs.openjdk.org/?repo=jdk
> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java
> failed with "InterruptedException: sleep interrupted" and related issues.
>
> This is a major ForkJoin update (and hard to review -- sorry) that finally
> addresses incompatibilities between ExecutorService and ForkJ
13 matches
Mail list logo
