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
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
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
>
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:
>
>>
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
> 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
-
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
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
>
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
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
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
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
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.
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
>>
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.
> 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,
>
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
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
>>
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
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 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
>>
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
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
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
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:
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
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: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
> 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 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
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
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
> 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
> 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:
> -
> 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
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:
>
>>
> 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
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
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
>>
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 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
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
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 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
>>
> 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:
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`
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
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
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
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:
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:
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
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
>>
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
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
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
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
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
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
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
>
>
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
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
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.
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
> **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.
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:
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,
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
69 matches
Mail list logo
