On Mon, 7 Oct 2024 12:42:00 GMT, Prasadrao Koppula wrote:
>> Using SharedSecrets, I attempted to expose FileInputStream::path
>> information. After implementing the fix, I validated the startup performance
>> tests. Observed no consistent pattern of performance drops or gains, can
>> disregard
> Timezone data 2024b changes
Johny Jose has updated the pull request incrementally with one additional
commit since the last revision:
Review changes
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21265/files
- new: https://git.openjdk.org/jdk/pull/21265/files/6c4ce6f8..
On Mon, 7 Oct 2024 05:58: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, 7 Oct 2024 22:21:13 GMT, Mandy Chung wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Alan's suggestion - retain old text plus add a new deprecation note
>
> src/java.scripting/share/classes/module-info.java
> 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.html was
> an experimental and unsupported tool. Ever
On Wed, 25 Sep 2024 20:00:42 GMT, Chen Liang wrote:
>> This patch already has a CSR for trivial signature changes. The real
>> difficulty lies in how we should name our new array class descriptors,
>> `Object_array` or `ObjectArray` or what else?
>
> That said, can you leave a quick review on C
On Fri, 4 Oct 2024 18:08:53 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains nine commits:
>>
>> - class or interface descriptor renamed for clarity
>> - Merge branch 'master' of https://gith
On Tue, 8 Oct 2024 01:05:14 GMT, Shaojin Wen wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename get64 -> get64S
>
> src/java.base/share/classes/java/util/zip/ZipUtils.java line 173:
>
>> 171: * The byte
> @cl4es discovered that Stack Map generation in ClassFile API uses
> `componentType` and `arrayType` for `aaload` `aastore` instructions, which
> are currently quite slow. We can split out array class descriptors from class
> or interfaces to support faster `arrayType` and `componentType` opera
On Sun, 6 Oct 2024 21:45:08 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Mon, 7 Oct 2024 22:03:36 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`
> - Mach5 tie
On Fri, 4 Oct 2024 23:49:42 GMT, Shaojin Wen wrote:
> Use `slot & ~0xFF == 0` instead of `(slot & 0xFF) == slot` to reduce codeSize.
>
> The following is a comparison of the bytecode before and after the
> modification. It can be seen that using `slot & ~0xFF == 0` will reduce one
> iload oper
> Some DirectCodeBuilder related optimizations to improve startup and running
> performance:
> 1. Merge calls, merge writeU1 and writeU2 into writeU3
> 2. Merge calls, merge writeU1 and writeIndex operations
> 3. Directly use writeU1 instead of writeBytecode
> 4. Rewrite the implementation of load
On Mon, 7 Oct 2024 22:03:36 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`
> - Mach5 tie
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
-
Commit messages:
- fix one more place
On Mon, 7 Oct 2024 07:03:13 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 Mon, 7 Oct 2024 21:45:00 GMT, Henry Jen wrote:
>> This PR support a -k, --keep options like tar that allows jar to avoid
>> override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Adapt review suggestion
> This PR support a -k, --keep options like tar that allows jar to avoid
> override existing files.
Henry Jen has updated the pull request incrementally with one additional commit
since the last revision:
Adapt review suggestion
-
Changes:
- all: https://git.openjdk.org/jdk/pu
On Mon, 7 Oct 2024 20:03:29 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix merge error
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
> line 989:
>
>> 987:
> This PR moves the section on restricted methods from the the javadoc of
> `java.lang.foreign` package into a standalone static [javadoc
> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/java/lang/foreign/doc-files/RestrictedMethods.html).
>
> This is
On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
On Mon, 7 Oct 2024 15:48:46 GMT, Vladimir Kozelkov wrote:
> > Does this restacking make things clearer?
>
> I really like this new definition.
>
> To what extent do these rules determine the compatibility of FFM calling
> conventions with the C calling convention? If I understand correctly, al
On Sat, 5 Oct 2024 16:33:50 GMT, Shaojin Wen wrote:
>> Some DirectCodeBuilder related optimizations to improve startup and running
>> performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 inste
On Fri, 4 Oct 2024 23:49:42 GMT, Shaojin Wen wrote:
> Use `slot & ~0xFF == 0` instead of `(slot & 0xFF) == slot` to reduce codeSize.
>
> The following is a comparison of the bytecode before and after the
> modification. It can be seen that using `slot & ~0xFF == 0` will reduce one
> iload oper
On Mon, 7 Oct 2024 19:54:15 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which adds validation of the 'total entries' value
>> when fetched from the 'ZIP64 End of Central Directory' header.
>>
>> We should reject this value under the following conditions:
>>
>> 1. It is too large to fit
Please consider this PR which makes `ZipFileInflaterInputStream` release its
`Inflater` instance back to the pool when observing that the stream has been
fully consumed.
This is motivated by the following observations:
* After a `ZipFileInflaterInputStream` has reached the end of stream, its
`
On Mon, 7 Oct 2024 18:51:52 GMT, Lance Andersen wrote:
> It might be beneficial to future readers to provide the steps used to create
> the hex string in the format you have provided.
The test vector was crafted using a ZIP test library not available in OpenJDK.
I have replaced that with a tes
> Please review this PR which adds validation of the 'total entries' value when
> fetched from the 'ZIP64 End of Central Directory' header.
>
> We should reject this value under the following conditions:
>
> 1. It is too large to fit within the specified CEN size (considering each CEN
> header
On Fri, 4 Oct 2024 22:42:18 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti Though, it's also true that if I want to do astronomical
>> calculations, I probably have a machine that allows me to do so, and so I'd
>> like to be able to make the most of it...
>
> `BigDecimal` was not designed to d
On Mon, 7 Oct 2024 17:39:33 GMT, Markus KARG wrote:
>>> keep the reference to the char sequence "forever"
>>
>> Note that this only happens if the `Reader` instance is kept forever; but a
>> `Reader` is supposed to be used and closed and discarded instead of being
>> held indefinitely after cl
On Sat, 5 Oct 2024 16:33:50 GMT, Shaojin Wen wrote:
>> Some DirectCodeBuilder related optimizations to improve startup and running
>> performance:
>> 1. Merge calls, merge writeU1 and writeU2 into writeU3
>> 2. Merge calls, merge writeU1 and writeIndex operations
>> 3. Directly use writeU1 inste
On Sun, 6 Oct 2024 18:02:58 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which proposes to change the input buffer size of
> `ZipFileInflaterInputStream` to be based on the _compressed_ size of a ZIP
> entry instead of the _uncompressed_ size. This saves allocation since buffers
> will n
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Use log cache of BigInteger
-
Changes:
- all: https://git.openjdk.org/
On Sun, 6 Oct 2024 21:45:08 GMT, Claes Redestad wrote:
>> #14632 showed that coalescing loads in the `ZipUtils` utility methods could
>> improve performance in zip-related microbenchmarks, but doing so would
>> increase startup overheads. Progress was stalled as we backed out some
>> related e
On Mon, 7 Oct 2024 05:58: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, 7 Oct 2024 09:13:57 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which adds validation of the 'total entries' value when
> fetched from the 'ZIP64 End of Central Directory' header.
>
> We should reject this value under the following conditions:
>
> 1. It is too large to fit withi
On Wed, 28 Aug 2024 08:11:08 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests to deprecate the unused class
>> `java.util.zip.ZipError` for removal.
>>
>> The class has been unsed by OpenJDK since the ZIP API was rewritten from
>> native to Java in JDK 9.
>>
>> I opted to n
On Wed, 2 Oct 2024 00:25:00 GMT, Henry Jen wrote:
>> This PR support a -k, --keep options like tar that allows jar to avoid
>> override existing files.
>
> Henry Jen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> More review comments
Ove
On Mon, 7 Oct 2024 16:06:08 GMT, Chen Liang wrote:
>> This is correct, but then we would keep the reference to the char sequence
>> "forever", without any good reason. This content could be *huge* (and often
>> it is, as `CharSequence` most often is a `StringBuilder` just because the
>> applic
On Mon, 7 Oct 2024 17:07:47 GMT, Chen Liang wrote:
> Your example is an exact antipattern from our data-oriented model: we would
> want users to check the object type with `instanceof` (should be `is` in
> kotlin) instead of checking these constants.
I'm aware, this was just the first example
On Mon, 7 Oct 2024 16:45:28 GMT, Luca Kellermann wrote:
>> First, some bit of history. These API methods are added before those
>> constants, and this patch did not change the type of these methods or
>> constants.
>>
>> I believe the methods have restricted return types to be informative:
>>
ReferenceClassDescImpl caches internalName to avoid creating a new String
object for each call, which can also simplify the implementation of classfile.
-
Commit messages:
- suggestion from @liach
- stable
- ReferenceClassDescImpl cache internalName
Changes: https://git.openjdk.o
On Sun, 6 Oct 2024 01:22:33 GMT, Shaojin Wen wrote:
> ReferenceClassDescImpl caches internalName to avoid creating a new String
> object for each call, which can also simplify the implementation of classfile.
In many scenarios where classfile is used, ClassDesc is cached by statically
declarin
On Sun, 6 Oct 2024 01:22:33 GMT, Shaojin Wen wrote:
> ReferenceClassDescImpl caches internalName to avoid creating a new String
> object for each call, which can also simplify the implementation of classfile.
Changes requested by liach (Reviewer).
The caching of class entry forms in ReferenceC
On Wed, 2 Oct 2024 20:24:41 GMT, Chen Liang wrote:
> First, some bit of history. These API methods are added before those
> constants, and this patch did not change the type of these methods or
> constants.
Sure, makes sense to separate this patch from a potential type change of the
methods/c
JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out
of problem listing. Additionally I have increased logging so that it is easier
to debug when the issue happens again.
Testing:
tier1,tier2,tier3
tier6-comp,tier8-comp
-
Commit messages:
- initial commit
Hi all,
The test `java/util/PluggableLocale/DateFormatProviderTest.java` run timeout on
riscv64 physic machine. This test has 4496 sub-tests, and riscv64 has poor
single core performance, so this test run timeouted on riscv64 seems acceptable.
Thus, to make less test noisy, I think we should add
On Sun, 6 Oct 2024 16:42:15 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which suggests we clean up iteration and validation
> logic in `ZipFile.Source::initCEN` and some related methods to use a simpler
> and more consistent style:
>
> * The main loop in `ZipFile.Source::initCEN` curren
On Sun, 6 Oct 2024 09:15:58 GMT, SendaoYan wrote:
> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp
> mode.
This pull request has now been integrated.
Changeset: 33595189
Author:SendaoYan
URL:
https://git.openjdk.org/jdk/commit/3359518986bd12b0d97e5df5b01
On Sun, 6 Oct 2024 17:23:51 GMT, Markus KARG wrote:
> keep the reference to the char sequence "forever"
Note that this only happens if the `Reader` instance is kept forever; but a
`Reader` is supposed to be used and closed and discarded instead of being held
indefinitely after closing. If user
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 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
On Mon, 7 Oct 2024 15:32:53 GMT, Maurizio Cimadamore
wrote:
> Does this restacking make things clearer?
I really like this new definition.
To what extent do these rules determine the compatibility of FFM calling
conventions with the C calling convention? If I understand correctly, all
layout
On Mon, 7 Oct 2024 15:08:05 GMT, Vladimir Kozelkov wrote:
> > 4. {@code G} contains at least a non-padding member layout
>
> I reread all the points again, now the fourth one confuses me. Does it mean
> that now linker will not support empty structures at all?
>
> Previously you said this:
>
On Mon, 7 Oct 2024 12:16:15 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests we clean up iteration and validation
>> logic in `ZipFile.Source::initCEN` and some related methods to use a simpler
>> and more consistent style:
>>
>> * The main loop in `ZipFile.Source::initCEN` c
On Mon, 7 Oct 2024 14:17:52 GMT, Maurizio Cimadamore
wrote:
> 4. {@code G} contains at least a non-padding member layout
I reread all the points again, now the fourth one confuses me. Does it mean
that now linker will not support empty structures at all?
-
PR Comment: https://git
On Mon, 7 Oct 2024 14:50:33 GMT, Vladimir Kozelkov wrote:
> I don't really understand why unions should allow PaddingLayout inside
> themselves at all.
Padding inside unions is required for a case like this:
union Foo {
long long x;
int arr[3];
};
Size of the struct without padding
On Sun, 6 Oct 2024 09:15:58 GMT, SendaoYan wrote:
> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp
> mode.
Thanks for the review.
-
PR Comment: https://git.openjdk.org/jdk/pull/21375#issuecomment-2397159519
On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reword doce
These rules talk about GroupLayou
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Correct typo in comment
-
Changes:
- all: https://git.openjdk.org/jdk/
On Mon, 7 Oct 2024 12:54:00 GMT, Vladimir Kozelkov wrote:
> > I think the new rules should explicitly ban zero-element sequence layouts.
>
> Even in the rules with the latest edits, I don't see what exactly should
> prohibit such sequences.
>
> Also, if they are banned, won't that break jextra
On Tue, 24 Sep 2024 14:56:19 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
On Mon, 7 Oct 2024 12:49:45 GMT, Maurizio Cimadamore
wrote:
> I think the new rules should explicitly ban zero-element sequence layouts.
Even in the rules with the latest edits, I don't see what exactly should
prohibit such sequences.
-
PR Comment: https://git.openjdk.org/jdk/pul
On Mon, 7 Oct 2024 11:27:33 GMT, Vladimir Kozelkov wrote:
> Another test example. I can create a structure ending with PaddingLayout
>
> ```
> {
> Linker linker = Linker.nativeLinker();
> var sequence0a8 = MemoryLayout.sequenceLayout(0, JAVA_LONG);
> var sequence3a1 = MemoryLayout.se
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the occasional performance drop observed in 1 or 2 runs.
Prasa
On Mon, 7 Oct 2024 11:35:00 GMT, Claes Redestad wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Mark this resource hungry test manual
>> - For the benefit of the interpreter, extract loop predicate into a loca
> Please review this PR which suggests we clean up iteration and validation
> logic in `ZipFile.Source::initCEN` and some related methods to use a simpler
> and more consistent style:
>
> * The main loop in `ZipFile.Source::initCEN` currently updates two iteration
> variables (`pos` and `entryP
On Sun, 6 Oct 2024 16:42:15 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which suggests we clean up iteration and validation
> logic in `ZipFile.Source::initCEN` and some related methods to use a simpler
> and more consistent style:
>
> * The main loop in `ZipFile.Source::initCEN` curren
On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reword doce
I'll add this here because the ru
On Mon, 7 Oct 2024 09:00:28 GMT, Aleksei Efimov wrote:
>> This PR proposes the following changes to address wrong timeout computations
>> in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano)
>> clock. The existing `Timeout` test ha
(Moving this to core-libs-dev)
Cay,
Regarding 1, Characteristics was a part of the Gatherers-contract for a very
long time, alas it didn't end up worth its cost. There's a longer discussion on
the topic here:
https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/118138.html (and
I'm s
Please review this PR which suggests we clean up iteration and validation logic
in `ZipFile.Source::initCEN` and some related methods to use a simpler and more
consistent style:
* The main loop in `ZipFile.Source::initCEN` currently updates two iteration
variables (`pos` and `entryPos`), where
On Sun, 6 Oct 2024 09:15:58 GMT, SendaoYan wrote:
> A trivial fix to ProblemList `java/foreign/TestUpcallStress.java` in Xcomp
> mode.
Marked as reviewed by jvernee (Reviewer).
FWIW, I think it would be okay to disable this test on -Xcomp altogether. It
tests a very precise race, so -Xcomp pr
Please review this PR which adds validation of the 'total entries' value when
fetched from the 'ZIP64 End of Central Directory' header.
We should reject this value under the following conditions:
1. It is too large to fit within the specified CEN size (considering each CEN
header encodes as at
On Sun, 6 Oct 2024 21:49:08 GMT, Claes Redestad wrote:
>>> How would you model unsigned long values here, though?
>>
>> I don't think we should. `9223372036854775807 ` should be enough for
>> everyone :-)
>>
>> It may be worth renaming the method to `get64S` and add a `get64` variant
>> which
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Speed up computation of shiftRight() and bitLength()
-
Changes:
- all:
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the occasional performance drop observed in 1 or 2 runs.
Prasa
> This PR proposes the following changes to address wrong timeout computations
> in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano)
> clock. The existing `Timeout` test has also been updated to use the nano
> clock to measure obser
On Sun, 6 Oct 2024 02:35:45 GMT, SendaoYan wrote:
> Hi all,
> The newly added test `java/foreign/TestUpcallStress.java` call
> `System.loadLibrary("TestUpcall")` load native library, so this test should
> mark as `/native`.
> The change has been verified locally, trivial fix, no risk.
Marked a
On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Minor change
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21323/
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
More explaining variable identificator
-
Changes:
- all: https://git.o
On Sun, 6 Oct 2024 14:50:48 GMT, Markus KARG wrote:
>> src/java.base/share/classes/java/io/Reader.java line 174:
>>
>>> 172: * @since 24
>>> 173: */
>>> 174: public static Reader of(CharSequence c) {
>>
>> Should we give this factory a more specific name so we don't clash in the
On Mon, 7 Oct 2024 01:52:59 GMT, David Schlosnagle wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 417:
>>
>>> 415: if (size > 65536) {
>>> 416: size = 8192;
>>> 417: }
>>
>> Not sure if this clamping makes se
> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses
> repeated squares trick.
fabioromano1 has updated the pull request incrementally with two additional
commits since the last revision:
- Correct indentation
- Refine the estimate of remaining zeros
-
Change
On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Mon, 7 Oct 2024 06:26:09 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
> 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.html was
> an experimental and unsupported tool. Ever
On Mon, 7 Oct 2024 06:46:23 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update module-info of java.scripting to note about jrunscript tool
>> deprecation
>
> src/java.scripting/share/classes/
88 matches
Mail list logo
