> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
Axel Boldt-Christmas has updated the pull request with a new target base due to
a merge or a rebase. The pull request n
On Fri, 18 Oct 2024 02:03:21 GMT, Jatin Bhateja wrote:
>> This patch optimizes LongVector multiplication by inferring VPMULUDQ
>> instruction for following IR pallets.
>>
>>
>>MulL ( And SRC1, 0x) ( And SRC2, 0x)
>>MulL (URShift SRC1 , 32) (URShift
On Fri, 18 Oct 2024 06:10:54 GMT, Jatin Bhateja wrote:
>> @iwanowww IMO there are 2 ways to view this:
>>
>> - You can see a `MulVL` nodes with `_mult_lower_double_word` being an
>> entirely different kind of nodes which do a different thing (a.k.a throw
>> away the upper bits and only multipl
On Fri, 18 Oct 2024 05:35:27 GMT, Quan Anh Mai wrote:
>>> The issue is that a node is not immutable.
>>
>> I don't see any issues with mutability here.
>> `MulVLNode::_mult_lower_double_word` is constant, so you have to allocate
>> new node if you want to change its value. (And that's exactly
On Fri, 18 Oct 2024 05:16:04 GMT, Vladimir Ivanov wrote:
>>> I see this is as a twostep optimization, in the first step we do analysis
>>> and annotate additional information on existing IR, which is later used by
>>> instruction selector. I plan to subsume first stage with enhanced dataflow
>
On Fri, 18 Oct 2024 05:35:27 GMT, Quan Anh Mai wrote:
>>> The issue is that a node is not immutable.
>>
>> I don't see any issues with mutability here.
>> `MulVLNode::_mult_lower_double_word` is constant, so you have to allocate
>> new node if you want to change its value. (And that's exactly
On Fri, 18 Oct 2024 05:39:08 GMT, Quan Anh Mai wrote:
>> `vpmuludq` does a long multiplication but throws away the upper bits of the
>> operands, effectively does a `(x & max_juint) * (y & max_juint)`
>
> You can see its pseudocode here https://www.felixcloutier.com/x86/pmuludq
>
> VPMULUDQ
On Fri, 18 Oct 2024 05:46:25 GMT, Vladimir Ivanov wrote:
>> You can see its pseudocode here https://www.felixcloutier.com/x86/pmuludq
>>
>> VPMULUDQ (VEX.256 Encoded Version)[
>> ¶](https://www.felixcloutier.com/x86/pmuludq#vpmuludq--vex-256-encoded-version-)
>> DEST[63:0] := SRC1[31:0]
On Fri, 18 Oct 2024 05:35:28 GMT, Vladimir Ivanov wrote:
>> Jatin Bhateja has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - Review resolutions
>> - 8341137: Optimize long vector multiplication using x86 VPMULU
On Fri, 18 Oct 2024 04:09:00 GMT, Ioi Lam wrote:
>> src/hotspot/share/cds/metaspaceShared.cpp line 873:
>>
>>> 871: Symbol* method_sig = vmSymbols::void_method_signature();
>>> 872: JavaCalls::call_static(&result, vmClasses::Class_klass(),
>>> 873: method
On Fri, 18 Oct 2024 05:37:16 GMT, Quan Anh Mai wrote:
>> src/hotspot/share/opto/vectornode.cpp line 2122:
>>
>>> 2120: // MulL (URShift SRC1 , 32) (URShift SRC2, 32)
>>> 2121: // MulL (URShift SRC1 , 32) ( And SRC2, 0x)
>>> 2122: // MulL ( And SRC1, 0x) (URShift
On Fri, 18 Oct 2024 05:16:04 GMT, Vladimir Ivanov wrote:
>>> I see this is as a twostep optimization, in the first step we do analysis
>>> and annotate additional information on existing IR, which is later used by
>>> instruction selector. I plan to subsume first stage with enhanced dataflow
>
On Fri, 18 Oct 2024 05:05:16 GMT, Quan Anh Mai wrote:
> The issue is that a node is not immutable.
I don't see any issues with mutability here.
`MulVLNode::_mult_lower_double_word` is constant, so you have to allocate new
node if you want to change its value. (And that's exactly what
`MulVLNo
On Fri, 18 Oct 2024 04:16:15 GMT, Jatin Bhateja wrote:
> I see this is as a twostep optimization, in the first step we do analysis and
> annotate additional information on existing IR, which is later used by
> instruction selector. I plan to subsume first stage with enhanced dataflow
> analysi
On Fri, 18 Oct 2024 04:16:15 GMT, Jatin Bhateja wrote:
> It convolutes the graph with machine-dependent nodes early in the compiling
> process.
Ah, I see your point now! I took a closer look at the patch and indeed
`MulVLNode::_mult_lower_double_word` with `MulVLNode::Ideal()` don't look
pret
On Wed, 16 Oct 2024 01:26:41 GMT, Ioi Lam wrote:
>> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 235:
>>
>>> 233: }
>>> 234:
>>> 235: // TODO -- is this really correct? Do we need a special
>>> ClassLoaderData for each hidden class?
>>
>> There are multiple kinds of hidden classes:
On Tue, 15 Oct 2024 15:19:36 GMT, Dan Heidinga wrote:
>> Ioi Lam has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 29 commits:
>>
>> - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init
>> NCPU to runtime val
On Fri, 18 Oct 2024 02:41:47 GMT, Quan Anh Mai wrote:
> The issues I have with this patch are that:
>
> * It convolutes the graph with machine-dependent nodes early in the compiling
> process.
MulVL is a machine independent IR, we create a machine dependent IR post
matching.
> * It overloads
On Fri, 18 Oct 2024 04:08:37 GMT, Ioi Lam wrote:
>> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> This PR implements the AOT-linking of invokedynamic callsites:
>> - We only link lambda expressions (`Lamb
On Tue, 15 Oct 2024 17:03:40 GMT, Dan Heidinga wrote:
>> Ioi Lam has updated the pull request with a new target base due to a merge
>> or a rebase. The pull request now contains 29 commits:
>>
>> - @DanHeidinga comments -- added ConcurrentHashMap::runtimeSetup() to init
>> NCPU to runtime val
> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMetafactory::metafactory`) and
> string concat (`Stri
On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung wrote:
>> The old core reflection implementation generates dynamic classes that are
>> special cases in the VM to bypass bytecode verification to workaround
>> various issues [1] [2] [3].
>>
>> The old core reflection implementation was [removed in
I very much like this. I didn't even know about the SequenceInputStream
until a few days ago, so this would have way more visibility. And then it
could just delegate to SequenceInputStream under the hood. I like it a lot.
It looks like Jaikiran gave me a task to go search up other libraries and
se
On Fri, 18 Oct 2024 02:03:21 GMT, Jatin Bhateja wrote:
>> This patch optimizes LongVector multiplication by inferring VPMULUDQ
>> instruction for following IR pallets.
>>
>>
>>MulL ( And SRC1, 0x) ( And SRC2, 0x)
>>MulL (URShift SRC1 , 32) (URShift
On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung wrote:
>> The old core reflection implementation generates dynamic classes that are
>> special cases in the VM to bypass bytecode verification to workaround
>> various issues [1] [2] [3].
>>
>> The old core reflection implementation was [removed in
On Thu, 17 Oct 2024 21:53:16 GMT, Vladimir Ivanov wrote:
> > > MulVL (VectorCastI2X src1) (VectorCastI2X src2)
>
> > It looks unsafe to me, since VectorCastI2L sign-extends integer lanes, ...
>
> Hm, I don't see any problems with it if `VPMULDQ` is used. Sign extension
> becomes redundant when
On Thu, 17 Oct 2024 08:36:53 GMT, John R Rose wrote:
> I read through it fairly thoroughly. I made a lot of suggestions. Rather than
> edit comments into lots of spots in this PR, I made the following patch file.
> [aot-indy-21143-commentary.diff.txt](https://github.com/user-attachments/files/1
> This patch optimizes LongVector multiplication by inferring VPMULUDQ
> instruction for following IR pallets.
>
>
>MulL ( And SRC1, 0x) ( And SRC2, 0x)
>MulL (URShift SRC1 , 32) (URShift SRC2, 32)
>MulL (URShift SRC1 , 32) ( And SRC2, 0x
> ReferenceClassDescImpl caches internalName to avoid creating a new String
> object for each call, which can also simplify the implementation of classfile.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated c
On Mon, 7 Oct 2024 04:23:20 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to deprecate for
> removal the `jrunscript` tool?
>
> The `jrunscript` tool as documented in its specification
> https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunscript.
On Wed, 9 Oct 2024 07:00:21 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to deprecate for
>> removal the `jrunscript` tool?
>>
>> The `jrunscript` tool as documented in its specification
>> https://docs.oracle.com/en/java/javase/23/docs/specs/man/jrunsc
On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai wrote:
> Can I please get a review for this patch which proposes to implement the
> enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>
> Edit: This PR description has now been updated to match the changes that were
>
> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
> frames hiding mechanism.
> Please, see a fix description in the first comment.
>
> Testing:
> - Verified with new test `vthread/CheckHiddenFrames`
> - Mach5 tiers 1-6 are passed
Serguei Spitsyn has updated the pull re
On Thu, 17 Oct 2024 04:51:53 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this patch which proposes to implement the
>> enhancement request noted in
>> https://bugs.openjdk.java.net/browse/JDK-8173970?
>>
>> Edit: This PR description has now been updated to match the changes that
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote:
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will include the module
On Thu, 17 Oct 2024 06:09:42 GMT, Alan Bateman wrote:
> The JDK supports sym links on Windows and adding support for other unusual
> junctions types has the potential to introduce inconsistencies and weirdness
> that are outside the scope of the APIs.
There appear to be two types of junctions
On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung wrote:
>> The old core reflection implementation generates dynamic classes that are
>> special cases in the VM to bypass bytecode verification to workaround
>> various issues [1] [2] [3].
>>
>> The old core reflection implementation was [removed in
On Thu, 17 Oct 2024 18:23:12 GMT, Jatin Bhateja wrote:
> I have restricted the IR validation to just newly added UMin/UMax
> transformations.
Even then i think it better to do so in follow on PR, otherwise it is a moving
target for review and testing. This new test fails on aarch64 e.g.,
STA
On Thu, 17 Oct 2024 15:19:52 GMT, fabioromano1 wrote:
>> Will approve at the beginning of next week to let you add some last minute
>> (not substantial) changes during the next few days.
>
>> In any reduction approach, you still need to prove that the reduced problem
>> is equivalent to the ori
On Wed, 16 Oct 2024 00:03:25 GMT, Ioi Lam wrote:
>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading &
>> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>>
>> The implementation of java.lang.invoke uses SoftReferences so that unused
>> MethodHandles, LambdaForms, etc, can b
On Thu, 17 Oct 2024 11:17:43 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8233451: Remove use of handleAvailable() (Windows)
>> - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/
On Thu, 17 Oct 2024 11:14:17 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8233451: Remove use of handleAvailable() (Windows)
>> - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/
> Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces
> to native code and use these in `ChannelInputStream` to work around cases
> where a wrapped `FileChannelImpl` is not really seekable.
Brian Burkhalter has updated the pull request incrementally with two additional
On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung wrote:
> The old core reflection implementation generates dynamic classes that are
> special cases in the VM to bypass bytecode verification to workaround various
> issues [1] [2] [3].
>
> The old core reflection implementation was [removed in JDK
On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani wrote:
> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing
> Overhead & Inefficient Parallel Processing
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/21566
On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani wrote:
> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing
> Overhead & Inefficient Parallel Processing
> [xxDark](/xxDark)
Quite an allegation. Well, I initially wrote it for IntStraem and as I
mentioned the performance ch
> The old core reflection implementation generates dynamic classes that are
> special cases in the VM to bypass bytecode verification to workaround various
> issues [1] [2] [3].
>
> The old core reflection implementation was [removed in JDK
> 22](https://bugs.openjdk.org/browse/JDK-8305104).
On Tue, 15 Oct 2024 17:26:49 GMT, Quan Anh Mai wrote:
>> I'm pretty ambivalent, I think implementing it either way would be alright.
>> Especially with unit tests, I think the lowering implementation wouldn't be
>> that difficult. Maybe another reviewer has an opinion?
>>
>> About PhaseLowerin
On Thu, 17 Oct 2024 08:40:05 GMT, Eirik Bjørsnøs wrote:
>> I guess performance leans on there being only one or a small number of
>> versions per entry. Which I think is a fair assumption. Still would be good
>> to have a stress test with many entries having many versions and make sure
>> we d
On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato wrote:
>> Removing the old compatibility behavior switch for JDK1.1. With the
>> integration of tzdata2024b, definitions of those three (deprecated) IDs
>> changed again, so maintaining the JDK11 compatibility got less useful.
>> Removing the compat
On Thu, 17 Oct 2024 11:20:59 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8233451: Remove use of handleAvailable() (Windows)
>> - 8233451: Remove use of handleAvailable() (UNIX)
>
> src/
On Thu, 17 Oct 2024 20:45:53 GMT, Mandy Chung wrote:
> The old core reflection implementation generates dynamic classes that are
> special cases in the VM to bypass bytecode verification to workaround various
> issues [1] [2] [3].
>
> The old core reflection implementation was [removed in JDK
On Thu, 17 Oct 2024 19:40:52 GMT, Jatin Bhateja wrote:
>> MulVL (VectorCastI2X src1) (VectorCastI2X src2)
> It looks unsafe to me, since VectorCastI2L sign-extends integer lanes, ...
Hm, I don't see any problems with it if `VPMULDQ` is used. Sign extension
becomes redundant when 64-bit multipl
On Thu, 17 Oct 2024 18:13:45 GMT, Kevin Rushforth wrote:
>> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
>> with JavaFX instead.
>>
>> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
>> openjdk/jfx#1529 for the JavaFX PR that will include the mo
On Thu, 17 Oct 2024 20:11:16 GMT, Justin Lu wrote:
>> Please review this PR which specifies the _j.text.MessageFormat_
>> ArgumentIndex limit. A corresponding CSR is drafted.
>>
>> Both the existence of the limit (and behavior if violated), as well as this
>> implementation's limit are added t
The old core reflection implementation generates dynamic classes that are
special cases in the VM to bypass bytecode verification to workaround various
issues [1] [2] [3] uncovered over time.
The old core reflection implementation was [removed in JDK
22](https://bugs.openjdk.org/browse/JDK-8305
On Wed, 25 Sep 2024 12:58:20 GMT, David M. Lloyd wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It wa
On Sat, 12 Oct 2024 07:47:56 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized impleme
On Thu, 17 Oct 2024 20:11:16 GMT, Justin Lu wrote:
>> Please review this PR which specifies the _j.text.MessageFormat_
>> ArgumentIndex limit. A corresponding CSR is drafted.
>>
>> Both the existence of the limit (and behavior if violated), as well as this
>> implementation's limit are added t
On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani wrote:
> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing
> Overhead & Inefficient Parallel Processing
This seems like an AI-generated change... Also, turning a stream into a
parallel one is a recipe for disaster.
Consider
> Changing the charset initialization of `java.io.Console` class, which is the
> basis of `java.io.IO`, so that it would behave the same way as `System.out`
> wrt encoding. This change will also have the capability to override the
> default charset used in `IO` methods with `stdout.encoding` sys
Please review this PR which improves the readObject logic for
_j.text.MessageFormat_.
No offset should be larger than the pattern length. We already ensure the
offsets when consumed backwards are equal/descending. The existing
first/initial check was off by 1 since it was checking against the p
> Please review this PR which specifies the _j.text.MessageFormat_
> ArgumentIndex limit. A corresponding CSR is drafted.
>
> Both the existence of the limit (and behavior if violated), as well as this
> implementation's limit are added to the class description. See the JBS issue
> comments for
Changing the charset initialization of `java.io.Console` class, which is the
basis of `java.io.IO`, so that it would behave the same way as `System.out` wrt
encoding. This change will also have the capability to override the default
charset used in `IO` methods with `stdout.encoding` system prop
On Thu, 17 Oct 2024 16:12:45 GMT, Justin Lu wrote:
>> Please review this PR which specifies the _j.text.MessageFormat_
>> ArgumentIndex limit. A corresponding CSR is drafted.
>>
>> Both the existence of the limit (and behavior if violated), as well as this
>> implementation's limit are added t
On Mon, 14 Oct 2024 21:26:41 GMT, Jasmine Karthikeyan
wrote:
>> Jatin Bhateja has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>> - 834
On Tue, 15 Oct 2024 00:28:25 GMT, Vladimir Ivanov wrote:
> MulVL (VectorCastI2X src1) (VectorCastI2X src2
It looks unsafe to me, since VectorCastI2L sign-extends integer lanes, thus we
may not be able to neglect partial products of upper doublewords while
performing 64x64 bit multiplication. E
> This patch optimizes LongVector multiplication by inferring VPMULUDQ
> instruction for following IR pallets.
>
>
>MulL ( And SRC1, 0x) ( And SRC2, 0x)
>MulL (URShift SRC1 , 32) (URShift SRC2, 32)
>MulL (URShift SRC1 , 32) ( And SRC2, 0x
On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani wrote:
> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing
> Overhead & Inefficient Parallel Processing
Thank you for your detailed feedback and the opportunity to clarify the
proposed changes.
The issue raised was not abou
On Thu, 17 Oct 2024 18:45:01 GMT, Eirik Bjørsnøs wrote:
> But that's my subjective opinion, it's understandable and fine that others
> see it differently.
Again, I understand your suggestion and will give it some additional thought.
The original intent was to address the incorrect max value t
On Thu, 17 Oct 2024 16:21:29 GMT, wasif kirmani wrote:
> [JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing
> Overhead & Inefficient Parallel Processing
@kirmaniwasif Hi!
First of all, thanks for wanting to help out!
After reviewing the proposed changes I have some commen
On Thu, 17 Oct 2024 13:56:50 GMT, Lance Andersen wrote:
> I had thought about that and decided to keep the changes as they are. I am
> not opposed to revisiting this in a follow on PR. Any additional changes
> would require more javadoc updates to address the overall change in
> validation.
>
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> for following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB
[JDK-8342513](https://bugs.openjdk.org/browse/JDK-8342513) : Autoboxing
Overhead & Inefficient Parallel Processing
-
Commit messages:
- 8342513 : Fixed autoboxing and aprallel processing for big dataset
Changes: https://git.openjdk.org/jdk/pull/21566/files
Webrev: https://webrevs
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> for following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB
On Thu, 17 Oct 2024 16:17:02 GMT, Sandhya Viswanathan
wrote:
> > > Rather than adding more IR test functionality to this PR that requires
> > > additional review my recommendation would be to follow up in another PR
> > > or before hand rethink our approach.
> >
> >
> > Agree, I am thinking
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX.
> That PR describes the needed test scenarios
On Thu, 17 Oct 2024 17:44:10 GMT, Brian Burkhalter wrote:
> Either the problem reported in
> [JDK-8341666](https://bugs.openjdk.org/browse/JDK-8341666) will be addressed
> in the context of this PR, or that issue will be reopened and addressed by a
> subsequent PR.
@xxDark I reopened [JDK-834
On Thu, 17 Oct 2024 11:24:56 GMT, Weijun Wang wrote:
>> In general, I tried to remove any text from the Permission classes that
>> described behavior if the permissions were granted. So in the above I
>> removed the text because it had words like "protect" and "accessed" and
>> referred to `co
On Thu, 17 Oct 2024 03:37:30 GMT, xxDark wrote:
> I see that my [report](https://bugs.openjdk.org/browse/JDK-8341666) was
> closed as a duplicate of JDK-8233451 (the bug this PR fixes). This does not
> resolve the situation with `FileInputStream`?` java.io` will not be fixed?
You are correct.
On Wed, 16 Oct 2024 19:59:44 GMT, Naoto Sato wrote:
>> Removing the old compatibility behavior switch for JDK1.1. With the
>> integration of tzdata2024b, definitions of those three (deprecated) IDs
>> changed again, so maintaining the JDK11 compatibility got less useful.
>> Removing the compat
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> for following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB
On Thu, 17 Oct 2024 15:41:58 GMT, Jatin Bhateja wrote:
> > Rather than adding more IR test functionality to this PR that requires
> > additional review my recommendation would be to follow up in another PR or
> > before hand rethink our approach.
>
> Agree, I am thinking of developing an autom
> Please review this PR which specifies the _j.text.MessageFormat_
> ArgumentIndex limit. A corresponding CSR is drafted.
>
> Both the existence of the limit (and behavior if violated), as well as this
> implementation's limit are added to the class description. See the JBS issue
> comments for
On Tue, 15 Oct 2024 21:26:26 GMT, Alex Menkov wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Disallow NotifyFramePop for
>> enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jv
On Thu, 17 Oct 2024 09:16:31 GMT, Serguei Spitsyn wrote:
>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition
>> frames hiding mechanism.
>> Please, see a fix description in the first comment.
>>
>> Testing:
>> - Verified with new test `vthread/CheckHiddenFrames`
>> - M
On Wed, 16 Oct 2024 19:44:08 GMT, Paul Sandoz wrote:
> Rather than adding more IR test functionality to this PR that requires
> additional review my recommendation would be to follow up in another PR or
> before hand rethink our approach.
Agree, I am thinking of developing an automated IR vali
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> for following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB
On Thu, 17 Oct 2024 15:17:38 GMT, Raffaello Giulietti
wrote:
>> With the definition remainingZeros = scale - preferredScale, the proof above
>> could be adapted almost on the fly to the old implementation.
>>
>> In any reduction approach, you still need to prove that the reduced problem
>> is
On Thu, 17 Oct 2024 15:12:32 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti That's correct, although I prefer that the correctness is proved
>> by "reducing the size of the problem" rather than "total number of removed
>> powers", because it was the logic to prove implicitly the correctness of
On Thu, 17 Oct 2024 14:51:28 GMT, fabioromano1 wrote:
>> OK, let me reformulate the reasoning to check that we are in sync.
>> For simplicity, I'm assuming that the powers of 2 are _not_ stripped away,
>> so I'm using powers of 10 rather than powers of 5. Adding the powers of 2
>> optimization
On Thu, 17 Oct 2024 14:29:36 GMT, Raffaello Giulietti
wrote:
>>> The comments are OK. However, there seems to be no explicit relation
>>> between the "running" vars used in the reasoning and the expected outcome.
>>>
>>> To clarify what I mean, let v0, z0 and s0 be the initial values at method
On Thu, 17 Oct 2024 12:59:37 GMT, fabioromano1 wrote:
>> The comments are OK. However, there seems to be no explicit relation between
>> the "running" vars used in the reasoning and the expected outcome.
>>
>> To clarify what I mean, let v0, z0 and s0 be the initial values at method
>> entry o
On Wed, 16 Oct 2024 22:48:58 GMT, Justin Lu wrote:
> Please review this PR which specifies the _j.text.MessageFormat_
> ArgumentIndex limit. A corresponding CSR is drafted.
>
> Both the existence of the limit (and behavior if violated), as well as this
> implementation's limit are added to the
On Thu, 17 Oct 2024 11:28:33 GMT, Eirik Bjørsnøs wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add back missing putNextEntry call
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 97:
>
>> 95:
On 17/10/2024 04:47, David Alayachew wrote:
Hello Core Libs Dev Team,
Currently, java.io.SequenceInputStream only has 2 constructors -- one
that takes in 2 instances of InputStream, and another that takes in an
Enumeration of type InputStream.
Would it make sense to add a third constructo
On Thu, 17 Oct 2024 11:41:05 GMT, Eirik Bjørsnøs wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add back missing putNextEntry call
>
> test/jdk/java/util/zip/ZipOutputStream/ZipOutputStreamMaxCenHdrTest.java lin
> Please review the changes for
> [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a
> follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which
> addresses that
>
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
>
> currently validat
On Thu, 17 Oct 2024 12:38:29 GMT, Raffaello Giulietti
wrote:
> The comments are OK. However, there seems to be no explicit relation between
> the "running" vars used in the reasoning and the expected outcome.
>
> To clarify what I mean, let v0, z0 and s0 be the initial values at method
> entr
On Tue, 15 Oct 2024 09:56:30 GMT, fabioromano1 wrote:
>> I would say yes... The invariant `i == max{n : 5^(2^n) <= 5^remainingZeros}`
>> should be a sufficient condition to affirm it, indeed the 2nd loop ends when
>> `remainingZeros == 0`, so `remainingZeros >= z` implies `z == 0`...
>
>> Yes,
1 - 100 of 122 matches
Mail list logo
