[FFI] Remove PUSH_OBJECT_IN_SPECIAL_FRAME in the upcall dispatcher

[ChengJin01]

The idea is to store the argument objects in native to the java array rather to avoid
misusing PUSH_OBJECT_IN_SPECIAL_FRAME so as to stop GC from updating the
references before calling into the interpreter in upcall.

Fixes: #16410, #16422

Signed-off-by: ChengJin01 jincheng@ca.ibm.com

[ChengJin01]

As explained at #16410 (comment), PUSH_OBJECT_IN_SPECIAL_FRAME is removed everywhere given it is problematic to use this macro in our special situations in terms of multiple GC points during the memory allocation for struct/pointer/arguments after building the call-in frame.

To avoid any unexpected behavior with GC, we simly store the allocated struct/pointer objects to a java array (already created in java code in advance) instead and load them to the java stack prior to upcall.

The changes were verified on all supported platforms.

Reviewer: @gacholio, @tajila
FYI: @pshipton, @dmitripivkine

[ChengJin01]

A session specific test failure was detected in one of Jtreg test suites. I will need to double-check the code to see whether something was modified incorrectly for the session.

test LibraryLookupTest.testLoadLibrarySharedClosed(): failure
java.lang.AssertionError: expected [true] but found [false]
        at org.testng.Assert.fail(Assert.java:99)
        at org.testng.Assert.failNotEquals(Assert.java:1037)
        at org.testng.Assert.assertTrue(Assert.java:45)
        at org.testng.Assert.assertTrue(Assert.java:55)
        at LibraryLookupTest.testLoadLibrarySharedClosed(LibraryLookupTest.java:144)

[ChengJin01]

I went through the code with session in the PR and didn't find anything incorrect in dealing with session.

The reason for the failing test LibraryLookupTest.testLoadLibrarySharedClosed at #16427 (comment) is that it is supposed to complete at a fixed max time at https://github.com/ibmruntimes/openj9-openjdk-jdk19/blob/master/test/jdk/java/foreign/LibraryLookupTest.java#L144

void testLoadLibrarySharedClosed() throws Throwable {
...
        accessExecutor.shutdown();
        assertTrue(accessExecutor.awaitTermination(MAX_EXECUTOR_WAIT_SECONDS, TimeUnit.SECONDS)); <---------
    }

in which case exceeding the max time leads to failure. That being said, the explicit GC calls (especially the global GC) delayed the normal execution of test case (and also disturbed other time -sensitive tests). So these tests passed by simply disabling the global GC call; otherwise, I didn't spot anything wrong/abnormal in tests in terms of stack walker due to the explicit GC calls except that it took much longer in execution.

[gacholio]

jenkins test sanity zlinux jdk19