> Automate setting up an environment for mac signing tests: create keychain(s),
> self-signing certificates, and register them in the system.
>
> To set up the environment, run `make test-only
> TEST=test/jdk/tools/jpackage/macosx/base/SigningBase.java
> JTREG=JAVA_OPTIONS=-Djpackage.test.SignE
> the test output was cleanup for common execution.
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
8351593: [JMH] test PhoneCode.Bulk reports NPE exception
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24011/f
I propose some cleanups to `FinalizerHistogramTest.java` to hopefully clear up
the intermittent failures:
* run with `othervm`: this test blocks the (global) finalizer thread, and also
requires the (global) finalizer thread to enter the test's `finalize()` method
* The test uses `volatile` ints,
On Wed, 19 Mar 2025 17:48:20 GMT, Naoto Sato wrote:
>> Upgrading the CLDR to version 47.0. A corresponding CSR has also been
>> drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Copyright year/bugid update
Marked as
On Thu, 20 Mar 2025 19:49:33 GMT, David M. Lloyd wrote:
> Provide method overloads to the ClassFile interface of the
> java.lang.classfile API which allow parsing of classes found in byte buffers
> and memory segments, as well as allowing built class files to be output to
> these types.
src/j
> Automate setting up an environment for mac signing tests: create keychain(s),
> self-signing certificates, and register them in the system.
>
> To set up the environment, run `make test-only
> TEST=test/jdk/tools/jpackage/macosx/base/SigningBase.java
> JTREG=JAVA_OPTIONS=-Djpackage.test.SignE
Provide method overloads to the ClassFile interface of the java.lang.classfile
API which allow parsing of classes found in byte buffers and memory segments,
as well as allowing built class files to be output to these types.
-
Commit messages:
- 8352536: Add overloads to parse and b
On Mon, 17 Mar 2025 08:27:20 GMT, Christoph Langer wrote:
>> Alternative approach to #24012
>>
>> This keeps the current handling of *.pdb vs *.stripped.pdb which allows
>> debugging at the cost of a little hack in jlink. Maybe the code in jlink can
>> be improved, e.g. make it more conditiona
On Wed, 12 Mar 2025 15:53:33 GMT, Vladimir Ivanov wrote:
> the test output was cleanup for common execution.
Is it make sense to restore the 'cmudict-0.7b.txt' from the old
'https://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks'?
-
PR Comment: https://git.openjdk.org/jdk/
On Tue, 18 Mar 2025 19:21:11 GMT, Leonid Mesnik wrote:
>> This PR tries to cut down the use of `WhiteBox` in the HotSpot test cases.
>> It modifies `VMProps` to save the set of VM properties into a file called
>> "vm.properties" under Jtreg's work directory. The new API
>> `jdk.test.lib.VMProp
On Wed, 12 Mar 2025 15:53:33 GMT, Vladimir Ivanov wrote:
> the test output was cleanup for common execution.
The root cause seems to be that `DataProviders.dictionary()` attempts to load a
dictionary file that isn't there, which means that the microbenchmark is likely
not testing what the orig
On Thu, 20 Mar 2025 09:44:07 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early is that this is a large change, and the
> Hi all,
>
> please review this change that implements (currently Draft) JEP: G1:
> Improve Application Throughput with a More Efficient Write-Barrier.
>
> The reason for posting this early is that this is a large change, and the JEP
> process is already taking very long with no end in sight
On Wed, 19 Mar 2025 00:29:49 GMT, David Holmes wrote:
>> Please review this PR that adds `@requires !jdk.static` to tests, thanks.
>>
>> - runtime/StackGap/TestStackGap.java
>> - runtime/StackGuardPages/TestStackGuardPages.java
>> - runtime/TLS/TestTLS.java
>> - runtime/jni/daemonDestroy/TestDae
On Thu, 20 Mar 2025 10:51:08 GMT, Severin Gehwolf wrote:
>> See the bug for rationale.
>>
>> This goal for this improvement is to be easily backportable, so we can catch
>> up with update releases. As such, it does a few borderline-trivial changes,
>> and _does not_ change the jspawnhelper pr
> After "JDK-8339480: Build static-jdk image with a statically linked launcher"
> AIX was not able to build the new target. Therefore with "JDK-8345590 AIX
> 'make all' fails after JDK-8339480" the new target was disabled again.
>
> Now with this change we can enable the statically linked launch
On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev wrote:
> See the bug for rationale.
>
> This goal for this improvement is to be easily backportable, so we can catch
> up with update releases. As such, it does a few borderline-trivial changes,
> and _does not_ change the jspawnhelper protoc
> Can I please get a review of this doc-only change which proposes to improve
> the API documentation of `DeflaterInputStream`, `DeflaterOutputStream`,
> `InflaterInputStream` and `InflaterOutputStream` classes?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8066583 some of the
> construct
On Thu, 20 Mar 2025 11:42:15 GMT, Aleksey Shipilev wrote:
> I have been thinking about this for the last several days, and I think we
> should be doing this relaxation consistently everywhere. Honestly, I don't
> expect the all distro issues to be fixed/deployed in the field before JDK 25
> GA
On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes wrote:
>> @magicus why can't we just use `-pthread` everywhere? My recollection is
>> that `-pthread` both sets compiler directives needed for pthread programming
>> and links to libpthread, so it seems to be what we should be using. ??
>
>> Anothe
On Mon, 17 Mar 2025 10:44:30 GMT, snake66 wrote:
>>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_
>>> Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything
>>> coming to mind directly that would make that infeasible, or is it just a
>>> matter of te
On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev wrote:
> See the bug for rationale.
>
> This goal for this improvement is to be easily backportable, so we can catch
> up with update releases. As such, it does a few borderline-trivial changes,
> and _does not_ change the jspawnhelper protoc
On Thu, 20 Mar 2025 11:09:34 GMT, Alan Bateman wrote:
> In any case, I don't think we should change main line as it currently targets
> JDK 25 so won't GA for 6 months. Maybe there is a case to re-examine in the
> update releases where the jspawnhelper checks were back ported but I think we
>
On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev wrote:
> See the bug for rationale.
>
> This goal for this improvement is to be easily backportable, so we can catch
> up with update releases. As such, it does a few borderline-trivial changes,
> and _does not_ change the jspawnhelper protoc
On Thu, 20 Mar 2025 10:53:49 GMT, Aleksey Shipilev wrote:
> I used to think the same, but with every new report we are seeing, I think we
> need to re-evaluate. From the bug: "To emphasize, this is not a bugfix, as
> version checks still a valid thing to do. This is merely a pragmatic
> conces
On Thu, 20 Mar 2025 10:09:31 GMT, Alan Bateman wrote:
> Something is very broken if the JDK is being overridden while in use.
Yes, that was the original thinking for jspawnhelper version checks.
> So I don't think I agree that relaxing the check is the right thing to do,
> it's not fixing the
See the bug for rationale.
This goal for this improvement is to be easily backportable, so we can catch up
with update releases. As such, it does a few borderline-trivial changes, and
_does not_ change the jspawnhelper protocol. So the overwrite of `jspawnhelper`
with this new version would be
27 matches
Mail list logo
