Some views from a programmer [3/3: annexes]

[Daniel Latrémolière]

      Annexe: automatic inlining of adaptor for upgrading a dependency
      module to newer version

Needed API for inlining would include an annotation @Inline giving hints 
in adaptor code for good inlining and avoiding to make unreadable 
customer's code, by example:

    * @Inline(ALWAYS) for simple methods like delegates created for
      method renaming, for singleton classes, for simple classes with
      only one field with the same access rights or zero field and one
      extends.
    * @Inline(IF_ONE_CALL) for a more complex method or class.
    * @PreExecute(IF_ARGUMENTS_STATICALLLY_KNOWN) if static method with
      one "switch" or multiple "if" for replacing an int constant by a
      new enumeration item or enumset; etc.).

This will probably need one or two others annotations than @Inline with 
an enumeration giving cases and @PreExecute. I am trying to make a more 
complex test for searching if others annotations can be useful (when 
user code send objects to the library for listening events). Nothing 
will forbid developer to use this in his own code for asking IDE to make 
a big pack of refactorings (probably more efficient when using 
pre-execution) in only one step. Pre-execution can probably be useful 
for reading and/or storing some files in the updated source (like 
modifying JPA descriptors or others XML used and defined by libraries).


      Annexe: smooth module replacement protocol

A simple and probably useful solution for replacing a living module is 
to remove all modules using the module to be replaced. It will probably 
create a smaller loss of quality of service than fully restarting the 
application, but it is only a part of the solution.

The real problem is replacing a living module smoothly without partial 
restart. I think it is too complex for current state of normalization 
(no real experiences). The only interest in this part of study is to 
allow this future possibility (search possible requirements), when there 
will be some uses (probably useful but no big immediate need for it, 
because this does not currently is an allowed possibility).

Given the infinite possibilities of module evolution, this concept need 
to allow object modification (some sort of Meta-Object Protocol) which 
is complex. My only clean solution is to add to the method, to be called 
for replacing lively a module by one or multiple others modules (like 
new module and adaptor), a parameter with the object who will be 
responsible of converting instances.

When the module replacement is asked, the VM tags all classes and 
instances of the module as being frozen and block all threads at the 
beginning of the module object used. When a thread use a frozen object, 
the corresponding object is send to the converter to be updated. The 
converter make its work, converting any number of objects to new objects 
(for being coherent if number of objects change), and tell to the VM to 
replace all references on each old object with references on new object. 
The converter can, by example, in simple cases, use partial 
serialization of object. The converter can create new objects having 
reference on old objects for smoothing update of objects (this problem 
is very similar to real-time GC). When the VM know that all objects of a 
module has been removed, the module can be removed itself.

This protocol for smooth binary evolution is probably defective because 
I have not too much think to it. It is clearly out of current VM 
development (very complex with security, etc.), then I do not ask (now) 
for creation of API for hot replacing of a used module. A small step to 
this direction would be exposure of Java API for heap visiting 
(currently in JVM TI), with correct security rights respectfully to the 
module owner of objects. This would possibly allow others goodies like 
removing some memory leaks in Java. More explanations on this in the 
following annexe (not related to module).


      Annexe: Garbage Collector plugin

It could be useful to create a GC plug-in for visiting all objects in 
heap having references on a specific char[] instance (particularly 
String instance), determine used parts and compact the char[] replacing 
all objects having references by new objects on the new compacted 
char[]. This would remove an old memory leak between char[] and String 
needing special use of substring() and new String() in user code.

This problem is applicable to any type not only char[]/String and need 
to be processed to know the behaviour of all references owners. It is 
good for char[] instance if only used in String instances and not 
directly used in user's classes or with users registering to this GC 
plug-in a hook for declaring parts of char[] used and supporting moving 
to a new char[] with only some of the characters.

It is clear there is hopefully not too much memory leaks like this 
generating real world problems, but char[]/String is clearly known, and 
I think some big applications can possibly have a same problem of 
intra-object compaction and see usefulness of a future (not jdk7) API 
for GC plug-in.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090916/47c3223f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daniel_latremoliere.vcf
Type: text/x-vcard
Size: 199 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090916/47c3223f/attachment-0001.vcf>