On Mon, Sep 23, 2019 at 11:08 PM David Holmes
wrote:
> Except when I run it through our test system ReservedStackTest is still
> failing :(
>
> I tested it initially when Fred proposed it and that went fine. It also
> passes for me locally on Linux.
>
I committed the changes other than for
Frederic, could you figure out how to resolve
8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166
refresh
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ReservedStackTest/index.html
https://bugs.openjdk.java.net/browse/JDK-8231031
On Mon, Sep 23, 2019 at
Except when I run it through our test system ReservedStackTest is still
failing :(
I tested it initially when Fred proposed it and that went fine. It also
passes for me locally on Linux.
David
On 24/09/2019 12:20 pm, David Holmes wrote:
Hi Martin,
That all seems fine to me.
Thanks,
David
Hi Martin,
That all seems fine to me.
Thanks,
David
On 24/09/2019 3:43 am, Martin Buchholz wrote:
We now have a fix-up integration that removes all the previously
excluded tests from their exclude lists.
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
We now have a fix-up integration that removes all the previously excluded
tests from their exclude lists.
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
8231031: runtime/ReservedStack/ReservedStackTest.java fails after jsr166
refresh
Sorry about the breakage. In retrospect, this is one jsr166 integration
where we should have run more tests from other areas of the jdk.
Especially monitoring tests are sensitive to implementation changes in
j.u.c.locks.
(but we've never run nsk tests)
On Sun, Sep 15, 2019 at 3:14 PM David
Hi Martin,
These changes have caused a number of tests to break and wreaked havoc
in our CI system (as those tests get executed a lot in different
configs). The problem seems to be changes to stack use and contents:
-
Thank you!
On Fri, Sep 13, 2019 at 9:44 AM wrote:
>
> Android (d8 in fact) is able to desugar private access with nestmates
> since last April,
> your latest backport target 9 which is not supported anymore, so when you
> will move the backport to support Java 11,
> this tool can become handy.
- Mail original -
> De: "Doug Lea"
> À: "Remi Forax" , "Martin Buchholz"
> Cc: "core-libs-dev" , "loom-dev"
> , "David Holmes"
>
> Envoyé: Vendredi 13 Septembre 2019 17:19:21
> Objet: Re: RFR: jsr166 integ
quot;Martin Buchholz"
> *À: *"Remi Forax"
> *Cc: *"core-libs-dev" , "loom-dev"
> , "David Holmes"
> , "Doug Lea"
> *Envoyé: *Jeudi 12 Septembre 2019 16:20:12
> *Objet: *Re: RFR: jsr166 integration 201
> De: "Martin Buchholz"
> À: "Remi Forax"
> Cc: "core-libs-dev" , "loom-dev"
> , "David Holmes" , "Doug
> Lea"
> Envoyé: Jeudi 12 Septembre 2019 16:20:12
> Objet: Re: RFR: jsr166 integration 2019-09
> On Thu, S
On Thu, Sep 12, 2019 at 1:48 AM Remi Forax wrote:
> This remember me something,
> we should refactor most of the the package-private final methods (and the
> corresponding constructors) at least inside java.lang/java.util to make
> them private, there is no need to make them package-private
attributes instead of generating the method
access$XXX.
Maybe i should write a bytecode analyzer for that ?
Rémi
- Mail original -
> De: "Martin Buchholz"
> À: "core-libs-dev" , "loom-dev"
> , "David Holmes"
>
> Envoyé: Lundi 9 S
On 09/09/2019 16:06, Martin Buchholz wrote:
:
Another round of stress testing at Google allowed us to fix a handful of
very rare test failures.
8227235: rare failures in testForkHelpQuiesce tck tests
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/ForkJoin-quiesce/index.html
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
8229442: AQS and lock classes refresh
https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/lock-classes-refresh/index.html
https://bugs.openjdk.java.net/browse/JDK-8229442
Lock classes refresh is a
15 matches
Mail list logo
