#39 Static cloning of library methods for application and VM contexts

[Michael Bond]

Since Jikes RVM is written in Java, the application and VM call into the same Java libraries. If you want to change only the application's behavior and not the VM's behavior, it's difficult to handle the libraries (i.e., to instrument/modify only libraries called by the application but not the VM). This patch clones library methods so that each library method has two versions: one called by the application and one called by the VM. Instrumenting/modifying only libraries called by the application is then as straightforward as checking which version of a library method is being compiled.

Attached is a patch against Jikes RVM 3.1.2 that provides this functionality. The patch also adds a README that provides more details: static-cloning/README-static-cloning.txt

[Michael Bond]

Also attaching a patch with two fixes to Jikes 3.1.2 that are environment sensitive (one related to gtk, the other to JDK 1.7). You might not need them (the gtk one in particular seems quite platform dependent).

Another fine option is to patch against a newer version of Jikes (currently 3.1.3 is the latest). I haven't tried that. If you do port the patch to a newer Jikes version, contributing it here would be appreciated.

[Quentin Sabah]

Hi, I am using this patch, many thanks!

But I just found a bug in OptLinker.resolveDynamicLink:

TableBasedDynamicLinker.resolveMember(bcodes.getMethodReference(), cm.method.getStaticContext());

should be replaced with:

TableBasedDynamicLinker.resolveMember(bcodes.getMethodReference(), realMethod.getStaticContext());

The current version leads to an infinite loop in the dynamic member resolving code when the RESOLVE_MEMBER instruction comes from an inlined method and the caller method is not in the same static context as the inlined callee.
The dynamic member resolving code generated in ConvertToLowLevelIR.resolveMember looks for the member offset into the offset table corresponding to the callee context. But OptLinker.resolveDynamicLink looks into the offset table corresponding to the caller context. Thus the slot in the callee context isn't updated with the member offset, and the dynamic member resolution code loops forever.

I'm also not sure about the current version of OptMachineCodeMap.getMethodForMCOffset, where the last instruction use the static context of the root method instead of the inlined callee's.

Regards.