Add j.l.Thread.setCurrentThread() inline & fast jni natives

[JasonFengJ9]

Add j.l.Thread.setCurrentThread() inline & fast jni natives.

related #15176

FYI @tajila

Signed-off-by: Jason Feng fengj@ca.ibm.com

[gacholio]

@amicic @dmitripivkine This is the first time we've modified the threadObject field of J9VMThread after initial creation. Are there any barriers required?

[gacholio]

Please add a comment describing why the liveness check can be omitted. I also want to hear back from the GC guys before merging - we're changing a thread root field from another thread, so there may be barrier implications.

[JasonFengJ9]

Please add a comment describing why the liveness check can be omitted

Missed the initial request for the comment, added it.

[amicic]

I don't think we need a barrier on (strong) roots mutation, even if they are done by another thread.

For some concurrent GCs, based on card dirtying barrier, like Concurrent Mark in Gencon and Concurrent Scavenge, we will rescan thread roots at the final STW phase and pick up those mutations.
For others, we will not rescan, like SATB (Snapshot-At-The-Beginning) based ones, but that's because roots are there to determine only the snapshot of live objects as seen at the start of GC and mutation of roots after initial scan are irrelevant (there are other mechanisms that maintain overall GC consistency, that care about heap object mutations and newly allocated objects)

[gacholio]

jenkins compile win jdknext

[gacholio]

14:57:00  jclse.def : error LNK2001: unresolved external symbol Java_java_lang_Thread_setCurrentThread

[gacholio]

exports.cmake need updating as well.

[JasonFengJ9]

exports.cmake need updating as well.

Fixed, please re-launch the PR build.

[gacholio]

jenkins compile win,xlinux jdknext

[gacholio]

jenkins compile zlinux jdk8