id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
20,Method call on a local server is too slow,Bernhard Haumacher (haui at haumacher dot de),,"In KaRMI already exists a shortcut for a method call where the server object lives in the same address space. In comparison to a standard Java method invocation it is from 600 up to 1700 times slower (with JIT). This is because of the interface hierarchy that has to be tunneled through and the parameter duplication to simulate the remote semantics.
=== Solution ===
Most methods have only parameters and return values of basic type, so they can be called directly from the stub. Therefore we need a shortcut Stub->Server in case the references are SingleRemoteClientRef->UnicastRemoteServerRef pairs and the server is local to the stub.
=== Solution ===
Handling of parameter and return types:  * boolean, byte, char, int, float, long, double can be passed by value without marshaling and unmarshaling.
 * String objects are immutable, therefore they do not need to be copied. They can be passed by reference.
 * Objects that implement the uka.lang.Immutable interface are declared to be immutable by the programmer and can be passed by reference, too.
 * Parameters that are declared of a type that '''extends''' the remote interface uka.karmi.Remote are either stubs or remote server objects '''at runtime'''. Stubs can be passed by reference because they are immutable, remote servers have to be converted to a stub pointing to the local server object to simulate the remote method call behavior.
 * All other objects have to be costly copied.

'''partially-fixed''' since 1.02a.[[br]]
Add a new instance variable ""Remote server"" to uka.karmi.server.RemoteStub that points to a local server implementation if the combination SingleRemoteClientRef->UnicastRemoteServerRef is available.

declare ""RemoteClientRef remoteClientRef"" protected to detect all usages of this field within KaRMI. The protected access modifier ensures that the generated stubs can further on access/read that field directly. Declare get and set methods in RemoteStub for remoteClientRef. The set method can be used to update the shortcut reference. Modify all direct usages of remoteClientRef in KaRMI to the appropriate access method.

'''partially-fixed''' since 1.02b.[[br]]
Modify the generated stubs to make use of the shortcut. For example for class XXX, a stub XXX_KStub is generated. Before the modification for a method XXX_intf mmm() in XXX, the following method within the stub was generated:
{{{
public XXX_intf mmm() throws uka.karmi.RemoteException {
  try {
    return (XXX_intf) remoteClientRef.applicationCallObject(0, null);
  } catch (...) {
    ...
  }
}
}}}
After the modification, the following method should be generated:
{{{
public XXX_intf mmm() throws uka.karmi.RemoteException {
  try {
    if (remoteServer != null) {
      return (XXX_intf) uka.karmi.ExportPoint.toStub(
        ((XXX) remoteServer).mmm() );
    } else {
      return (XXX_intf) remoteClientRef.applicationCallObject(0, null);
    }
  } catch (...) {
    ...
  }
}
}}}

Parameters and return values are handled according to their types:
 * boolean, byte, char, int, float, long, double are passed by value
 * String and uka.lang.Immutable are passed by reference
 * parameters of interface type that extends uka.karmi.Remote are converted with uka.karmi.ExportPoint.toStub(.)
 * all other objects are duplicated.

'''partially-fixed''' since 1.02c.[[br]]
The JavaParty transformation makes the methods of all objects aware of object migration without distinction whether the object can migrate or not. But having the option to migrate a remote object incurs a large overhead of counting the number of methods actually running on a remote object. If the programmer declares a class to be resident by implementing the jp.lang.Resident interface the administration overhead can be saved for objects of this class.

'''fixed''' since 1.02c.
",defect,closed,normal,1.02c,uka.karmi,,normal,fixed,,