Re: interactive development and code re-loading

[Per Bothner <per at bothner dot com>]

On 10/12/2015 12:42 AM, Helmut Eller wrote:
> I'm still wondering how a re-loadable version of define-simple-class
> could possibly work.

I think you can do a decent job as long as the super-classes (extended
classes and implemented interfaces) don't change.

The initial load creates a "skeleton class" with the specified super-classes.
All instances of the class are compiled to instances of the skeleton class.
The skeleton class doesn't change even if the source code is re-compiled.

Every method defined in the class is compiled to a static method in a helper
class.  The skeleton class has just a stub method that calls the static method
indirectly, for example using a MethodHandle.  If a method is changed, we create
a new static method and update the MethodHandle to point to it.

If the original class inherits a method, that is treated as an actual
method that calls the super method - i.e. we create a static method that
uses invokesuper to call the inherited method.  (There are some
limitations on invokesuper, especially for protected methods.)
That way you can add new overrides after the initial load.

Adding a completely new method after the skeleton class is created
is trickier.  If there are no sub-classes, we can just treat
the method as a static function.  If there are sub-classes, and
the method is overridden in a sub-class, it more complicated.
One solution is to use a switch based on a sub-class index.

Changing the signature (types) of a method is tricky - it may just
have to be treated as deleting a method and adding a method.

Calling a deleted method generally throws an exception.  In simple
cases if there is a new method with the same name and the same
number of parameters perhaps we can try to convert the methods instead.

Instance fields could be handled by translating them into pairs of
getter/setter methods.  Each field (including deleted fields)
has a unique integer index.   Each object has a helper array for the
value of the field.  We use a special unique object NO_SUCH_FIELD.
Reading a field indexes into the field array.  If the index
is out of bounds, or the value is NO_SUCH_FIELD we throw an
exception.  Writing a field updates the element of the field value
array (which is extended as needed).

This design maintains object identity, and handles binary compatibility
acceptably, I think.  It adds non-trivial overhead, but I suspect
less than many other JVM languages :-)

Renaming a method or a field can't be detected by Kawa.  However,
if the rename is done by an IDE, the IDE can notify Kawa of the
rename, and Kawa could automatically translate new names to old names.

Static methods and fields are essentially plain top-level functions and
variable definitions, which we should support before tackling classes.

I don't know when I'll have time to implement these ideas.
Re-loading class definitions should be handled after we have
handle function and variable re-definitions well.  Class re-loading
could be a good project for someone - possibly a Google Summer of
Code project for next year.  Or anyone who wants a non-trivial
but manageable project.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/