Conflicts exist if move to jdk14

Arthur Eubanks aeubanks at google.com
Tue Mar 31 16:49:01 UTC 2020


Glad to hear it!
Did you do a merge or a rebase? I'm wondering which one makes more sense.
It'd be nice to keep our patches separate from upstream's development,
meaning I'd prefer a rebase, but I'm not sure if that's feasible in the
long run?

On Mon, Mar 30, 2020 at 10:51 PM Jie He <Jie.He at arm.com> wrote:

> Actually, I have already workaround these conflicts,  now all 79 cases
> passed.
>
>
>
> *From:* Arthur Eubanks <aeubanks at google.com>
> *Sent:* Tuesday, March 31, 2020 12:22 AM
> *To:* Jie He <Jie.He at arm.com>
> *Cc:* tsan-dev at openjdk.java.net; nd <nd at arm.com>
> *Subject:* Re: Conflicts exist if move to jdk14
>
>
>
> If there are failing tests, we can deal with rebasing later. Applying
> patches on top of jdk/tsan should be fine.
>
>
>
> On Fri, Mar 27, 2020 at 1:29 AM Jie He <Jie.He at arm.com> wrote:
>
> Hi
>
> I had a quick try to rebase jdk/tsan to jdk14-ga, and found 2 major
> conflicts:
> 1, Shenandoah gc had a refactor last year, which implements a concurrent
> evacuation, seems it impacts current tsan oop map.
> 2, they limited non-gc to access the reserved region in gc, adding the
> function back to collectedHeap is a workround.
>
> In addition, a known build error exists in AARCH64 when building openjdk
> release version with clang 8. changing the -O3 to -Os or -O0 will be ok.
>
> An initial test shows 77 passed of total 79 tsan cases. The failed cases
> are NonRacyFinalizerLoopTest.java and
> tsan/NonRacyGarbageCollectionLoopTest.java.
>
> Thanks
> Jie He
>
>


More information about the tsan-dev mailing list