> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A couple key things we want to be able to say are:
> -
On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai wrote:
> Can I get a review of this change which proposes to remove the `SystemTest`
> from among the `JSR166TestCase`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the
> `SystemTest.nanoTime` test has been intermittently failing
On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai wrote:
> Can I get a review of this change which proposes to remove the `SystemTest`
> from among the `JSR166TestCase`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the
> `SystemTest.nanoTime` test has been intermittently failing
On Thu, 22 Feb 2024 22:50:03 GMT, Justin Lu wrote:
>> Please review this PR which handles an edge case pattern bug with
>> ChoiceFormat.
>>
>>
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
>> "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>>
On Thu, 22 Feb 2024 23:14:37 GMT, Brent Christian wrote:
>> I note that the adjective(s) (un)successful and the adverb(s)
>> (un)successfully are used at several places in these comments, it might
>> makes sense to use those terms here as well such that the documentation in
>> internally
On Thu, 22 Feb 2024 18:24:39 GMT, Y. Srinivas Ramakrishna
wrote:
>> or, better yet, `fails`
>
> I note that the adjective(s) (un)successful and the adverb(s)
> (un)successfully are used at several places in these comments, it might makes
> sense to use those terms here as well such that the
On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy wrote:
> Widen acceptable error bound of Math.tan to accommodate the worst-case
> observed error which is slightly outside of the allowable range.
Looks fine.
-
Marked as reviewed by bpb (Reviewer).
PR Review:
> Please review this PR which handles an edge case pattern bug with
> ChoiceFormat.
>
>
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
> "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
>
>
> Not only does this lead to faulty formatting results,
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where
> aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the
> in-house cache with WeakHashMap, and removed the Key class as it is no longer
> needed (thus the original NPE will no longer be possible).
On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote:
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344)
> which adds MessageFormat pattern support for the following subformats:
> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is
> intended to
Widen acceptable error bound of Math.tan to accommodate the worst-case observed
error which is slightly outside of the allowable range.
-
Commit messages:
- JDK-8326530: Widen allowable error bound of Math.tan
Changes: https://git.openjdk.org/jdk/pull/17973/files
Webrev:
> Please review this PR which handles an edge case pattern bug with
> ChoiceFormat.
>
>
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
> "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
>
>
> Not only does this lead to faulty formatting results,
The change updates the test to throw an exception if expected
AgentLoadException is not thrown
-
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/17971/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17971=00
Issue:
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where
> aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the
> in-house cache with WeakHashMap, and removed the Key class as it is no longer
> needed (thus the original NPE will no longer be possible).
On Thu, 22 Feb 2024 00:14:23 GMT, Naoto Sato wrote:
>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211
>> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored
>> the in-house cache with WeakHashMap, and removed the Key class as it is no
>> longer
On Thu, 22 Feb 2024 17:38:50 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/text/ChoiceFormat.java line 332:
>>
>>> 330:
>>> 331: // Used to explicitly define the segment mode while applying a
>>> pattern
>>> 332: private enum Segment {
>>
>> Do we need a new enum? Would
On Thu, 22 Feb 2024 17:55:18 GMT, Justin Lu wrote:
>> Please review this PR which handles an edge case pattern bug with
>> ChoiceFormat.
>>
>>
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
>> "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>>
On Mon, 27 Nov 2023 22:41:25 GMT, Hans Boehm wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Cleaner thread dequeue happens-before running cleaning action
>
>
On Thu, 22 Feb 2024 01:42:17 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Thu, 22 Feb 2024 12:05:31 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 491:
>>
>>> 489: * If this reference is not registered with a queue, or was
>>> already enqueued
>>> 490: * (by the garbage collector, or a previous call to
> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756)
> which defines the behavior for creating ChoiceFormats with incorrect
> patterns. The wording is added to both the ChoiceFormat constructor and
> ChoiceFormat::applyPattern method.
>
> While ideally the
> Please review this PR which handles an edge case pattern bug with
> ChoiceFormat.
>
>
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
> "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
>
>
> Not only does this lead to faulty formatting results,
On Tue, 20 Feb 2024 23:14:26 GMT, Naoto Sato wrote:
>> Please review this PR which handles an edge case pattern bug with
>> ChoiceFormat.
>>
>>
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
>> "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>>
On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai wrote:
> Can I get a review of this change which proposes to remove the `SystemTest`
> from among the `JSR166TestCase`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the
> `SystemTest.nanoTime` test has been intermittently failing
On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai wrote:
> Can I get a review of this change which proposes to remove the `SystemTest`
> from among the `JSR166TestCase`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the
> `SystemTest.nanoTime` test has been intermittently failing
> Currently assertEquals has in the failure case sometimes confusing output
> like :
>
> java.lang.RuntimeException: VM output should contain exactly one RTM locking
> statistics entry for method
> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test: expected 0 to equal 1
>at
On Thu, 22 Feb 2024 15:23:56 GMT, Christoph Langer wrote:
> I think it is a good idea to improve this. I was irritated by that output
> more than once.
>
> Maybe a better message would be ... _"..." is not equal to "..."_ ?
Thanks , I adjusted the output .
-
PR Comment:
On Thu, 22 Feb 2024 14:57:05 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
> Currently assertEquals has in the failure case sometimes confusing output
> like :
>
> java.lang.RuntimeException: VM output should contain exactly one RTM locking
> statistics entry for method
> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test: expected 0 to equal 1
>at
> Please review this PR which proposes that we officially deprecate the
> following four methods in the `java.util.zip` package:
>
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
>
> Since these legacy methods return `int`, they
On Tue, 20 Feb 2024 14:23:35 GMT, Alan Bateman wrote:
> > Should these methods specify return values when the number of processed
> > bytes exceed Integer.MAX_VALUE?
>
> I think they should, otherwise it's not clear if the return value is clamped
> at Integer.MAX_VALUE. The wording can make
> Please review this PR which proposes that we officially deprecate the
> following four methods in the `java.util.zip` package:
>
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `Deflater.getTotalIn()`
> * `Deflater.getTotalOut()`
>
> Since these legacy methods return `int`, they
On Wed, 21 Feb 2024 21:42:08 GMT, Alex Menkov wrote:
>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with
>> AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from
>> HotSpotVirtualMachine.processCompletionStatus (called from
>>
On Thu, 22 Feb 2024 01:42:17 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Thu, 22 Feb 2024 12:04:05 GMT, Daniel Jeliński wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Cleaner thread dequeue happens-before running cleaning action
>
>
On Wed, 21 Feb 2024 15:01:15 GMT, Viktor Klang wrote:
> More aggressively breaking chains in order to prevent nodes promoted to older
> generations standing in the way for collecting younger nodes. I decided that
> it was most efficient to add this logic to the else-branch of updating the
>
On Wed, 21 Feb 2024 18:26:18 GMT, Aleksei Efimov wrote:
>>> Currently, it is hard to distinguish what part of the test responsible for
>>> [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) testing, and
>>> which part is for
>>>
On Thu, 15 Feb 2024 19:44:42 GMT, Justin Lu wrote:
> Please review this PR which handles an edge case pattern bug with
> ChoiceFormat.
>
>
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
> "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
>
>
>
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>
Can I get a review of this change which proposes to remove the `SystemTest`
from among the `JSR166TestCase`?
As noted in https://bugs.openjdk.org/browse/JDK-8278527 the
`SystemTest.nanoTime` test has been intermittently failing since a few years
now. Martin and Paul have investigated this
On Thu, 22 Feb 2024 01:42:17 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Thu, 22 Feb 2024 01:42:17 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>
45 matches
Mail list logo
