Re: [Jikesrvm-researchers] support at stack/variable level

[Avery M. <av...@av...>]

Not at all wanting to get into the fray (only will agree with Ian that the
current approach seems problematic), allow me to share some effort I have
put into potentially helping aid this situation.

Usual caveats apply: I make no presumption the community should/will adopt
these ideas (nor even presume everyone will agree these ideas are correct or
consistent with the goals of RVM); I am merely sharing ideas and techniques
reduced to code which have worked well for balancing the conflicting goals
of rapid development with necessity to mature RVM into a stable, reliable
component suitable for potential inclusion into sophisticated products which
demand high-reliability (admittedly not a historical goal of RVM).

> 2) Philosophy for the inclusion of patches is something that 
> effects those without commit privileges and those with them 
> not wanting to upset people. Currently the publications 
> demonstrate a lot of good Jikes RVM work, but this work isn't 
> feeding back into the VM - as you say we have a high bar for 
> the inclusion of patches. Myself, most patches I either put 
> in directly because they're "safe" or submit to the patch 
> tracker and they go in after some regression testing. Some 
> patches have taken a lot more work and others have fallen on 
> the floor until they can be resurrected.

At root, my supposition is this is a build/image issue. Hence my willingness
to chew through the nightmare of rewriting jconfigure--unraveling all sorts
of undocumented (and numerous obsolete) dependencies interwoven in the deep
parts of RVM and jconfigure.

Part of my build/boot effort is to merge and refine preprocessing and image
writing in such a manner that severable components can be flexibly
merged/removed in an automated fashion via ant. Technical details range from
making preprocessing a first-class primitive (including support for
non-destructive, in-place preprocessing at both SVN checkout and build
times) all the way to conditionally auto-generating the primordial list.

One derivative of this approach is the necessity to cleanly separate "core
VM" from "everything else", taking a truly minimalistic interpretation of
"core". From there, providing a "mixin"-style ant build system that takes
the minimalistic "core VM" and permits in-place building of any desired
mixin concoction. Examples of severability run the gamut:
including/excluding classically preprocessed components (OPT, adaptive, OSR,
etc), supporting differing classpath versions, supporting different OS
(including Windows), supporting differing OS models (e.g. booting on metal),
etc.

Two primary challenges lie herein:

* Defining and institutionalizing the minimalistic "core" (I have got it
down to ~ 200 classes; undoubtedly it can be cut down further, removing
obsolete code like broken object models);
* Identifying, hooking, and standardizing rules for tinkering with the core
chokepoints where changes must be made to support "everything else" (e.g.
which static class initializers to load in VM.finishBooting(), libdl issues,
etc);

With a clean set of ground rules for these "core chokepoints", the constant
thrashing and obsolescence of patches seems to go way down and much of the
low-level RVM undocumented mysteries are nicely subsumed into easily
configurable components (which themselves are now well-documented, hopefully
making their maintenance less painful).

All that said, I will defer additional functional description, instead
preferring to let my code speak for itself (and not wishing to bore anyone
with details).

End benefits which I have seen:

* Patches against anything but the "core VM" can be supported without
violating integrity of RVM stability (a crucial dependency for those of us
who fancy using RVM for non-academic purposes);
* Severable components can be included/excluded in build instantly (just
choose a different ant target to build) and with greater confidence they
won't hose everything else;
* New severable components can be added by changing XML build files;
* Automated regression tests can be extended automatically to rebuild/retest
severable components.

While certainly no panacea, I have found some value in this approach.

-a