On Tue, 1 Oct 2024 12:40:57 GMT, Matthias Baesken wrote:
>> src/java.base/macosx/native/libjli/java_md_macosx.m line 315:
>>
>>> 313: rc = pthread_create(&main_thr, NULL, &apple_main, &args);
>>> 314: if (rc != 0) {
>>> 315: JLI_ReportErrorMessageSys("Could not create main thread
On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken wrote:
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((format (printf, 1, 2))).'
> Should
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:66
On Mon, 24 Jun 2024 09:40:14 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit
> [bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e6
Hi all,
This pull request contains a backport of
[JDK-8222884](https://bugs.openjdk.org/browse/JDK-8222884), commit
[bd046d9b](https://github.com/openjdk/jdk/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backpo
> The commit being backported was authored by Rajan Halade on 21 Jun 2024 and
> was reviewed by Christoph Langer and Sean Mullan.
>
> Thanks!
Thanks for doing the backport.
-
Marked as reviewed by clanger (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19841#pullrequestreview-2133855195
On Thu, 20 Jun 2024 18:35:00 GMT, Rajan Halade wrote:
> Updated all the tests that depend on external infrastructure services as
> manual. These tests may fail with external reasons, for instance - change in
> CA test portal, certificate status updates, or network issues.
Looks good, although
On Mon, 17 Jun 2024 08:19:18 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8211847](https://bugs.openjdk.org/browse/JDK-8211847), commit
> [f5213671](https://github.com/openjdk/jdk/commit/f5213671f7b636b32bb93c78e43696a61cd69b
backported was authored by Christoph Langer on 13 Jun 2024 and
was reviewed by Thomas Stuefe.
Thanks!
-
Commit messages:
- Backport f5213671f7b636b32bb93c78e43696a61cd69bae
Changes: https://git.openjdk.org/jdk/pull/19742/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=1
On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
This pull request has now been integrated.
Changeset: f5213671
Author: Christoph Langer
URL:
https://git.openjdk.org/jdk/com
On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
Trivial fix of test listing, so
-
PR Comment: https://git.openjdk.org/jdk/pull/19691#issuecomment-2165639694
On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
Maybe [this
one](https://github.com/openjdk/jdk/commit/4d9042043ecade75d50c25574a445e6b8ef43618)?
But just guessing...
-
PR Comment: ht
It seems the error is gone meanwhile. So we can reenable the test.
-
Commit messages:
- JDK-8211847
Changes: https://git.openjdk.org/jdk/pull/19691/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19691&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8211847
Stats: 1
On Wed, 15 May 2024 11:40:38 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could n
On Tue, 7 May 2024 08:08:05 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could no
On Fri, 3 May 2024 15:25:05 GMT, Joachim Kern wrote:
>> Since ~ end of March, after
>> [JDK-8329131](https://bugs.openjdk.org/browse/JDK-8329131),
>> tools/launcher/JliLaunchTest.java fails on AIX. Failure is :
>>
>> stdout: [];
>> stderr: [Error: could not find libjava.so
>> Error: Could no
On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Fri, 19 Apr 2024 10:07:22 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Tue, 16 Apr 2024 10:20:23 GMT, Alan Bateman wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> I think this is way too ad hoc and looks like lefts over from a debugging
> session. So I
On Thu, 18 Apr 2024 06:57:05 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Mon, 15 Apr 2024 12:47:08 GMT, Matthias Baesken wrote:
> > If we expand the tracing then I think it should be consistent with the
> > existing tracing.
>
> What exactly do you see as inconsistent ?
Maybe the output of the tracing should look similar to other traces done
through `JLI_TraceL
On Tue, 9 Apr 2024 15:28:08 GMT, Matthias Baesken wrote:
> We have already good JLI tracing capabilities. But GetApplicationHome and
> GetApplicationHomeFromDll lack some tracing and should be enhanced.
To me this looks useful, although maybe the overall JLI tracing could be
revisited.
src/ja
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/CoreLibraries.gmk:194:
On Mon, 4 Mar 2024 15:02:45 GMT, Aleksei Efimov wrote:
>>> As for the test, I had a closer look now and I find it hard to separate
>>> testing of [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) from
>>> [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). Furthermore,
>>> mos
On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer wrote:
> During analysing a customer case I figured out that we have an inconsistency
> between documentation and actual behavior in class
> com.sun.jndi.ldap.Connection. The [method documentation of
> com.sun.jndi.lda
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Tue, 19 Mar 2024 16:09:18 GMT, Aleksei Efimov wrote:
>> Christoph Langer 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 cont
On Tue, 19 Mar 2024 16:01:34 GMT, Aleksei Efimov wrote:
>> Christoph Langer 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 cont
On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer wrote:
> 4f336085d1098e7fba7b58f0a73c028179a2a13d
> ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few
> cases to test java/util/Formatter/Padding.java with huge Strings as
> arguments. Since all possi
On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti
wrote:
>> Christoph Langer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Generate large strings in parameter generator methods
>
> I wa
On Thu, 7 Mar 2024 17:37:59 GMT, Christoph Langer wrote:
> > > Thanks for exploring the possibility of improving tracebility of test
> > > invocations to reported bugs.
> > > >
> >
> >
> > I've given this test change a second thought,
On Thu, 7 Mar 2024 17:38:24 GMT, Christoph Langer wrote:
>> src/java.naming/share/classes/module-info.java line 42:
>>
>>> 40: * The value of this environment property specifies the
>>> fully
>>> 41: * qualified class name of the socket
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
the one large @ParameterizedTest into
> multiple ones. With that, I could run the test successfully in a test VM with
> 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm
> -Xmx96m Padding`
Christoph Langer has updated the pull request incrementally with one additi
On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti
wrote:
> Can you please add the bug id to `@bug` and correct the typo, as suggested
> [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?
Done.
I kept the tenMillion... handling.
-
PR Comment: https://g
the one large @ParameterizedTest into
> multiple ones. With that, I could run the test successfully in a test VM with
> 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm
> -Xmx96m Padding`
Christoph Langer has updated the pull request incrementally with one addition
On Wed, 13 Mar 2024 09:42:34 GMT, Raffaello Giulietti
wrote:
> What about factoring out the 4 invocations of `tenMillionBlanks()` in each
> source method in a local var?
OK, I inlined the generation of the ten million character strings into the
parameter generator methods. I looked a bit at t
4f336085d1098e7fba7b58f0a73c028179a2a13d
([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases
to test java/util/Formatter/Padding.java with huge Strings as arguments. Since
all possible argument combinations for the test are stored in one array,
nothing can be garbage
On Wed, 6 Mar 2024 14:42:09 GMT, Aleksei Efimov wrote:
>> Christoph Langer 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 cont
On Mon, 4 Mar 2024 15:02:45 GMT, Aleksei Efimov wrote:
> > Thanks for exploring the possibility of improving tracebility of test
> > invocations to reported bugs.
> > >
>
> I've given this test change a second thought, maybe you can try to separate
> the test into two separate test classes? On
On Thu, 7 Mar 2024 08:16:26 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally with
On Wed, 6 Mar 2024 16:30:23 GMT, Matthias Baesken wrote:
>> We define the RESTARTABLE macro again and again at a lot of places in the
>> JDK native codebase. This could be centralized to avoid repeating it again
>> and again !
>
> Matthias Baesken has updated the pull request incrementally with
On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote:
> The new test JmodExcludedFiles.java checks that no debug symbol files are
> contained in the jmod files. It does not take into account that with
> configure option --with-external-symbols-in-bundles=public we want to have
&
On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote:
> The new test JmodExcludedFiles.java checks that no debug symbol files are
> contained in the jmod files. It does not take into account that with
> configure option --with-external-symbols-in-bundles=public we want to have
&
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Wed, 28 Feb 2024 12:32:17 GMT, Matthias Baesken wrote:
> Looks okay to me, but could we print here `RuntimeException(jmodFile + " is
> expected not to include native debug symbols` not only the jmod but also the
> unwanted file(s) ?
This information is already printed in isNativeDebugSymbol
On Fri, 23 Feb 2024 19:18:46 GMT, Christoph Langer wrote:
> The new test JmodExcludedFiles.java checks that no debug symbol files are
> contained in the jmod files. It does not take into account that with
> configure option --with-external-symbols-in-bundles=public we want to have
&
On Tue, 27 Feb 2024 16:48:05 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>> compiler.rtm.locking.TestRTMTot
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>> compiler.rtm.locking.TestRTMTot
On Sat, 24 Feb 2024 11:45:46 GMT, Jaikiran Pai wrote:
> This is similar to what other test libraries usually report for such failures.
But in the case of a non-empty `msg` you would not see the actual values any
more which I think could be helpful in a lot of cases...
-
PR Comment
The new test JmodExcludedFiles.java checks that no debug symbol files are
contained in the jmod files. It does not take into account that with configure
option --with-external-symbols-in-bundles=public we want to have stripped pdb
files, also in jmods, to get native callstacks with line number.
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>> compiler.rtm.locking.TestRTMTot
On Thu, 22 Feb 2024 14:57:05 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>> compiler.rtm.locking.TestRTMTot
On Wed, 21 Feb 2024 18:26:18 GMT, Aleksei Efimov wrote:
>>> Currently, it is hard to distinguish what part of the test responsible for
>>> [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and
>>> which part is for
>>> [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579
On Mon, 19 Feb 2024 16:46:18 GMT, Aleksei Efimov wrote:
> Currently, it is hard to distinguish what part of the test responsible for
> [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and which
> part is for [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). I
> wou
On Mon, 19 Feb 2024 16:57:23 GMT, Aleksei Efimov wrote:
>> Christoph Langer 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 Mon, 19 Feb 2024 13:17:48 GMT, Goetz Lindenmaier wrote:
>> Christoph Langer 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 Fri, 16 Feb 2024 16:39:33 GMT, Daniel Fuchs wrote:
>> Christoph Langer 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, 20 Feb 2024 09:45:22 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Thu, 15 Feb 2024 15:11:15 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
ort unconnected sockets would simply fail
> with an IOException.
>
> So we should either make the code adhere to what is documented or adapt the
> documentation to the actual behavior.
>
> I hereby try to fix the connect coding. Alternatively, we could also adapt
> the descri
On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer wrote:
> During analysing a customer case I figured out that we have an inconsistency
> between documentation and actual behavior in class
> com.sun.jndi.ldap.Connection. The [method documentation of
> com.sun.jndi.lda
During analysing a customer case I figured out that we have an inconsistency
between documentation and actual behavior in class
com.sun.jndi.ldap.Connection. The [method documentation of
com.sun.jndi.ldap.Connection::createSocket](https://github.com/openjdk/jdk/blob/3ebe6c192a5dd5cc46ae2d263713c
On Wed, 17 Jan 2024 15:38:22 GMT, Richard Reingruber wrote:
>> Set `interrupted` in `Thread::interrupt` before reading `nioBlocker` for
>> correct (Dekker scheme) synchronization with concurrent execution of
>> [`AbstractInterruptibleChannel::begin`](https://github.com/openjdk/jdk/blob/59062402
On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bjørsnøs wrote:
>> This PR suggests that `Files.setPosixPermissions`as implemented by
>> `ZipFileSystem` should preserve the leading seven bits of the 'external file
>> attributes' field. These bits contain the 'file type', 'setuid', 'setgid',
>> and 'sti
On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer wrote:
> In the review of the PR for JDK-8322417 it was noted that a fully qualified
> class name "java.util.Arrays" is unnecessary but it was forgotten to clean it
> up prior to integration.
Integrating under trivial rule.
On Fri, 29 Dec 2023 13:44:27 GMT, Christoph Langer wrote:
> In the review of the PR for JDK-8322417 it was noted that a fully qualified
> class name "java.util.Arrays" is unnecessary but it was forgotten to clean it
> up prior to integration.
This pull request has
In the review of the PR for JDK-8322417 it was noted that a fully qualified
class name "java.util.Arrays" is unnecessary but it was forgotten to clean it
up prior to integration.
-
Commit messages:
- JDK-8322417
Changes: https://git.openjdk.org/jdk/pull/17203/files
Webrev: https:
On Fri, 1 Dec 2023 13:46:14 GMT, Matthias Baesken wrote:
> On Windows we recently run into this error rather often in the test
> LdapPoolTimeoutTest.java :
>
> MSG RTE: javax.naming.CommunicationException: example.com:1234 [Root
> exception is java.net.ConnectException: Connection timed out: n
On Wed, 22 Nov 2023 15:59:38 GMT, Christoph Langer wrote:
> java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already
> problem listed on linux-x64. However, the issue is not processor specific. We
> see the failure on linux on other architectures as well.
This pull re
java/lang/invoke/lambda/LambdaFileEncodingSerialization.java is already problem
listed on linux-x64. However, the issue is not processor specific. We see the
failure on linux on other architectures as well.
-
Commit messages:
- Update ProblemList.txt
Changes: https://git.openjdk.o
On Tue, 5 Sep 2023 13:52:09 GMT, Roger Riggs wrote:
> A bit late due to a US holiday. Looks good.
Thanks 🙇
-
PR Comment: https://git.openjdk.org/jdk/pull/15222#issuecomment-1706695064
On Thu, 10 Aug 2023 09:54:43 GMT, Christoph Langer wrote:
> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run
> as user that is member of the Administrators group. In that case new files
> are not owned by the user but instead by BUILTIN\ADMINISTRATORS. Th
On Fri, 1 Sep 2023 08:32:20 GMT, Christoph Langer wrote:
>> On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run
>> as user that is member of the Administrators group. In that case new files
>> are not owned by the user but instead by BUILTIN\ADMINISTR
ck. My suggestion is to cater for
> this case and don't fail the test but write a warning message to stdout that
> a whoami check is not correctly possible.
Christoph Langer has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev ex
On Thu, 31 Aug 2023 15:08:34 GMT, Roger Riggs wrote:
>> The problem with the environment variables is, that jtreg only passes very
>> few of them down to the testee process - USERDOMAIN and USERNAME are not
>> part of these as far as I know.
>
> ok, more overhead than value in the suggestion.
On Mon, 28 Aug 2023 05:24:09 GMT, Arno Zeller wrote:
>> I think you might use System.getProperty("user.name"). But I am not sure
>> about domain names of users on Windows.
>> I am also not sure why the user name is currently determined by creating a
>> file - there might be a reason for this th
On Windows, the test java/lang/ProcessHandle/InfoTest.java can fail when run as
user that is member of the Administrators group. In that case new files are not
owned by the user but instead by BUILTIN\ADMINISTRATORS. This breaks the
assumptions of the test's whoami check. My suggestion is to cat
On Tue, 1 Aug 2023 21:57:17 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8311822](https://bugs.openjdk.org/browse/JDK-8311822), commit
> [d1cc2782](https://github.com/openjdk/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e851ed
Hi all,
This pull request contains a backport of
[JDK-8311822](https://bugs.openjdk.org/browse/JDK-8311822), commit
[d1cc2782](https://github.com/openjdk/jdk/commit/d1cc2782606e8a3cfead9055aa845e48e851edd4)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backpo
On Fri, 28 Jul 2023 09:10:20 GMT, Alan Bateman wrote:
> JDK-8308609
I added a comment on https://bugs.openjdk.org/browse/JDK-8303498, cc
@offamitkumar
-
PR Comment: https://git.openjdk.org/jdk21/pull/149#issuecomment-1655513822
On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov wrote:
> This patch adds the java/lang/ScopedValue/StressStackOverflow.java to the
> problem list for linux-x86 where it intermittently fails on a GA, ex:
> https://github.com/openjdk/jdk21/pull/148
>
> This is only for JDK 21, test passes on
On Wed, 5 Jul 2023 15:01:52 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last revi
On Thu, 22 Jun 2023 09:21:29 GMT, Matthias Baesken wrote:
>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
>> line 196:
>>
>>> 194:
>>> 195: /**
>>> 196: * Set whether or not to use ct.sym as an alternate
>>
>> As an alternate to what? This needs somet
On Fri, 30 Jun 2023 11:37:10 GMT, Matthias Baesken wrote:
>> There are a few references to rt.jar in comments and in the codebase itself.
>> Some of them might be removed or adjusted.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last rev
On Thu, 22 Jun 2023 11:51:15 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode c
On Thu, 22 Jun 2023 09:53:29 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode c
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("checking if debug mode codes
On Fri, 19 May 2023 09:46:59 GMT, Matthias Baesken wrote:
>> MappedMemoryUtils.c can generate exceptions like those :
>> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>>at
>> java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>>at java.ba
On Wed, 11 Jan 2023 09:21:18 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit
> [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2f
On Wed, 11 Jan 2023 17:01:26 GMT, Naoto Sato wrote:
>> Hi all,
>>
>> This pull request contains a backport of
>> [JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit
>> [3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2)
>> from the [openjd
Hi all,
This pull request contains a backport of
[JDK-8299439](https://bugs.openjdk.org/browse/JDK-8299439), commit
[3b374c01](https://github.com/openjdk/jdk/commit/3b374c0153950ab193f3a188b57d3404b4ce2fe2)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backpo
On Fri, 22 Jul 2022 15:09:13 GMT, Christoph Langer wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is r
On Thu, 21 Jul 2022 18:48:14 GMT, Jorn Vernee wrote:
> This patch removes the use of std::thread from the `java.lang.foreign` tests,
> and switches to the OS specific thread APIs, in order to change things such
> as the stack size on some platforms where this is required in the future (see
> t
On Fri, 22 Jul 2022 07:04:29 GMT, Christoph Langer wrote:
> Hi all,
>
> This pull request contains a backport of
> [JDK-8290460](https://bugs.openjdk.org/browse/JDK-8290460), commit
> [d7f0de27](https://github.com/openjdk/jdk/commit/d7f0de272c85ee8d0890c9d61e10065b618b69
1 - 100 of 107 matches
Mail list logo