On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
1) This is un-necessary churn.
2) I can't
On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy
wrote:
> I have in mind dozens of improvements all over the code like this one.
That sounds scary. Broad updates like these cause unnecessary churn in the
codebase, and can make merging and back
porting harder. Changes should be discussed ah
Hi Paul,
thanks for looking into this!
> The update to AbstractStringBuilder is problematic because the uninitialized
> array could potentially be accessed through reflection.
>
> In other cases it seems you have slotted in the allocation at a low-level
> e.g. StringUTF16.newBytesFor. That make
Hello,
We would like to open a discussion about a new project focused on
"Coordinated Restore at Checkpoint".
A possible relevant project name might be Tubthumpting [9].
Over the years, we [at Azul] have tinkered with various ways to improve java
start-up time and warmup behavior for different u
On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall
wrote:
>> Hello, newbie here
>>
>> I picked JDK-8138732 to work on because it has a "starter" label and I
>> believe I understand what to do.
>>
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change `@sinc
On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote:
>> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to
>> post, but even if you are a reply-all will
>> be delayed due to all of the mails being held up for moderator approval due
>> to:
>> " Too many recipients to the
On Thu, 10 Sep 2020 15:23:14 GMT, Gilles Duboscq wrote:
>> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced
>> the
>> jdk.internal.lambda.disableEagerInitialization system property to be able to
>> disable eager initialization of lambda
>> classes. This was necessary t
On Thu, 10 Sep 2020 16:16:57 GMT, Joe Wang wrote:
>> Marked as reviewed by alanb (Reviewer).
>
> Remove the implNote from the package description added by JDK-8249643.
> The implementation's deviation from the specification was actually wrong.
> It incorrectly identified characters from #x1 t
On Thu, 10 Sep 2020 05:45:59 GMT, Alan Bateman wrote:
>> Revert changes made by JDK-8249643, removing the implNote.
>
> Marked as reviewed by alanb (Reviewer).
Remove the implNote from the package description added by JDK-8249643.
The implementation's deviation from the specification was actuall
On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote:
> `jlink --generate-jli-classes` plugin should retain the original holder
> classes if the default_jli_trace.txt
> file does not exist.
>
> Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes`
> methods are invoked
> unco
On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote:
>> @dholmes-ora raises a good point. Hopefully there is a balance point between
>> a dozen different bugs / pull requests
>> each targeting one area and one bug / PR targeting a dozen separate areas. I
>> don't have a good general rule to su
On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote:
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
The code in java.base was updated to use String::isEmpty in JDK 12
(JDK-8215281). There was follow-up in JDK 13 to do
the same in the java.desktop module (JDK-8223237). Changing the remainin
On Thu, 10 Sep 2020 11:50:04 GMT, Gilles Duboscq wrote:
>> It's a good suggestion as `disableEagerInitialization` support is not part
>> of javac.
>
> OK makes sense. I guess it's still good to clean the test comments of the old
> `disableEagerInitialization` references?
I have created a new t
> [JDK-8232806](https://bugs.openjdk.java.net/browse/JDK-8232806) introduced the
> jdk.internal.lambda.disableEagerInitialization system property to be able to
> disable eager initialization of lambda
> classes. This was necessary to prevent side effects of class initializers
> triggered by such
On Wed, 9 Sep 2020 16:36:43 GMT, Mandy Chung wrote:
>> Gilles Duboscq has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Remove extra field test from LambdaTest6
>> - Wrap long lines
>> - Add deciated test in the jdk tests
>
> src/jav
On Tue, 8 Sep 2020 15:19:40 GMT, Roger Riggs wrote:
> 8252830: Correct missing javadoc comments in java.rmi module
This pull request has now been integrated.
Changeset: 418e4a25
Author:Roger Riggs
URL: https://git.openjdk.java.net/jdk/commit/418e4a25
Stats: 39 lines in 4 files ch
On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote:
>> This should be broken up to deal with the files in different functional
>> areas under different bugids and PRs. Otherwise
>> the cross-posting to so many lists is prohibitive. Files in different areas
>> need to be reviewed by differe
On Thu, 10 Sep 2020 12:20:05 GMT, Evgeny Nikitin wrote:
> pre-Skara RFR thread:
> [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
>
> Error reporting was improved by writing a C-style escaped string
> representations for the variables passed to the
> m
pre-Skara RFR thread:
[link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
Error reporting was improved by writing a C-style escaped string
representations for the variables passed to the
methods being tested. For array comparisons, a dedicated diff-formatter
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
>> The code in java.base was updated to use String::isEmpty in JDK 12
>> (JDK-8215281). There was follow-up in JDK 13 to do
>> the same in the java.desktop module (JDK-8223237). Changing the remaining
>> usages make sense although I see that
On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote:
> `jlink --generate-jli-classes` plugin should retain the original holder
> classes if the default_jli_trace.txt
> file does not exist.
>
> Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes`
> methods are invoked
> unco
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
>> The code in java.base was updated to use String::isEmpty in JDK 12
>> (JDK-8215281). There was follow-up in JDK 13 to do
>> the same in the java.desktop module (JDK-8223237). Changing the remaining
>> usages make sense although I see that
On Wed, 9 Sep 2020 16:39:25 GMT, Mandy Chung wrote:
>> test/langtools/tools/javac/lambda/lambdaExpression/LambdaTest6.java line 29:
>>
>>> 27: * @summary Add lambda tests
>>> 28: * Test bridge methods for certain SAM conversions
>>> 29: * Test the set of generate fields
>>
>> I would sug
On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote:
>> @kevinrushforth thanks. Done.
>>
>> Similar issues:
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=822
On 10/09/2020 10:44, Archana Nogriya wrote:
Hi,
I am requesting a proposal for the contribution to OpenJDK.
I have created webrev with my changes.
Moving to build-dev as that is normally where the linker options are
discussed.
I don't know if there is a significant need for Windows 32-bit bu
On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy
wrote:
>> Before this Enhancement can be formally reviewed, you will need a JBS bug
>> ID. If you are already working with a
>> Committer or Reviewer in the `jdk` project who has agreed to sponsor your
>> change, they can file the Enhancement
On Wed, 9 Sep 2020 19:38:38 GMT, Mandy Chung wrote:
> `jlink --generate-jli-classes` plugin should retain the original holder
> classes if the default_jli_trace.txt
> file does not exist.
>
> Before JDK-8252725, `JavaLangInvokeAccess::generateXXXHolderClassesBytes`
> methods are invoked
> unco
Hi,
I am requesting a proposal for the contribution to OpenJDK.
I have created webrev with my changes.
Please can I have someone to review my changes and suggest further.
Details description is as follow,
==
Title : Add the /LARGEADDRESSAWARE fl
Hi,
I am requesting a proposal for the contribution to OpenJDK.
I have created webrev with my changes.
Please can I have someone to review my changes and suggest further.
Details description is as follow,
===
Title : Performance optimization by setting MALL
On Wed, 9 Sep 2020 20:21:44 GMT, Kevin Rushforth wrote:
>> @mrserb hello. Thanks for the review. Any further actions required from me?
>
> Before this Enhancement can be formally reviewed, you will need a JBS bug ID.
> If you are already working with a
> Committer or Reviewer in the `jdk` projec
On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy
wrote:
>> @doom369 jcheck requires an associated issue
>
> @mrserb hello. Thanks for the review. Any further actions required from me?
Before this Enhancement can be formally reviewed, you will need a JBS bug ID.
If you are already working wit
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
src/demo/share/java2d/J2DBench/src/j2dben
On Sun, 6 Sep 2020 18:08:15 GMT, thatsIch
wrote:
>> **isEmpty** is faster + has less byte code + easier to read. Benchmarks
>> could be found
>>
>> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
>
> @doom369 jcheck requires an associated issu
**isEmpty** is faster + has less byte code + easier to read. Benchmarks could
be found
[here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
-
Commit messages:
- Merge branch 'master' of https://github.com/doom369/jdk into
reaplce_equal
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
@doom369 jcheck requires an associated is
> On 4 Sep 2020, at 21:32, Vipin Sharma wrote:
>
>
> I have generated Javadoc for all updated packages and compared html files,
> before and after changes.
Since effects can be nonlocal (e.g. {@inheritDoc}), you should always compare
everything.
>> There are ~ 1.5K lines, 86 files changed in
On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall
wrote:
>> Hello, newbie here
>>
>> I picked JDK-8138732 to work on because it has a "starter" label and I
>> believe I understand what to do.
>>
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change `@sinc
37 matches
Mail list logo