Conflicts exist if move to jdk14

[Man Cao]

Update: I'm in the process of rebasing/merging to JDK tip on the TSAN repo
on github <https://github.com/openjdk/tsan>.
My first step is to merge till this commit
<https://github.com/openjdk/tsan/commit/952f32e3755f385315e67de454eeba7a20e2f8a1>,
because there is a later change for
https://bugs.openjdk.java.net/browse/JDK-8239450 that introduced a whole
lot of conflicts with TSAN's make rules.
I prefer dealing with those make-rule conflicts separately later.

Currently I resolved all conflicts and it can build with fastdebug.
However, there are a few test failures under fastdebug. Particularly
NonRacyGarbageCollectionLoopTest.java triggers an assertion failure:
#  Internal Error
(/usr/local/google/home/manc/ws/tsanGit/src/hotspot/share/tsan/tsanOopMap.cpp:157),
pid=70844, tid=70861
#  assert(s == bucket->get_oop_size()) failed: same oop should have same
size

I'm working on fixing the failures.

-Man


On Tue, Mar 31, 2020 at 11:52 PM Jie He <Jie.He at arm.com> wrote:

> Yes, it’s better if you can do that. As you said, I have no permission.
>
>
>
> I tried the rebase just for knowing how much risk here.
>
>
>
> *From:* Man Cao <manc at google.com>
> *Sent:* Wednesday, April 1, 2020 2:40 AM
> *To:* tsan-dev at openjdk.java.net
> *Cc:* nd <nd at arm.com>; Arthur Eubanks <aeubanks at google.com>; Jie He <
> Jie.He at arm.com>
> *Subject:* Re: Conflicts exist if move to jdk14
>
>
>
> I also looked at how other projects (portola and shenandoah) handle this.
>
> Unlike tsan and loom, which maintain separate development branches,
> both portola and shenandoah just maintain a single "default" branch. They
> also have separate repositories for JDK11, JDK12, etc.
>
> They also do regular "Merge" commits to sync with jdk/jdk in the master
> development repository.
>
> So I think we should go with "hg merge". Mercurial should be able to
> differentiate commits between the tsan and jdk/jdk. The "tsan" branch in
> our repository would help separate out the changes further.
>
>
>
> I guess the main problem with "hg rebase" is that it generates a whole new
> set of changeset IDs (hashes). We don't want to change the IDs for
> changesets that have already been pushed.
>
>
>
> Any more concerns before I try a merge with jdk14-ga?
>
>
> -Man
>