This test was recently dialled down via JDK-8323002 but it still makes slow
progress on some test machines, esp. macox-x64-debug builds. The issue is that
the the sampling of the target thread is skewed towards the unmounted case so
the target thread is disabled from being scheduled and doesn't
On Fri, 8 Dec 2023 20:28:20 GMT, Eirik Bjørsnøs wrote:
> This PR suggests we retire the binary test vectors `ZipFile/input.zip`,
> `ZipFile/input.jar` and `ZipFile/crash.jar`
>
> Binary test vectors are harder to analyze, and sharing test vectors across
> unrelated tests increases
On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bjørsnøs wrote:
> > Sounds like a CSR is needed for the behavioral change proposed here.
>
> Thanks for flagging this @jddarcy
>
> I'm personally not 100% convinced a CSR is warranted in this case, but I'm of
> course happy to extend the following into
On Mon, 14 Aug 2023 07:48:00 GMT, Matthias Baesken wrote:
> Currently there is a number of functionality that would be interesting to
> have for shared lib load operations in the JDK C code.
> Some examples :
> Events::log_dll_message for hs-err files reporting
> JFR event NativeLibraryLoad
>
> Added mirror event with static methods: jdk.internal.event.SelectionEvent
> that provides the duration of select calls and the count of how many keys are
> available.
>
> Emit the event from SelectorImpl::lockAndDoSelect
>
> Test at jdk.jfr.event.io.TestSelectionEvents
Tim Prinzing has
On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato wrote:
> Backporting the document only fix to jdk22
This pull request has now been integrated.
Changeset: 6951987b
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk22/commit/6951987b65e50143ee3f1f79f7731159a0310223
Stats: 5 lines in
On Tue, 9 Jan 2024 07:29:49 GMT, Eirik Bjørsnøs wrote:
>> This PR suggests we retire the binary test vectors `ZipFile/input.zip`,
>> `ZipFile/input.jar` and `ZipFile/crash.jar`
>>
>> Binary test vectors are harder to analyze, and sharing test vectors across
>> unrelated tests increases
On Wed, 10 Jan 2024 20:54:20 GMT, Peter Levart wrote:
> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It
> returns `-1` (meaning that regions are equal) when passing the same instance
> of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless
> of
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A couple key things we want to be able to say are:
> -
On Wed, 10 Jan 2024 16:09:14 GMT, Viktor Klang wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add links to new Memory Consistency section in package doc
>
>
On Sat, 18 Nov 2023 01:56:11 GMT, Mandy Chung wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove hyphen in 'strongly reachable' in Cleaner
>
> src/java.base/share/classes/java/lang/ref/Reference.java line
On Wed, 20 Dec 2023 18:51:08 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
> Please review this PR which splits up the _LocaleProvidersRun_ test file for
> performance and maintenance reasons.
>
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR,
> HOST, SPI, etc.) was getting rather long, as all related bugs were added to
> the single test
On Wed, 10 Jan 2024 21:23:48 GMT, Naoto Sato wrote:
> Still looks good. Please modify the copyright year for
> `HostLocaleProviderAdapter_md.c` file before integrating
Totally missed that, thanks for catching. Will integrate after re-testing VM
tiers.
-
PR Comment:
On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato wrote:
> Backporting the document only fix to jdk22
Marked as reviewed by iris (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/59#pullrequestreview-1814223539
On Wed, 10 Jan 2024 20:43:19 GMT, Mandy Chung wrote:
> `jdk.test.lib.process.ProcessTools::executeTools` was modified to throw
> Exception by JDK-8322920 that has only been in the main line. It's a
> mistake to backport JDK-8322809 without catching this. Trivial fix - update
> the
On Wed, 10 Jan 2024 21:05:53 GMT, Justin Lu wrote:
>> Please review this PR which splits up the _LocaleProvidersRun_ test file for
>> performance and maintenance reasons.
>>
>> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR,
>> HOST, SPI, etc.) was getting rather
On Fri, 15 Dec 2023 11:15:30 GMT, Lance Andersen wrote:
>> Seeing that `ReadAfterClose.java` uses a binary test vector `crash.jar`, I
>> think it makes sense to include it in this PR, convert it to JUnit and move
>> it into `ReadZip.readAfterClose`.
>>
>> This removes the last remaining
On Wed, 10 Jan 2024 18:29: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
On Wed, 10 Jan 2024 20:43:19 GMT, Mandy Chung wrote:
> `jdk.test.lib.process.ProcessTools::executeTools` was modified to throw
> Exception by JDK-8322920 that has only been in the main line. It's a
> mistake to backport JDK-8322809 without catching this. Trivial fix - update
> the
I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It
returns `-1` (meaning that regions are equal) when passing the same instance of
MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of
whether `srcFromOffset` and `dstFromOffset` as well as
Please review this PR which implements toString() for the `Format` subclasses.
Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
The general specification follows a template that provides the locale (if the
class is localized) and any relevant patterns. The
On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato wrote:
> Backporting the document only fix to jdk22
Marked as reviewed by rriggs (Reviewer).
-
PR Review: https://git.openjdk.org/jdk22/pull/59#pullrequestreview-1814171861
> Please review this PR which splits up the _LocaleProvidersRun_ test file for
> performance and maintenance reasons.
>
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR,
> HOST, SPI, etc.) was getting rather long, as all related bugs were added to
> the single test
Backporting the document only fix to jdk22
-
Commit messages:
- Backport 3bd9042054116365323912ed5867b70936fe85c4
Changes: https://git.openjdk.org/jdk22/pull/59/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22=59=00
Issue: https://bugs.openjdk.org/browse/JDK-8320788
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A couple key things we want to be able to say are:
> -
`jdk.test.lib.process.ProcessTools::executeTools` was modified to throw
Exception by JDK-8322920 that has only been in the main line. It's a mistake
to backport JDK-8322809 without catching this. Trivial fix - update the
signature to throw Throwable instead.
-
Commit messages:
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar
On Wed, 10 Jan 2024 18:03:32 GMT, Viktor Klang wrote:
>> While this might not fix 8314515, it should at least make it more exact.
>
> Viktor Klang has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains two commits:
>
> - Cleaning up
>1/ Is there a reason why the integrator is not declared greedy (I'm still not
>sure to what exactly Greedy means in the context of gatherers) ?
No, that was just a (benign) omission from typing the solution as I was typing
the email
>2/ Is there a reason to write the code in a OOP way like
On Tue, 9 Jan 2024 16:48:56 GMT, Jatin Bhateja wrote:
>> Hi,
>>
>> Patch optimizes non-subword vector compress and expand APIs for x86 AVX2
>> only targets.
>> Upcoming E-core Xeons (Sierra Forest) and Hybrid CPUs only support AVX2
>> instruction set.
>> These are very frequently used APIs in
> Adds serialization misdeclaration events to JFR.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Small space optimization.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17129/files
- new:
On Tue, 9 Jan 2024 00:51:28 GMT, Naoto Sato wrote:
> Adding an explanation of the locale-related system properties in the
> `System.getProperties()` method. Corresponding CSR has also been drafted.
This pull request has now been integrated.
Changeset: 3bd90420
Author:Naoto Sato
URL:
On Tue, 9 Jan 2024 23:40:35 GMT, Naoto Sato wrote:
>> Adding an explanation of the locale-related system properties in the
>> `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge
> or a
> Add a few apiNote concerning source-level modifiers that are not represented
> in java.lang.reflect.Modifier.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Implement review feedback.
-
Changes:
- all:
On Wed, 3 Jan 2024 06:43:22 GMT, Joe Darcy wrote:
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec,
On Wed, 10 Jan 2024 17:41:41 GMT, Raffaello Giulietti
wrote:
>> The spec is silent about methods being 'native'; it would generally be
>> impractical to implement native methods for these purposes, but a native
>> method can implement the behavior.
>
> @RogerRiggs The checks are agnostic
On Wed, 10 Jan 2024 18:27:45 GMT, Pavel Rappo wrote:
> > /contributor add @pavelrappo
>
> Thanks, Joe. Making me an "overriding author" was a bit over the top. :)
Skimmed the docs too quickly when looking for a "co-author" command :-)
-
PR Comment:
On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec,
On Wed, 10 Jan 2024 13:18:17 GMT, Jorn Vernee wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [d2d58dd6](https://github.com/openjdk/jdk/commit/d2d58dd6a8ec366a4bc3eb12a253b252de24557e)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy wrote:
>> As recently discussed on core libs, sealed-ness information could be
>> included in the Class.toGenericString() output, analagous to how "modifiers"
>> that also correspond to JVM access flags are handled.
>>
>> This is the initial spec,
On Wed, 10 Jan 2024 17:37:11 GMT, Lance Andersen wrote:
> Extra credit to convert this from testng to a junit test but not a must
Challenge accepted, see 885871f for the conversion to JUnit 5.
-
PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1885395478
> 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 'sticky' bits. These are unrelated to permissions and should not
On Wed, 20 Dec 2023 21:28:04 GMT, Serguei Spitsyn wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [0f8e4e0a](https://github.com/openjdk/jdk/commit/0f8e4e0a81257c678e948c341a241dc0b810494f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Tue, 9 Jan 2024 22:16:59 GMT, Mandy Chung wrote:
> This pull request contains a backport of commit
> [f3be138e](https://github.com/openjdk/jdk/commit/f3be138eb80c9e7f6cc21afb75cda9e49b667c8a)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being backported
> From: "Viktor Klang"
> To: "David Alayachew" , "core-libs-dev"
>
> Sent: Wednesday, January 10, 2024 2:33:45 PM
> Subject: Re: Gatherers -- conditionalWindowFixed?
> Hi David!
> Apologies for the late reply, there's been lots of catching up to do after the
> holidays.
> >I'm really excited
> As recently discussed on core libs, sealed-ness information could be included
> in the Class.toGenericString() output, analagous to how "modifiers" that also
> correspond to JVM access flags are handled.
>
> This is the initial spec, implementation, and test updated needed for that
> change.
On Wed, 10 Jan 2024 17:37:11 GMT, Lance Andersen wrote:
> Thank you for the PR. Overall it looks good a few couple nit comments.
Thanks Lance, see e4a505fa073874824f247c20b76c3531a068ee32 for the latest
update following your review.
> test/jdk/jdk/nio/zipfs/TestPosix.java line 761:
>
>> 759:
> 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 'sticky' bits. These are unrelated to permissions and should not
On Wed, 10 Jan 2024 18:01:01 GMT, Viktor Klang wrote:
>> While this might not fix 8314515, it should at least make it more exact.
>
> Viktor Klang has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains two commits:
>
> - Cleaning up
> While this might not fix 8314515, it should at least make it more exact.
Viktor Klang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains two commits:
- Cleaning up Fairness.java:s underlying queue implementation access
- Improving
Hi all,
This pull request contains a backport of commit
[d2d58dd6](https://github.com/openjdk/jdk/commit/d2d58dd6a8ec366a4bc3eb12a253b252de24557e)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Jorn Vernee on 10 Jan 2024 and was
On Wed, 10 Jan 2024 17:18:41 GMT, Alan Bateman wrote:
>> While this might not fix 8314515, it should at least make it more exact.
>
> test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 42:
>
>> 40: private static void testFairness(boolean fair,
>> 41:
On Wed, 10 Jan 2024 17:02:03 GMT, Weibing Xiao wrote:
> Better Error Handling for Jar Tool When Processing Non-existent Files.
> It is a clean backport.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk22/pull/55
On Wed, 10 Jan 2024 17:02:03 GMT, Weibing Xiao wrote:
> Better Error Handling for Jar Tool When Processing Non-existent Files.
> It is a clean backport.
Use this PR instead https://github.com/openjdk/jdk22/pull/56.
-
PR Comment:
Better Error Handling for Jar Tool When Processing Non-existent Files.
It needs to be backported to JDK22.
-
Commit messages:
- Backport 8ae309ebacd6947bbad2ef168ca13702e1cba099
Changes: https://git.openjdk.org/jdk22/pull/56/files
Webrev:
On Wed, 10 Jan 2024 16:58:43 GMT, Roger Riggs wrote:
>> I'm not sure that a `native` method is not considered effective by
>> serialization. I have to check.
>
> The spec is silent about methods being 'native'; it would generally be
> impractical to implement native methods for these purposes,
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
On Tue, 9 Jan 2024 23:55:30 GMT, Naoto Sato wrote:
> Backporting the document clarification to JDK22
This pull request has now been integrated.
Changeset: 46b1b1ae
Author:Naoto Sato
URL:
https://git.openjdk.org/jdk22/commit/46b1b1ae8ddc9466bda5af5ba2e917ded3352f4d
Stats: 81
On Wed, 10 Jan 2024 16:55:58 GMT, Roger Riggs wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changes according to reviewers feedback.
>
>
On Wed, 10 Jan 2024 16:49:50 GMT, Roger Riggs wrote:
>> Conceptually, these are independent types. There's no logical relationship
>> between them. Sharing a zero length array would convey a false sense of
>> logical sharing.
>
> true, but its wasted space and IMHO ok as a local and private
On Tue, 12 Dec 2023 15:13:01 GMT, Viktor Klang wrote:
> While this might not fix 8314515, it should at least make it more exact.
test/jdk/java/util/concurrent/SynchronousQueue/Fairness.java line 42:
> 40: private static void testFairness(boolean fair,
> 41:
Better Error Handling for Jar Tool When Processing Non-existent Files.
It is a clean backport.
-
Commit messages:
- Backport 8ae309ebacd6947bbad2ef168ca13702e1cba099
Changes: https://git.openjdk.org/jdk22/pull/55/files
Webrev: https://webrevs.openjdk.org/?repo=jdk22=55=00
On Tue, 19 Dec 2023 15:58:10 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java
>> line 185:
>>
>>> 183: commitEvent(PRIV_METH_NON_STATIC,
>>> 184: m + " must be non-static to be effective");
>>> 185:
On Wed, 10 Jan 2024 15:43:46 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Changes according to reviewers feedback.
On Mon, 8 Jan 2024 18:21:06 GMT, Joe Darcy wrote:
> Sounds like a CSR is needed for the behavioral change proposed here.
Thanks for flagging this @jddarcy
I'm personally not 100% convinced a CSR is warranted in this case, but I'm of
course happy to extend the following into a CSR if you or
On Tue, 9 Jan 2024 10:41:31 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java
>> line 53:
>>
>>> 51: private static final Class[] READ_OBJECT_NO_DATA_PARAM_TYPES =
>>> {};
>>> 52: private static final Class[]
On Mon, 8 Jan 2024 21:13:25 GMT, Viktor Klang wrote:
> As per conversation in the issue.
This pull request has now been integrated.
Changeset: b86c3b7a
Author:Viktor Klang
URL:
https://git.openjdk.org/jdk/commit/b86c3b7a68335d57699ea3c5ec6d09a62ea9026a
Stats: 8 lines in 3 files
On Tue, 9 Jan 2024 10:46:27 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java
>> line 70:
>>
>>> 68: privilegedCheckAccessibleMethod(cl, WRITE_REPLACE_NAME,
>>> 69: WRITE_REPLACE_PARAM_TYPES,
On Tue, 12 Dec 2023 23:36:30 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
> Adds serialization misdeclaration events to JFR.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Changes according to reviewers feedback.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17129/files
-
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar
On Wed, 10 Jan 2024 15:22:06 GMT, Maurizio Cimadamore
wrote:
>> 8321786: SegmentAllocator:allocateFrom(ValueLayout,
>> MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
>
> test/jdk/java/foreign/TestSegmentAllocators.java line 234:
>
>> 232: //
On Tue, 9 Jan 2024 08:10:16 GMT, Per Minborg wrote:
> 8321786: SegmentAllocator:allocateFrom(ValueLayout,
> MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
Marked as reviewed by mcimadamore (Reviewer).
-
PR Review:
On Tue, 9 Jan 2024 08:10:16 GMT, Per Minborg wrote:
> 8321786: SegmentAllocator:allocateFrom(ValueLayout,
> MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
test/jdk/java/foreign/TestSegmentAllocators.java line 234:
> 232: // WrongThreadException if this
JMH microbenchmarks may have dependencies on artifacts in the test image
outside of the benchmarks.jar. This includes native libraries (built into
`$TEST_IMAGE/micro/native`) and may soon include other test libraries like
wb.jar (built into `$TEST_IMAGE/lib-test/`)
By moving execution to the
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar
On Wed, 10 Jan 2024 14:58:37 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 3998:
>>
>>> 3996: int i = ArraysSupport.mismatch(m1, m2, len1);
>>> 3997: if (i != -1)
>>> 3998: return Integer.compareUnsigned(m1[i], m2[i])
On Wed, 10 Jan 2024 14:48:21 GMT, Roger Riggs wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 20 commits:
>>
>> - Use Integer.compareUnsigned
>> - Update copyright years and headers
>> - Merge branch
On Tue, 9 Jan 2024 17:11:42 GMT, Maurizio Cimadamore
wrote:
>> 8321786: SegmentAllocator:allocateFrom(ValueLayout,
>> MemorySegment,ValueLayout,long,long) spec mismatch in exception scenario
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1944:
>
>> 1942: *
On Wed, 10 Jan 2024 11:27:53 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> equals, hashCode, and compareTo for BigInteger. If you have any performance
>> concerns, please raise them.
>>
>> This PR is cherry-picked from a bigger,
On Wed, 10 Jan 2024 14:29:37 GMT, Jorn Vernee wrote:
>> The choice here is: if we allow non-zeroing implementation, implementors of
>> Arena have more flexibility, but clients have less guarantees (how does a
>> client know if what they get back is zeroed?)
>
>> (how does a client know if what
On Wed, 10 Jan 2024 14:21:15 GMT, Maurizio Cimadamore
wrote:
> (how does a client know if what they get back is zeroed?)
It seems similar to e.g. a HashMap vs. LinkedHashMap with regards to ordering.
The creator of the Arena would decide the zeroing strategy.
-
PR Review
On Wed, 10 Jan 2024 14:12:02 GMT, Jorn Vernee wrote:
>> This PR proposes to add a clarification that an `Arena` always returns
>> zeroed-out segments for `Arena::allocate` methods.
>>
>> Note that other overloaded methods refer to the abstract `Arena::allocate`
>> method via implementation
On Wed, 10 Jan 2024 14:19:29 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/java/lang/foreign/Arena.java line 269:
>>
>>> 267: * @implSpec
>>> 268: * Implementations of this method must return a native,
>>> zero-initialized segment
>>> 269: * featuring the
On Mon, 8 Jan 2024 16:16:50 GMT, Per Minborg wrote:
> This PR proposes to add a clarification that an `Arena` always returns
> zeroed-out segments for `Arena::allocate` methods.
>
> Note that other overloaded methods refer to the abstract `Arena::allocate`
> method via implementation notes.
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte
On Tue, 9 Jan 2024 18:31:49 GMT, Daniel Fuchs wrote:
>> Yes, that's perhaps clearer, will do.
>
> Typically in other places in the JDK we use `priviledgedXxx` for naming
> methods that are simple wrappers that call `xxx` from within a
> `doPrivileged`. The method is called privileged because
Hi David!
Apologies for the late reply, there's been lots of catching up to do after the
holidays.
>I'm really excited for what this will enable for us.
I'm really glad to hear that
>It is very much appreciated.
> Could we add one more method for a conditionalWindowFixed? We would need
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
Thanks for the reviews!
-
PR Comment:
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
This pull request has now been integrated.
Changeset: ec385057
Author:Stefan
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandates that the data descriptor `SHOULD be stored in
> ZIP64 format (as 8 byte
On Tue, 9 Jan 2024 13:06:56 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP format mandates that the data
On Tue, 9 Jan 2024 14:18:37 GMT, Jorn Vernee wrote:
> The issue with this test, and the test of JDK-8322324, seems to be that the
> forked processes write to stderr/stdout, without this output being read
> before the process terminates. The buffer might fill up if the output is not
> being
On Wed, 10 Jan 2024 12:44:25 GMT, Viktor Klang wrote:
>> Hello Viktor, the skara bot very helpfully has noted that this test has been
>> problemlisted in a couple of files:
>>
>>> 8309218 is used in problem lists: [test/jdk/ProblemList-zgc.txt,
>>> test/jdk/ProblemList-generational-zgc.txt]
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
lgtm.
-
Marked as reviewed by tschatzl (Reviewer).
PR Review:
On Tue, 9 Jan 2024 04:15:38 GMT, Jaikiran Pai wrote:
>> As per conversation in the issue.
>
> Hello Viktor, the skara bot very helpfully has noted that this test has been
> problemlisted in a couple of files:
>
>> 8309218 is used in problem lists: [test/jdk/ProblemList-zgc.txt,
>>
> From: "Remi Forax"
> To: "David Alayachew"
> Cc: "core-libs-dev"
> Sent: Wednesday, January 10, 2024 8:19:15 AM
> Subject: Re: Gatherers -- conditionalWindowFixed?
> Hello David,
> testing the gatherer api, I also wanted a "window" operation as the one you
> are
> describing.
> My use
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
Marked as reviewed by shade (Reviewer).
-
PR Review:
TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups file
still has a reference to it. This causes problems in our CI pipeline.
-
Commit messages:
- Revert unrelated changes
- 8323508: Remove TestGCLockerWithShenandoah.java line from TEST.groups
Changes:
1 - 100 of 113 matches
Mail list logo
