Class cornell.slk.jkernel.core.FastCopyContext
Source code
java.lang.Object
|
+----cornell.slk.jkernel.core.FastCopyContext
- public final class FastCopyContext
- extends java.lang.Object
A FastCopyContext object handles all argument copying
that takes place during a single switch from one task to
another.
An object may implement one or more of the interfaces FastCopyGraph,
FastCopyTree, and Serializable. If the object implements none of
these, then the copy results in a runtime error. Each object uses
only one of these three methods for copying. Either the object:
- Uses serialization to copy itself. Before copying,
serializing checks to see if the object was previously copied,
and if so, it does not copy the object again.
- Uses FastCopyTree to copy itself. The object will produce
a new copy of itself, regardless of whether it was copied before.
- Uses FastCopyGraph to copy itself. The object will check to
see if had already been copied, and if so, it will return
the previous copy rather than making a new copy.
Since only one of these methods can be used to copy a particular object,
why would any object ever implement more than one of these?
- An object might implement both Serializable and fast copy if it
wants to be fast copied by the J-Kernel, but serialized for other
reasons (such as communication through RMI to another machine).
- A subclass wants to override the approach taken by the superclass.
How well this works depends on whether the new approach advocated
by the subclass was already supported by the superclass. For
instance, the serialization spec says that it is ok to serialize
an object where the subclass implements Serializable even if
the superclass didn't implement Serializable - but in this case,
only the subclass fields are serialized. A similar rule makes
sense for fast copy - if an object is fast copied, only the fields
of those classes implementing FastCopyGraph or FastCopyTree
are actually copied.
So if a class implements both Serializable and one of the fast copy
interfaces, which should we pick? In order to enable the strategy
described by the first bullet point (using fast copy for J-Kernel
calls and serialization for other things), fast copy needs to take
precedence over serializability in J-Kernel calls. What about
FastCopyGraph vs. FastCopyTree? Only the second bullet applies
here (a subclass overriding the behavior of the superclass).
FastCopyGraph is safer (but slower) than FastCopyTree, so it makes
sense to allow a subclass to override the superclass to change
FastCopyTree to FastCopyGraph. So FastCopyGraph should take
precedence over FastCopyTree.
FastCopyGraph takes precedence over FastCopyTree, which takes precedence
over Serializable.
Strings and arrays are treated as special cases. They are copied
as if they implemented FastCopyTree, except for arrays of objects,
which are copied as if they implemented FastCopyGraph.
If the fields of an object are also objects, these rules are applied
again to determine how the object held in the field is copied. This
decision is made independently of how the outer object (that contains
the field) was copied, _except_: if the outer object was serialized,
the field must also be serialized, not fast copied. We don't have
much control over this.
| Methods inherited from class java.lang.Object
|
| , clone, equals, finalize, getClass, hashCode, notify, notifyAll, registerNatives, toString, wait, wait, wait |
tds
ThreadTaskState tds
fromTask
Task fromTask
classTable
RefSetCache classTable
copyTable
RefHashtable copyTable
serializer
DObjectCopier serializer
next
FastCopyContext next
FastCopyContext
FastCopyContext(ThreadTaskState tds,
Task fromTask,
Task toTask)
reset
public void reset(Task fromTask,
Task toTask)
add
public void add(java.lang.Object o,
java.lang.Object oCopy)
checkClass
private void checkClass(java.lang.Class c)
- If the class isn't in the cache (classTable), go through
the slower Task.getClass call to make sure the task can
find this class.
Note that because of a lack of synchronization,
classTable.containsKey may return false negatives.
This is ok.
copy
public java.lang.Object copy(java.lang.Object o) throws RemoteException
- Copy an arbitrary object. If the type of the object is known
at compile-time, it may be more efficient to use one of
the specialized copy methods, like copyString.
copyString
public java.lang.String copyString(java.lang.String s1)
copyByteArray
public byte[] copyByteArray(byte[] a1)
copyCharArray
public char[] copyCharArray(char[] a1)
copyIntArray
public int[] copyIntArray(int[] a1)
copyShortArray
public short[] copyShortArray(short[] a1)
copyBooleanArray
public boolean[] copyBooleanArray(boolean[] a1)
copyFloatArray
public float[] copyFloatArray(float[] a1)
copyLongArray
public long[] copyLongArray(long[] a1)
copyDoubleArray
public double[] copyDoubleArray(double[] a1)
copyObjectArray
public java.lang.Object[] copyObjectArray(java.lang.Object[] a1) throws RemoteException