Some views from a programmer [3/3: annexes]
daniel.latremoliere at gmail.com
Wed Sep 16 13:03:05 EDT 2009
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
* @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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 199 bytes
Desc: not available
More information about the jsr294-modularity-observer