When writing factory methods for Gatherers, there's sometimes a
degenerate case that requires returning a no-op Gatherer. So I'd like a
way to mark a no-op Gatherer as such, allowing the Stream implementation
to recognize and eliminate it from the pipeline. One idea is to add
Gatherer.defaultIn
On Fri, 26 Jul 2024 16:46:28 GMT, Archie Cobbs wrote:
> With this new proposed change we will throw an IOException (unlike
> previously). I think that's fine and in fact the correct thing to do.
I've run into a problem.
With this change, `GZIPInZip.java` fails; the test is annotated like this:
On Fri, 26 Jul 2024 15:13:06 GMT, Andrew Haley wrote:
>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>>
>> HotSpot
On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote:
> StringConcatFactory improves startup speed and running performance through
> simpleConcat, but simpleConcat is currently given priority and only supports
> the following scenarios:
>
> // x instanceof Object
> prefix + x
> x = subfix
>
>
On Fri, 26 Jul 2024 23:02:14 GMT, Justin Lu wrote:
>> Please review this PR which is a simple doc only change to
>> java.text.DecimalFormat.
>>
>> Mainly, the DecimalFormat constructors have wording that recommends using
>> the NumberFormat factory methods for a standard formatting. This would
On Fri, 26 Jul 2024 22:51:26 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update see links with Locale arg link
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 478:
>
>> 476:
> Please review this PR which is a simple doc only change to
> java.text.DecimalFormat.
>
> Mainly, the DecimalFormat constructors have wording that recommends using the
> NumberFormat factory methods for a standard formatting. This would be better
> tagged as an `@apiNote`. Minor wording updat
On Fri, 26 Jul 2024 21:22:58 GMT, Justin Lu wrote:
>> Please review this PR which is a simple doc only change to
>> java.text.DecimalFormat.
>>
>> Mainly, the DecimalFormat constructors have wording that recommends using
>> the NumberFormat factory methods for a standard formatting. This would
> Add some verbiage stating that two buffered readers or input streams should
> not be used to read from the same reader or input stream, respectively.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8336895: Modified verbiage pe
On Thu, 25 Jul 2024 22:33:44 GMT, Chen Liang wrote:
>> Removed redundant APIs in `JavaLangReflectAccess` and added general warning
>> against using `SharedSecrets`.
>>
>> The cleanup in `JavaLangReflectAccess` is:
>> - Converted `newConstructor` taking parameters to taking another constructor
On Fri, 26 Jul 2024 15:13:06 GMT, Andrew Haley wrote:
>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>>
>> HotSpot
On Fri, 26 Jul 2024 04:40:35 GMT, Jaikiran Pai wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8336895: s/dues/does/
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 56:
>
>> 54: * to rea
On Fri, 26 Jul 2024 18:39:27 GMT, Vladimir Ivanov wrote:
> Oh, it comes as a surprise to me... I was under impression that the first
> thing hand-coded assembly variants do is check for `bitmap !=
> SECONDARY_SUPERS_BITMAP_FULL`. At least, it was my recollection from working
> on [JDK-8180450]
On Thu, 25 Jul 2024 10:05:03 GMT, Alan Bateman wrote:
> Also think to work through some naming on IOUtil vs. NIOUtil as it won't be
> obvious to maintainers which class to use.
Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only by
classes involved in networking?
On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote:
> StringConcatFactory improves startup speed and running performance through
> simpleConcat, but simpleConcat is currently given priority and only supports
> the following scenarios:
>
> // x instanceof Object
> prefix + x
> x = subfix
>
>
On Fri, 26 Jul 2024 21:22:58 GMT, Justin Lu wrote:
>> Please review this PR which is a simple doc only change to
>> java.text.DecimalFormat.
>>
>> Mainly, the DecimalFormat constructors have wording that recommends using
>> the NumberFormat factory methods for a standard formatting. This would
> Please review this PR which is a simple doc only change to
> java.text.DecimalFormat.
>
> Mainly, the DecimalFormat constructors have wording that recommends using the
> NumberFormat factory methods for a standard formatting. This would be better
> tagged as an `@apiNote`. Minor wording updat
On Fri, 26 Jul 2024 21:05:07 GMT, Chen Liang wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect review
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 438:
>
>> 436: * NumberFormat#getNumb
On Fri, 26 Jul 2024 20:45:43 GMT, Justin Lu wrote:
>> Please review this PR which is a simple doc only change to
>> java.text.DecimalFormat.
>>
>> Mainly, the DecimalFormat constructors have wording that recommends using
>> the NumberFormat factory methods for a standard formatting. This would
> Please review this PR which is a simple doc only change to
> java.text.DecimalFormat.
>
> Mainly, the DecimalFormat constructors have wording that recommends using the
> NumberFormat factory methods for a standard formatting. This would be better
> tagged as an `@apiNote`. Minor wording updat
On Fri, 26 Jul 2024 20:05:53 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect review
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 441:
>
>> 439: * @see NumberFormat#ge
On Fri, 26 Jul 2024 19:17:34 GMT, Justin Lu wrote:
> Please review this PR which is a simple doc only change to
> java.text.DecimalFormat.
>
> Mainly, the DecimalFormat constructors have wording that recommends using the
> NumberFormat factory methods for a standard formatting. This would be b
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
Please review this PR which is a simple doc only change to
java.text.DecimalFormat.
Mainly, the DecimalFormat constructors have wording that recommends using the
NumberFormat factory methods for a standard formatting. This would be better
tagged as an `@apiNote`. Minor wording updates included
On Fri, 26 Jul 2024 00:00:49 GMT, Shaojin Wen wrote:
> 8337245: Fix wrong comment of StringConcatHelper
Trivial.
-
Marked as reviewed by phh (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20344#pullrequestreview-2202564779
On Fri, 26 Jul 2024 15:13:06 GMT, Andrew Haley wrote:
>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>>
>> HotSpot
On Fri, 26 Jul 2024 15:53:11 GMT, Andriy Plokhotnyuk wrote:
> Could you please review [these](https://github.com/openjdk/jdk/pull/11986)
> proposed changes for instantiation of `Instant` values with already
> normalized nanos?
@plokhotnyuk Your contribution cannot be acted upon until the OCA i
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Fri, 26 Jul 2024 16:12:11 GMT, Jaikiran Pai wrote:
>> Archie Cobbs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 16 commits:
>>
>> - Merge branch 'master' into JDK-8322256
>> - Wording tweak.
>> - Change concatenation poli
On Wed, 24 Jul 2024 14:57:05 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote:
> StringConcatFactory improves startup speed and running performance through
> simpleConcat, but simpleConcat is currently given priority and only supports
> the following scenarios:
>
> // x instanceof Object
> prefix + x
> x = subfix
>
>
On Fri, 26 Jul 2024 15:56:14 GMT, Shaojin Wen wrote:
> StringConcatFactory improves startup speed and running performance through
> simpleConcat, but simpleConcat is currently given priority and only supports
> the following scenarios:
>
> // x instanceof Object
> prefix + x
> x = subfix
>
>
StringConcatFactory improves startup speed and running performance through
simpleConcat, but simpleConcat is currently given priority and only supports
the following scenarios:
// x instanceof Object
prefix + x
x = subfix
// x instanceof Object && z instanceof Object
x + y
This PR improves st
On Fri, 26 Jul 2024 15:44:59 GMT, Shaojin Wen wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one addi
On Fri, 26 Jul 2024 13:36:43 GMT, Lance Andersen wrote:
>> Archie Cobbs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 16 commits:
>>
>> - Merge branch 'master' into JDK-8322256
>> - Wording tweak.
>> - Change concatenation po
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
add comment
-
On Thu, 25 Jul 2024 23:31:21 GMT, Vladimir Ivanov wrote:
> Thanks! The patch looks good, except there was one failure observed during
> testing with the latest patch [1]. It does look related to the latest changes
> you did in
> [54050a5](https://github.com/openjdk/jdk/pull/19989/commits/54050
On Fri, 26 Jul 2024 15:24:46 GMT, Stephen Colebourne
wrote:
>> By removing the redundant code logic in
>> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
>> reduced and the performance can be improved.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatt
> Add some verbiage stating that two buffered readers or input streams should
> not be used to read from the same reader or input stream, respectively.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8336895: s/dues/does/
--
On Fri, 26 Jul 2024 14:20:07 GMT, Shaojin Wen wrote:
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
>
> HotSpot shared runtime
> --
>
> Building hashed s
On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote:
>> The current LocalDateTime.toString implementation concatenates the toString
>> results of date and time, which can be passed to StringBuilder to reduce
>> additional object allocation and improve performance.
>
> Shaojin Wen has updated th
On Fri, 26 Jul 2024 12:25:24 GMT, Stephen Colebourne
wrote:
> This change is fine, however the comments and performance testing assume that
> a date is always 10 characters long which isn't true, as the year could be
> greater than .
The scenario where year is greater than also works
On Fri, 26 Jul 2024 14:20:07 GMT, Shaojin Wen wrote:
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
By removing redundant code logic, the codeSize can be reduced from 444 to
By removing the redundant code logic in
DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
reduced and the performance can be improved.
-
Commit messages:
- optimize format instant
Changes: https://git.openjdk.org/jdk/pull/20353/files
Webrev: https://web
On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote:
>> The current LocalDateTime.toString implementation concatenates the toString
>> results of date and time, which can be passed to StringBuilder to reduce
>> additional object allocation and improve performance.
>
> Shaojin Wen has updated th
On Wed, 24 Jul 2024 14:57:05 GMT, Archie Cobbs wrote:
>> `GZIPInputStream` supports reading data from multiple concatenated GZIP data
>> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In
>> order to do this, after a GZIP trailer frame is read, it attempts to read a
>
On Fri, 26 Jul 2024 08:03:01 GMT, Adam Sotona wrote:
>> As discussed in offline meeting, the max stack and locals information are
>> part of the code attribute and not meaningful for buffered code elements.
>> Computation would be costly and these see no real usage during
>> transformations. T
On Thu, 25 Jul 2024 01:14:32 GMT, Shaojin Wen wrote:
>> @cl4es I would wait, to be honest. I'm currently quite busy, but I hope I
>> can do something here in the next 2-3 weeks.
>
> @eme64 Unsafe.putByte MergeStore of master branch doesn't work
>
>
> import sun.misc.Unsafe;
>
> public class
On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote:
>> The current LocalDateTime.toString implementation concatenates the toString
>> results of date and time, which can be passed to StringBuilder to reduce
>> additional object allocation and improve performance.
>
> Shaojin Wen has updated th
On Thu, 25 Jul 2024 05:06:17 GMT, Shaojin Wen wrote:
> The current LocalDateTime.toString implementation concatenates the toString
> results of date and time, which can be passed to StringBuilder to reduce
> additional object allocation and improve performance.
This pull request has now been i
On Wed, 24 Jul 2024 13:20:31 GMT, fabioromano1 wrote:
>> The aim is not about having even more efficient code (yours is already
>> faster than the existing algorithm), but to have simpler code.
>>
>> The two denormalization code snippets, while based on the same underlying
>> math, are quite d
On Thu, 25 Jul 2024 23:05:46 GMT, Shaojin Wen wrote:
>> The current LocalDateTime.toString implementation concatenates the toString
>> results of date and time, which can be passed to StringBuilder to reduce
>> additional object allocation and improve performance.
>
> Shaojin Wen has updated th
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the New
On Thu, 25 Jul 2024 23:11:15 GMT, Chen Liang wrote:
> Removes 6 `AccessFlags` factories that do not take class-file versions as its
> arguments.
>
> `AccessFlags` is a wrapper around a bit mask to support modifier streaming in
> ClassFile API. It additionally supports advanced validation based
On Thu, 25 Jul 2024 22:41:08 GMT, Chen Liang wrote:
> As discussed in offline meeting, the max stack and locals information are
> part of the code attribute and not meaningful for buffered code elements.
> Computation would be costly and these see no real usage during
> transformations. Thus,
On Fri, 26 Jul 2024 06:29:18 GMT, Jaikiran Pai wrote:
> The latest change looks OK to me. Please wait for Alan to decide if this is
> OK to integrate.
Okey, thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/19905#issuecomment-2252123786
On Thu, 25 Jul 2024 05:30:34 GMT, Shaojin Wen wrote:
> Integer.stringSize and Long.stringSize are used not only in java.lang, but
> also in other places. We put stringSize in DecimalDigits to reduce duplicate
> code and the use of JLA.
This pull request has now been integrated.
Changeset: 7f1
On Thu, 25 Jul 2024 14:29:05 GMT, Shaojin Wen wrote:
>> Integer.stringSize and Long.stringSize are used not only in java.lang, but
>> also in other places. We put stringSize in DecimalDigits to reduce duplicate
>> code and the use of JLA.
>
> Shaojin Wen has updated the pull request incremental
59 matches
Mail list logo
