On 10/19/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
> Sounds reasonable. And this solution joins mine and Pavel's proposals:
JIT
> calls a VM method to resolve native address for direct call. JIT does
not
I would also add that we can not use any Java-based resolution schemes
at all.
(Here I mean anything that implies execution of managed code during
compilation in order to resolve the things).
We already do. We resolve classes and it leads to the execution of user's
classloader Java code.
But JIT does not know about it: it just calls something like
'vm_resolve_class()' . The same could be done with native calls.
JIT could ask VM (vm_resolve_native_addr()) and do not care which algorithm
(Pavel'l or mine is used).
In this case we make no workarounds in JIT. All workarounds and temporary
solutions are fitted into the one method.
In order to think anything meaningful, it would be nice to see something
like a pseudo-code example. Something like a piece of Java code for the
helper.
Would you be so kind, please?
Let me presume several things - are you talking about anything like the
following?
//
// JIT side
//
ByteCodeTranslator::handleInvokeStatic() {
MethodDesc md = getMethodToInvoke();
ClassDesc klass = md.getClass();
if (klass.implements(NativeCallProvider) && /and what's here??/) {
if (klass.implements(NativeCallProvider) &&
vm_resolve_native_addr(md)!=NULL) {
// So, the VM is smart enough to find all the needed only by the name.
Right?
Yes. Find a given static method with bootstrap classloader
void* addr =
vm_get_special_native_method_address(md.get_fully_qualified_name())
insert_a_native_call(addr);
}
else {
proceed_as_usual_java_call();
}
}
The JIT side becomes simple, indeed.
What about the 'helper writer's' side?
What should be placed in the helper's Java code in order to make this
special call?
The helper writer must prepare his helper to work with a current VM.
The body of the helper is not changed, the only thing is changed is how to
report the address. Both variants require from a writer small amount of
code.
//
// Java side
//
package org.apache.hy.drvm.gc.helpers;
public class GCHelpers /*implements anything? */ {
/** it's fast path - will be inlined by JIT. */
private static Address fast_alloc(Address classHandle, int size) {
...
if (fast_path_succeeded) return allocated_address();
return perform_slow_path(classHandle, size);
}
/** it's slow path - implemented by gc.dll*/
// What's here? annotation? anything else?
private static Address perform_slow_path(Address classHandle, int size);
}
Yes, annotation that the method is native. The address of the method could
be retrieved by VM either using my or Pavel's solution
All,
I have a critical amount of changes. The first inlined helper is ready and
I'm testing it with different workloads.
The names of the slow-path helpers are hardcoded in JIT today - VM code is
not affected before we find an agreement on the final solution. And the
final solution should cover not only VM helpers but any native calls (or
assert that we do not want to support anything except helpers).
It's possible that my further work on the other helpers will open new
problems that will affect the final design.
So I'm going to put the patch into JIRA soon with workaround in JIT before
we find the solution.
Nobody minds?
--
Mikhail Fursov
