On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato wrote:
> Backing out a fix that is causing a T1 failure.
>
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.
Backout looks accurate - thanks.
-
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.org/jdk/pul
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
I eyeballed the diff file and all seems okay.
Thanks,
David
-
Marked as reviewed by dholmes (Reviewer).
PR: http
.html
(or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-79465)
[^2]:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
_Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
[core-libs-dev](mailto:core-libs
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
> `-Djava.secu
On Fri, 5 Mar 2021 18:58:44 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix omitted synchronized
>
> Looks good.
If I read the order right your benchmark findings were done before you added
On 20/02/2021 12:00 am, Naoto Sato wrote:
On Thu, 18 Feb 2021 14:49:20 GMT, Roger Riggs wrote:
The table is informative and should not be construed as specification.
The wording "has supported" should be sufficient.
If this is not specification then doesn't that imply that any provider of
On Fri, 12 Feb 2021 15:22:15 GMT, Roger Riggs wrote:
>
>
> The table is informative and should not be construed as specification.
> The wording "has supported" should be sufficient.
If this is not specification then doesn't that imply that any provider of any
version of OpenJDK would be free
On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote:
>> Marked as reviewed by kvn (Reviewer).
>
> Have you run the JFR tests in test/jdk/jdk/jfr?
@marschall Please do not force-push anything as it breaks the commit history in
the PR and renders previous
reviews/comments obsolete. There is no wa
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 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 Mon, 7 Sep 2020 09:44:09 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 `@since` from
Hi Philippe,
On 8/09/2020 3:08 am, Philippe Marschall wrote:
Hello, newbie here
Welcome aboard!
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 8/11/2013 8:13 PM, Patrick Zhang wrote:
Hi Alan,
I have created https://bugs.openjdk.java.net/browse/JDK-8028044 to hold it.
My understanding is that 8019502 was originally covering this issue for
a broad range of tests across different areas. They were then split out
into different CRs f
ional localedata.jar so tests
that require it need to be identified. This change might alter the list
of tests. But that isn't your concern.
Thanks,
David
Naoto
On 9/8/13 7:47 PM, David Holmes wrote:
Hi Naoto,
On 7/09/2013 5:01 AM, Naoto Sato wrote:
Hello,
Please review the fix for the fol
Hi Naoto,
On 7/09/2013 5:01 AM, Naoto Sato wrote:
Hello,
Please review the fix for the following bug. At the moment, it's not yet
reflected in the bug database, but the symptom is that
sun.util.resources.en package is split between rt.jar and
localedata.jar, which would make it problematic in J
Ni Naoto,
Where will this be pushed to initially?
It is a big set of changes, albeit localized (no pun intended :) ), so
it would be good to see this get some bake time before propagating up.
Further we're just about to have a "flag day" between hotspot and JDK
due to JSR292 changes, so it wo
On 5/11/2011 5:39 AM, Alan Bateman wrote:
On 04/11/2011 12:03, Heiko Wagner wrote:
Hi Tom, thanks for your reply. I am using JNI in a different,propably
never
designed to be used that way, kind of scenario. I use JNI to bring
Java to a
legacy Smalltalk based product[1].
The Smalltalk code does
So the jtreg uncaughtException code is doing a join() on the target
Thread while holding the monitor lock of the ThreadGroup - ouch! Where
do we file jtreg bugs?
David
On 11/10/2011 1:44 AM, Chris Hegarty wrote:
On 10/10/2011 15:52, Alan Bateman wrote:
Chris Hegarty wrote:
Naoto,
Forgot to
, David Holmes wrote:
Hi Naoto,
This looks okay to me, but is missing the change to make
availableJRELocales volatile (which is needed to ensure safe publication)
David
On 8/10/2011 4:40 AM, Naoto Sato wrote:
OK here is the proposed fix (including David's suggestion for using
putIfAbsent)
On 10/6/11 2:59 PM, Naoto Sato wrote:
Hi David,
Thank you for the quick look and the fix!
Naoto
On 10/6/11 10:09 AM, David Holmes wrote:
Hi Chris,
Thanks. Here's the bug:
private List getJRELocales() {
if (availableJRELocales == null) {
synchronized (LocaleServiceProviderPool.class) {
i
elationship. Or maybe I've gotten this wrong? His
is quite bizarre, or maybe it is just the overly complicated use of
locking/DCL in this class.
-Chris.
On 10/ 5/11 07:01 PM, David Holmes wrote:
This might not be related to the CME problem, but here:
public static LocaleServiceProviderPool g
This might not be related to the CME problem, but here:
public static LocaleServiceProviderPool getPool(ClassLocaleServiceProvider> providerClass) {
LocaleServiceProviderPool pool = poolOfPools.get(providerClass);
if (pool == null) {
LocaleServiceProviderPool newP
On 6/10/2011 2:58 AM, Alan Bateman wrote:
Chris Hegarty wrote:
Alan, Naoto, David
I filed CR 7098100: java/util/Locale/Bug6989440.java fails
intermittently.
If you're ok with it please review the patch (below) and I can push it
to the tl repo. Job done!
I assume there is also some underlying
Thanks Chris and Alan.
On 4/10/2011 11:24 PM, Alan Bateman wrote:
Chris Hegarty wrote:
Trivially, should the main thread in the test be waiting on the three
other threads to complete before exiting?
I think jtreg will try to cleanup once the main thread completes. The
main thread should keep a
he test be run on a machine with more than one
processor, it just will not reproduce on a machine without multiple processors
Sent from my iPhone
On Oct 3, 2011, at 14:25, David Holmes wrote:
On 4/10/2011 3:53 AM, Naoto Sato wrote:
Discussed in the CR 7027061. Never been able to reproduce ou
On 4/10/2011 3:53 AM, Naoto Sato wrote:
Discussed in the CR 7027061. Never been able to reproduce outside the
JPRT system, and it's difficult to investigate such issue without
reproducing it.
This error message is coming from jtreg:
ACTION: main -- Error. Error while cleaning up threads after
26 matches
Mail list logo
