On Tue, 23 Apr 2024 09:32:40 GMT, Jin Kwon wrote:
>> Fix typos within the `DatabaseMetaData.java`.
>
> Jin Kwon has updated the pull request incrementally with one additional
> commit since the last revision:
>
> [JDK-8330686] Update copyright year
Thank you for the update. The changes look
> Prevent blocking due to a carrier thread not being released when
> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8330748: Add vthread1.join() in test
On Tue, 23 Apr 2024 06:20:47 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correct ID in test @bug tag
>
> test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java line 78:
>
>> 7
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean isCompa
> 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:
> - `Refer
On Wed, 10 Apr 2024 20:16:50 GMT, Justin Lu wrote:
> Please review this PR which is a large spec reformatting for
> _java.text.NumberFormat_ and related subclasses, specifically DecimalFormat
> and CompactNumberFormat.
>
> The motivation for this change was the difficulty of readability for th
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>> all-or
On Tue, 23 Apr 2024 13:54:42 GMT, Evemose wrote:
>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
>> `java.util.List`
>>
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the
>> `List` interface by providing a more f
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when i
On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
>
On Mon, 15 Apr 2024 22:12:30 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
> This is an implementation of JEP JDK-8315129: Module Import Declarations
> (Preview). Please see the JEP for details:
> https://bugs.openjdk.org/browse/JDK-8315129
>
> It is mostly straightforward - the module imports are parsed, and then
> expanded to import-on-demand in `TypeEnter`.
> There
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>> all-or
On Tue, 23 Apr 2024 18:57:44 GMT, Sean Mullan wrote:
> A few other comments/questions:
>
> Does this need a CSR since you are adding new property files?
Not sure it does, but Joe will follow up with Joe Darcy
>
> Are there any tests to ensure the property files are working correctly?
There ar
On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Fri, 19 Apr 2024 21:55:09 GMT, Joe Wang wrote:
>> Add two sample configuration files:
>>
>> jaxp-strict.properties: used to set strict configuration, stricter than
>> jaxp.properties in previous versions such as JDK 22
>>
>> jaxp-compat.properties: used to regain compatibility from any
On Tue, 23 Apr 2024 18:21:42 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the i
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or imp
On Tue, 23 Apr 2024 18:21:30 GMT, Sonia Zaldana Calles
wrote:
> The JNI error message didn’t previously get reported before the regression
> was introduced, so I just wanted to make sure we were okay with this.
I think such errors have a very high potential to confuse the hell out of the
poor
On Fri, 19 Apr 2024 17:04:30 GMT, Mandy Chung wrote:
>> @lahodaj
>>
>>> I would suggest to take the test from 18753 though - doing a change like
>>> this without a test may lead to hard-to-find regressions in the future.
>>> (Note the current test should guard against both JDK-8329420 and
>>
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue linked above,
> [LauncherHelper#getMainType](https://github.com/open
On Mon, 22 Apr 2024 08:59:33 GMT, Claes Redestad wrote:
> @mlchung @asotona: Alan asked me to use the ClassFile API here. As it's only
> used in what's effectively a slow path it shouldn't be blocked by the startup
> investigations we're doing there, right?
I agree that this should not be bloc
On Tue, 23 Apr 2024 17:35:42 GMT, Jason Mehrens wrote:
>> A good question. The buf/count fields are protected so the subclass has
>> direct access to the bytes. So while it could Arrays.copy the bytes, it
>> doesn't help with a buggy subclass that is changing bytes without
>> synchronization.
On Tue, 23 Apr 2024 16:08:13 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>>
>>> 162: public void writeTo(OutputStream out) throws IOException {
>>> 163: if (Thread.currentThread().isVirtual()) {
>>> 164: out.write(t
On Tue, 23 Apr 2024 08:09:20 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/FileInputStream.java line 211:
>>
>>> 209: * @param name the name of the file
>>> 210: */
>>> 211: private void open(String name) throws FileNotFoundException {
>>
>> If method such as thi
On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman wrote:
> This change drops the adjustments to the virtual thread scheduler's target
> parallelism when virtual threads do file operations on files that are opened
> for buffered I/O. These operations are usually just too short to have any
> benefit
On Tue, 23 Apr 2024 11:16:01 GMT, Jason Mehrens wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Correct ID in test @bug tag
>
> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>
>> 162
On Tue, 23 Apr 2024 13:13:03 GMT, Per Minborg wrote:
> Do we need additional tests or are these modifications already covered by the
> existing tests?
Thanks for the note, upon review it seems the default method overrides aren't
covered by existing Collection tests. I should add them to ensure
On Tue, 23 Apr 2024 12:49:15 GMT, Jaikiran Pai wrote:
>> Archie Cobbs 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 10 additional
>> commits s
On Tue, 23 Apr 2024 14:25:22 GMT, Magnus Ihse Bursie wrote:
> There's a huge amount of changes for just hsdis... You might have to separate
> out the infrastructure changes that seem to amount to most of the changes
> here.
>
> This is going to take me a while to get through.
Sorry, it's stil
> 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
commit since the last revision:
adjust output
-
Chang
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, 23 Apr 2024 13:56:32 GMT, Julian Waters wrote:
> WIP
>
> This changeset contains hsdis for Windows/gcc Port. It supports both the
> binutils and capstone backends, though the LLVM backend is left out due to
> compatibility issues encountered during the build. Currently, which gcc
> di
On Mon, 22 Apr 2024 11:57:19 GMT, Alan Bateman wrote:
>> Hi, any additional comments / reviews ?
>> Thanks Matthias
>
>> Hi, any additional comments / reviews ? Thanks Matthias
>
> It still looks like left over trace messages from a debugging session, need
> to think about about what tracing ma
WIP
This changeset contains hsdis for Windows/gcc Port. It supports both the
binutils and capstone backends, though the LLVM backend is left out due to
compatibility issues encountered during the build. Currently, which gcc
distributions are supported is still to be clarified, as several, rangi
On Sat, 20 Apr 2024 23:11:48 GMT, Chen Liang wrote:
>> Evemose has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Added Objects import to sun List
>> - Replaced on-demand import in com.sunList
>> - added non-null assertions
>
> sr
On Tue, 23 Apr 2024 13:51:54 GMT, Evemose wrote:
>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
>> `java.util.List`
>>
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the
>> `List` interface by providing a more f
On Fri, 19 Apr 2024 22:27:15 GMT, xxDark wrote:
>>> I noticed that most (if not all) methods don't ensure non-nullability of
>>> `filter` so NPE would only be thrown if the list is not empty.
>>
>> Yeah, thats true. not sure if it has to throw NPE even if list is emply
>
>> > I noticed that mos
On Fri, 19 Apr 2024 12:10:34 GMT, Chen Liang wrote:
>> @minborg Sorry to bother you with this kind of question, but i cant manage
>> to find where exactly and how I can file CSR review request. Could you help
>> me out?
>
> @Evemose Please revert formatting changes in existing classes. Unfortun
On Fri, 19 Apr 2024 15:49:11 GMT, Evemose wrote:
>> **Subject**
>> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
>> `java.util.List`
>>
>> **Motivation**
>> The motivation behind this proposal is to enhance the functionality of the
>> `List` interface by providing a more f
On Fri, 19 Apr 2024 22:20:48 GMT, Evemose wrote:
> > I noticed that most (if not all) methods don't ensure non-nullability of
> > `filter` so NPE would only be thrown if the list is not empty.
>
> Yeah, thats true. not sure if it has to throw NPE even if list is emply
Yes, it does. If it shoul
On Fri, 19 Apr 2024 21:36:42 GMT, xxDark wrote:
> I noticed that most (if not all) methods don't ensure non-nullability of
> `filter` so NPE would only be thrown if the list is not empty.
Yeah, thats true. not sure if it has to throw NPE even if list is emply
-
PR Comment: https:/
> **Subject**
> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to
> `java.util.List`
>
> **Motivation**
> The motivation behind this proposal is to enhance the functionality of the
> `List` interface by providing a more flexible way to find the index of an
> element. Currently,
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 Thu, 21 Mar 2024 18:01:38 GMT, Chen Liang wrote:
>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>>
>> The default implementations for multiple-element immutable collect
Hello there! As I see, your approach finds all matching indexes, not
just first. This would be much more suitable using enumerated streams.
Discussion about them has been moved to another thread (see
EnumeratedStream subject in mails).
Few messages above I provided benchmarks indicating that for
ClassFile API `StackMapGenerator` attaches print or hex dump of the method to
an error message.
However there is no such attachment when the stack maps generation is turned
off.
This patch moves class print/dump to `impl.Util::dumpMethod`, so it is shared
by `StackMapGenerator` and `StackCount
On Thu, 21 Mar 2024 18:01:38 GMT, Chen Liang wrote:
>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>>
>> The default implementations for multiple-element immutable collect
Sadly, there is no way to define a short-circuiting collector :(
That was my first course of exploration for JEP-461, and unfortunately I found
no great way of retrofitting that behavior, especially not in a
backwards-compatibility-safe way.
You can have a short-circuiting Gatherer like this
On Sun, 17 Mar 2024 22:53:55 GMT, Archie Cobbs wrote:
>> `GZIPInputStream`, when looking for a concatenated stream, relies on what
>> the underlying `InputStream` says is how many bytes are `available()`. But
>> this is inappropriate because `InputStream.available()` is just an estimate
>> and
Du to a glibc security alert about a charset in iconv() I checked OpenJDK
(since I was quite sure encoding is handled in JCL), however there are a few
utilities (related to libinstrument and splash Screens) which use iconv.
If I see it correctly it’s mostly used for utf8 so it should not expose
This patch adds missing `@throws` javadoc annotations to
`java.lang.classfile.BufWriter`.
Please review.
Thank you,
Adam
-
Commit messages:
- 8322847: java.lang.classfile.BufWriter should specify @throws for its
writeXXX methods
Changes: https://git.openjdk.org/jdk/pull/18913/fi
On Mon, 22 Apr 2024 17:19:14 GMT, Magnus Ihse Bursie wrote:
> But that sounds like a very special case.
Not sure if it is really such a special case. Currently both modes (getting
the image path from launcher binary path , and getting the image path from 'the
dll' / GetApplicationHomeFromDll
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since t
On Tue, 23 Apr 2024 07:27:02 GMT, Alan Bateman wrote:
> > Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?)
> > been explored/benchmarked?
>
> Yes, decided not to do because it's just guarding access to a byte[] and any
> changes can influence the inlining. Plus, it would
On Sat, 20 Apr 2024 04:35:05 GMT, Jaikiran Pai wrote:
>> @openjdk with issue from where?
>
> Hello @onacit, it appears a JBS issue has been filed for this
> https://bugs.openjdk.org/browse/JDK-8330686. Please change the title of this
> PR to `8330686: Fix typos in the DatabaseMetaData javadoc`
> Fix typos within the `DatabaseMetaData.java`.
Jin Kwon has updated the pull request incrementally with one additional commit
since the last revision:
[JDK-8330686] Update copyright year
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18860/files
- new: https://git.openjd
On Tue, 23 Apr 2024 08:04:54 GMT, Viktor Klang wrote:
>> Alan Bateman 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 five additional
>> commits
On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>> be
On Mon, 22 Apr 2024 10:34:29 GMT, Claes Redestad wrote:
> This switch expression in `Locale::createLocale` is causing a somewhat large
> startup regression on my local system. Desugaring to if statements seem like
> the right thing to do while we investigate ways to further reduce overheads
>
On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad wrote:
>> This switch expression in `Locale::createLocale` is causing a somewhat large
>> startup regression on my local system. Desugaring to if statements seem like
>> the right thing to do while we investigate ways to further reduce overheads
In the hashN usages of readCen from zip_util.c we see a lot of signed integer
overflows.
For example in the java/util jtreg tests those are easily reproducable when
compiling with -ftrapv (clang/gcc toolchains).
While those overflows never seem to cause crashes or similar errors, they are
unwant
ClassFile API dives into the nested constant pool entries without type
restrictions, while parsing a class file. Validation of the entry is performed
post-parsing. Specifically corrupted constant pool entry may cause infinite
loop during parsing and throws SOE.
This patch resolves the issue by p
On Fri, 19 Apr 2024 11:33:48 GMT, Jin Kwon wrote:
> Fix typos within the `DatabaseMetaData.java`.
These typo fixes look fine to me. Please update the copyright year on the file
from `1996, 2022,` to `1996, 2024,`
-
PR Review: https://git.openjdk.org/jdk/pull/18860#pullrequestrevie
On Tue, 23 Apr 2024 07:11:34 GMT, Viktor Klang wrote:
> Has the alternative of moving to a j.u.c.Lock (Needs Reentrant or not?) been
> explored/benchmarked?
Yes, decided not to do because it's just guarding access to a byte[] and any
changes can influence the inlining. Plus, it would need to c
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since t
On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman wrote:
>> This change drops the adjustments to the virtual thread scheduler's target
>> parallelism when virtual threads do file operations on files that are opened
>> for buffered I/O. These operations are usually just too short to have any
>> be
On Wed, 17 Apr 2024 05:43:12 GMT, Joe Darcy wrote:
>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Correct release date as observed in review feedback.
> - Improve javadoc of class file update.
LGTM
69 matches
Mail list logo
