Remove Fast_java_lang_System_arraycopy

[ehrenjulzert]

Fast_java_lang_System_arraycopy is dead code,
as it is no longer called anywhere

[ehrenjulzert]

@tajila Do you know if there's a reason FastJNI_java_lang_System.cpp exists? It doesn't even get compiled when I compile j9 normally, since it disables itself right at the start with #undef FAST_JNI_ARRAYCOPY

[tajila]

are currentmillis and nanotime still used?

[tajila]

@gacholio may know why FAST_JNI_ARRAYCOPY is undefined

[pshipton]

The #undef was added by GAC in 2013 by
39436: More Fast JNI implementations - clean up code and implement Throwable.fillInStackTraceJ9VMInternals.getClassLoader, Array.newArrayImpl, String.intern, System.arraycopy (currently disabled due to JIT issue).

39436 is a Discussion item in RTC.

[ehrenjulzert]

are currentmillis and nanotime still used?

Good question, originally I thought they weren't used because there's different implementations in BytecodeInterpreter.hpp, but I just realized that the other FastJNI_* files also have their functions implemented elsewhere. When are the fast versions used?

[gacholio]

When are the fast versions used?

The fast versions are used by jitted code, not by the interpreter/VM. The System natives are referenced here:

openj9/runtime/vm/FastJNI.cpp

Line 42 in 732bff2

J9_FAST_JNI_METHOD_TABLE_EXTERN(java_lang_System);

openj9/runtime/vm/FastJNI.cpp

Line 57 in 732bff2

J9_FAST_JNI_CLASS("java/lang/System", java_lang_System)

[gacholio]

I do not recall what the issue with arraycopy was/is. It's possible these natives are not necessary as the JIT has custom inlined verisons of them, but we would need to prove that with performance measurements across the platforms.

I think this item should be closed with no action taken.

[ehrenjulzert]

The main reason I brought this up was because I'm editing System.arraycopy in #17048, and I figured that if one arrayCopy implementation is changed then Fast_java_lang_System_arraycopy should also either be updated or removed completely. I could also just not do anything to Fast_java_lang_System_arraycopy, but it seems like that could be a bad idea since it leaves it in kind of an unusable state and doesn't make it obvious that it's out of date. Which option do you think makes the most sense?

[gacholio]

The fast version has been disabled going on 10 years now, so I'm fine with removing it - it would be simple enough to reimplement it if a need arises later.

[ehrenjulzert]

Okay, I'll update this PR to just remove Fast_java_lang_System_arraycopy and keep the other functions.

[ehrenjulzert]

Okay, only Fast_java_lang_System_arraycopy is removed now

[gacholio]

Please update the PR description.

[gacholio]

jenkins test sanity zlinux jdk19