On Wed, 22 Sep 2021 03:57:21 GMT, Daniel D. Daugherty
wrote:
>> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes.
>>
>> This refactoring was tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request with a new target base due
> to a merge or a
On Fri, 3 Sep 2021 05:05:34 GMT, Jakob Cornell
wrote:
>> This has been under discussion on and off for the past month or so on
>> serviceability-dev, and I think a CSR request is required, so this may be a
>> work in progress.
>>
>> Notes on the patch:
>>
>> - The `list` command previously m
On Wed, 22 Sep 2021 18:21:51 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty 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 contains five
>> additi
In several places, String.compareTo was _compared_ with 0 ( via `== 0` or `!=
0`).
Instead of this, we can use String.equals calls. `String.equals` is faster and
shorter.
-
Commit messages:
- [PATCH] Use String.equals instead of String.compareTo to check String's
equality in jdk.j
On Wed, 22 Sep 2021 03:57:21 GMT, Daniel D. Daugherty
wrote:
>> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes.
>>
>> This refactoring was tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request with a new target base due
> to a merge or a
On Wed, 22 Sep 2021 19:14:03 GMT, Andrey Turbanov
wrote:
> In several places, String.compareTo was _compared_ with 0 ( via `== 0` or `!=
> 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster
> and shorter.
Looks good. Make sure you have done the appropriate testi
On Wed, 22 Sep 2021 19:14:03 GMT, Andrey Turbanov
wrote:
> In several places, String.compareTo was _compared_ with 0 ( via `== 0` or `!=
> 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster
> and shorter.
Marked as reviewed by amenkov (Reviewer).
-
On Fri, 17 Sep 2021 08:24:54 GMT, Lin Zang wrote:
> The class `GzipRandomAccess` is used to parse heap dump file generated from
> `jcmd`/`jmap` tools when testing.
> It has the limitation that only gzip file which has "blocksize" header field
> could be sucessfully parsed.
> We think this class
On Wed, 22 Sep 2021 19:14:03 GMT, Andrey Turbanov
wrote:
> In several places, String.compareTo was _compared_ with 0 ( via `== 0` or `!=
> 0`).
> Instead of this, we can use String.equals calls. `String.equals` is faster
> and shorter.
Looks good.
Thanks,
Serguei
-
Marked as rev
On Wed, 22 Sep 2021 18:39:05 GMT, Jakob Cornell
wrote:
> Thanks for following up on that Chris. Are there any outstanding changes that
> need to be made to the PR then, or are we waiting for the CSR process?
I think we can do the CSR now. I got it started with
https://bugs.openjdk.java.net/br
Cleanup places, where String.compareTo is used to check String's equality.
Instead String.equals or switch expression could be used. They are faster and
code is cleaner.
-
Commit messages:
- Avoid String.compareTo == 0 to check String equality
Changes: https://git.openjdk.java.net/
On Wed, 22 Sep 2021 20:39:51 GMT, Andrey Turbanov
wrote:
> Cleanup places, where String.compareTo is used to check String's equality.
> Instead String.equals or switch expression could be used. They are faster and
> code is cleaner.
src/java.management/share/classes/javax/management/BinaryRelQ
On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote:
> This logic no longer seems to be necessary since the adjustCompilationLevel
> callback has been removed.
Hi Tom,
The fix looks good in general.
We disabled can_pop_frame and can_pop_early_return capabilities with Graal
because some jvmti
On Wed, 22 Sep 2021 20:58:47 GMT, Chris Plummer wrote:
>> Cleanup places, where String.compareTo is used to check String's equality.
>> Instead String.equals or switch expression could be used. They are faster
>> and code is cleaner.
>
> src/java.management/share/classes/javax/management/BinaryR
On Fri, 3 Sep 2021 05:05:34 GMT, Jakob Cornell
wrote:
>> This has been under discussion on and off for the past month or so on
>> serviceability-dev, and I think a CSR request is required, so this may be a
>> work in progress.
>>
>> Notes on the patch:
>>
>> - The `list` command previously m
On Wed, 22 Sep 2021 21:34:12 GMT, Andrey Turbanov
wrote:
>> src/java.management/share/classes/javax/management/BinaryRelQueryExp.java
>> line 180:
>>
>>> 178: return sval1.compareTo(sval2) <= 0;
>>> 179: case Query.EQ:
>>> 180: return sval1.equals(sv
On Fri, 3 Sep 2021 05:05:34 GMT, Jakob Cornell
wrote:
>> This has been under discussion on and off for the past month or so on
>> serviceability-dev, and I think a CSR request is required, so this may be a
>> work in progress.
>>
>> Notes on the patch:
>>
>> - The `list` command previously m
On Wed, 22 Sep 2021 21:52:03 GMT, Chris Plummer wrote:
>> But it's now consistent with Query operator: **EQ**uals
>
> All of the other case statements map a Query operator to an arithmetic
> operator, including mapping EQ to ==, even after your changes (see the
> previous switch blocks). So you
On Tue, 21 Sep 2021 23:47:41 GMT, Coleen Phillimore wrote:
>> This change removes the special ranking and folds it into nosafepoint. You
>> have to look at commit #3 to see this actual part of the change that doesn't
>> include JDK-8273915.
>> This passes tier1-6 also.
>
> Coleen Phillimore ha
On Wed, 22 Sep 2021 23:14:39 GMT, Serguei Spitsyn wrote:
>> All of the other case statements map a Query operator to an arithmetic
>> operator, including mapping EQ to ==, even after your changes (see the
>> previous switch blocks). So your use of `equals` really sticks out as not
>> being con
On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote:
> This logic no longer seems to be necessary since the adjustCompilationLevel
> callback has been removed.
Since Graal is gone I don't think it's possible to run those tests any more.
It might be possible to run those tests on some source
On Thu, 23 Sep 2021 02:52:11 GMT, David Holmes wrote:
>> I agree with Chris on this.
>> Fix in the other file looks okay to me.
>
> I look at it this way, the code should really (IMHO) have been written as:
>
> int res = sval1.compareTo(sval2);
> switch(relOp) {
> case Query.GT: return res > 0;
On Wed, 22 Sep 2021 05:40:40 GMT, Tom Rodriguez wrote:
> This logic no longer seems to be necessary since the adjustCompilationLevel
> callback has been removed.
Yes, I got errors since Graal is gone:
`JVMCI compiler 'graal' specified by jvmci.Compiler not found`
If you have a repository with
23 matches
Mail list logo
