On Wed, 22 May 2024 05:16:42 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change for addressing
> https://bugs.openjdk.org/browse/JDK-8332490?
>
> The jmh test opens a `InflaterInputStream`, reads the stream contents, but
> then doesn't close the stream. This can lead
On Tue, 21 May 2024 21:16:52 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java line 78:
>>
>>> 76: String line = null;
>>> 77: synchronized (writeLock) {
>>> 78: synchronized(readLock) {
>>
>> Suggestion:
>>
>> sy
Can I please get a review of this test-only change for addressing
https://bugs.openjdk.org/browse/JDK-8332490?
The jmh test opens a `InflaterInputStream`, reads the stream contents, but then
doesn't close the stream. This can lead to resource leak which can then cause
OOM as noted in that JBS i
On Tue, 21 May 2024 17:41:46 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
(Sorry about my previous "do I need to subscribe?" email; in retrospect that
was needless noise.)
The purpose of this email is twofold: first, inquire about the status of ticket
filed a few years ago, and second to point out some non-obvious reasons why it
might be slightly more serious than it
On Fri, 17 May 2024 23:47:45 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 21 May 2024 18:03:41 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressing lots of comments. Interim commit.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4648:
>
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
> This test intends to verify the behavior of JdkConsole for the java.base
> module, wrt restoring the echo. The test assumes the internal methods that
> sets/gets the echo status of the platform.
Naoto Sato has updated the pull request with a new target base due to a merge
or a rebase. The inc
Please review this test-only clean up PR which converts the java.util.Base64
tests to run under JUnit.
In general, this allows for the tests to run independently, separates the data
providers from the tests, as well being able to utilize the built in JUnit
utility test methods to reduce boilerp
On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one add
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Used a dedicate
On Fri, 17 May 2024 09:26:03 GMT, Alan Bateman wrote:
>> My main concern here is the addition of clutter (checking two flags, and
>> creating two levels of nested "impl" methods) at every call site. We may
>> need to rearrange our internal API for JFR (jdk.internal.events) in order to
>> clean
This message is for information purposes only. It is not a recommendation,
advice, offer or solicitation to buy or sell a product or service, nor an
official confirmation of any transaction. It is directed at persons who are
professionals and is intended for the recipient(s) only. It is not di
On Tue, 21 May 2024 19:55:22 GMT, Andrey Turbanov 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:
>>
>> - Add diagnostic output
>> - Use "expect" that was found
>> - Merge branch 'master' into
On Mon, 20 May 2024 17:24:22 GMT, Ioi Lam wrote:
>> JavacBench is a test program that compiles 90 Java source files. It uses a
>> fair amount of invokedynamic callsites, so it's good for testing CDS support
>> for indy and lambda expressions.
>>
>> This test was first integrated into the
>> [
On Mon, 20 May 2024 17:49:29 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request with a new target base due
> 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 more
>> restricted configuration than previous versions
On Tue, 21 May 2024 18:02:45 GMT, Vladimir Ivanov wrote:
> I can definitely name it differently (e.g, ensureTypeVisible), but making a
> separate class loading pass across signature classes doesn't make much sense.
Ok, in that case I suggest also renaming `MemberName::checkForTypeAlias`, maybe
On Tue, 21 May 2024 15:44:18 GMT, Pavel Rappo wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merg
On Fri, 17 May 2024 23:47:45 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
> `java.lang.invoke.Mem
On Tue, 21 May 2024 07:21:14 GMT, Tobias Hartmann wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> shenandoah verifier
>
> I'm getting some conflicts when trying to apply this to master. Could you
> please m
> Performance. Before:
>
> Benchmark(algorithm) (dataSize) (keyLength)
> (provider) Mode Cnt ScoreError Units
> SignatureBench.ECDSA.signSHA256withECDSA1024 256
> thrpt3 6443.934 ± 6.491 ops/s
> SignatureBench.ECDSA.
On Wed, 17 Apr 2024 17:12:28 GMT, Brent Christian wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Another update to reachabilityFence() @apiNote
>
> AFAICT, all review feedback on this change has been addressed.
On Tue, 21 May 2024 08:44:47 GMT, Maurizio Cimadamore
wrote:
> These are all good suggestions. I have not looked into jpackage, but yes, I
> would expect that the jpackage user would need to provide extra options when
> packaging the application.
It would be good to document how jpackage user
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Mon, 20 May 2024 17:24:22 GMT, Ioi Lam wrote:
>> JavacBench is a test program that compiles 90 Java source files. It uses a
>> fair amount of invokedynamic callsites, so it's good for testing CDS support
>> for indy and lambda expressions.
>>
>> This test was first integrated into the
>> [
On Fri, 17 May 2024 13:38:25 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and `Runtime::loa
On Tue, 21 May 2024 10:20:27 GMT, Maurizio Cimadamore
wrote:
>> When creating a nested memory access var handle, we ensure that the segment
>> is accessed at the correct alignment for the root layout being accessed. But
>> we do not ensure that the segment has at least the size of the accessed
> Please review this PR which introduces the `java.io.IO` top-level class and
> three methods to `java.io.Console` for [Implicitly Declared Classes and
> Instance Main Methods (Third Preview)].
>
> This PR has been obtained as `git merge --squash` of a now obsolete [draft
> PR].
>
> [Implicitl
On Mon, 20 May 2024 19:21:44 GMT, Paul Sandoz wrote:
>> Hi,
>> Can you help to review this simple patch?
>> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not
>> necessary, could be removed.
>> Thanks
>
> That does not look correct and will only check a prefix indexes. A
On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman wrote:
> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
> change. The type of the operation parameter of the callWhere method is
> changed to a new functional interface to avoid having the API throw
> Exception. With that
On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman wrote:
> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
> change. The type of the operation parameter of the callWhere method is
> changed to a new functional interface to avoid having the API throw
> Exception. With that
I propose to add type-checked ConstantPool.entryByIndex and
ClassReader.readEntryOrNull taking an extra Class parameter, which throws
ConstantPoolException instead of ClassCastException on type mismatch, which can
happen to malformed ClassFiles.
Requesting a review from @asotona. Thanks!
Propo
When building with ubsan enabled (--enable-uban) on Linux x86_64 and doing
jtreg tests afterwards I run into this error :
/jdk/src/java.base/unix/native/libjava/ProcessImpl_md.c:562:5: runtime error:
null pointer passed as argument 2, which is declared to never be null
#0 0x7fd95bec78d8 in s
On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs wrote:
> The issue reported a ClassCastException "cannot assign instance of
> java.util.CollSer to field of type java.util.Map"
> while deserializing an object referring to an immutable Map that contained a
> reference to a class that was not availab
On Fri, 17 May 2024 09:31:33 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable V
On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs and Species classes) on
>> a
On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti
wrote:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
This pull request has now been integrated.
Changeset: 42e3c842
On Fri, 17 May 2024 09:31:33 GMT, Per Minborg wrote:
>> # Stable Values & Collections (Internal)
>>
>> ## Summary
>> This PR proposes to introduce an internal _Stable Values & Collections_ API,
>> which provides immutable value holders where elements are initialized _at
>> most once_. Stable V
On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs and Species classes) on
>> a
On Wed, 17 Apr 2024 17:12:28 GMT, Brent Christian wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Another update to reachabilityFence() @apiNote
>
> AFAICT, all review feedback on this change has been addressed.
On Thu, 16 May 2024 21:36:03 GMT, Konstantin Nisht wrote:
>> @AlanBateman @DougLea Reviews are most welcome :)
>
> @viktorklang-ora We managed to reproduce it quite reliably by running the
> test from the bug report multiple times (in our case, it was 100). I
> understand this does not make a 1
On Tue, 21 May 2024 09:20:36 GMT, Adam Sotona wrote:
> j.l.classfile.ClassReader instance is exposed in the Class-File API through
> j.l.classfile.AttributeMapper::readAttribute method only.
> ClassReader only purpose is to serve as a tool for reading content of a
> custom attribute in a user-p
On Mon, 20 May 2024 20:56:18 GMT, Oussama Louati wrote:
>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code
>> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle,
>> MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process
> When creating a nested memory access var handle, we ensure that the segment
> is accessed at the correct alignment for the root layout being accessed. But
> we do not ensure that the segment has at least the size of the accessed root
> layout. Example:
>
>
> MemoryLayout LAYOUT = sequenceLay
On Mon, 20 May 2024 19:21:44 GMT, Paul Sandoz wrote:
>> Hi,
>> Can you help to review this simple patch?
>> Some index check in Byte/ShortVector.fromArray/fromArray0Template seems not
>> necessary, could be removed.
>> Thanks
>
> That does not look correct and will only check a prefix indexes. A
On Tue, 21 May 2024 09:06:16 GMT, Raffaello Giulietti
wrote:
>> All random number generator algorithms are implemented in module
>> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory`
>> is no longer needed.
>
> Raffaello Giulietti has updated the pull request increment
j.l.classfile.ClassReader instance is exposed in the Class-File API through
j.l.classfile.AttributeMapper::readAttribute method only.
ClassReader only purpose is to serve as a tool for reading content of a custom
attribute in a user-provided AttribtueMapper.
It contains useful set of low-level cl
On Tue, 21 May 2024 09:01:32 GMT, Claes Redestad wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs and Species classes) on
>> a
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Prefer 'l
> We can fold the call to `Objects.checkIndex` into the code generated in
> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
> This loads 9 less classes (of which 8 generated LFs and Species classes) on a
> minimal test, while being neutral on a throughput sanity test
On Tue, 21 May 2024 07:20:05 GMT, Alan Bateman wrote:
> > Have you looked into / thought about how this will work for jpackaged apps
> > ? I suspect that both the existing FFM usage and this will be options the
> > application packager will need to supply when building the jpackaged app -
> >
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
> `java.lang.invoke.Mem
> We can fold the call to `Objects.checkIndex` into the code generated in
> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
> This loads 9 less classes (of which 8 generated LFs and Species classes) on a
> minimal test, while being neutral on a throughput sanity test
On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman wrote:
> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
> change. The type of the operation parameter of the callWhere method is
> changed to a new functional interface to avoid having the API throw
> Exception. With that
On Wed, 8 May 2024 09:40:38 GMT, Alan Bateman wrote:
> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
> change. The type of the operation parameter of the callWhere method is
> changed to a new functional interface to avoid having the API throw
> Exception. With that
JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
change. The type of the operation parameter of the callWhere method is changed
to a new functional interface to avoid having the API throw Exception. With
that change, the getWhere (and the corresponding method on Carrier)
On Tue, 21 May 2024 00:16:51 GMT, Chen Liang wrote:
>> We can fold the call to `Objects.checkIndex` into the code generated in
>> generateTypeSwitchSkeleton instead of doing so by filtering the MH argument.
>> This loads 9 less classes (of which 8 generated LFs and Species classes) on
>> a min
On Fri, 30 Jun 2023 14:43:36 GMT, Chen Liang wrote:
> As discussed on the mailing list
> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-June/000381.html,
> BufWriter::asByteBuffer has a behavior not suitable for API and is only used
> by internal StackMapGenerator/StackCounter, so i
On Mon, 20 May 2024 08:37:49 GMT, Adam Sotona wrote:
> Parsing of a specifically corrupted class file cause unexpected
> `ArrayIndexOutOfBoundsException` during label inflation.
> This patch checks the valid range and throws expected
> `IllegalArgumentException` instead.
> Relevant test is adde
> This is the implementation changes for JEP 471.
>
> The methods in sun.misc.Unsafe for on-heap and off-heap access are deprecated
> for removal. This means a removal warning at compile time. No methods have
> been removed. A deprecated message is added to each of the methods but
> unlikely to
On Fri, 17 May 2024 21:16:47 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
On Mon, 20 May 2024 18:47:35 GMT, Phil Race wrote:
> Have you looked into / thought about how this will work for jpackaged apps ?
> I suspect that both the existing FFM usage and this will be options the
> application packager will need to supply when building the jpackaged app -
> the end use
On Fri, 17 May 2024 21:16:47 GMT, Volodymyr Paprotski wrote:
>> Performance. Before:
>>
>> Benchmark(algorithm) (dataSize) (keyLength)
>> (provider) Mode Cnt ScoreError Units
>> SignatureBench.ECDSA.signSHA256withECDSA1024 256
66 matches
Mail list logo
