Home » forums » LtU Forum

Programming languages for low level autonomic systems

A few quick definitions

Autonomic Systems - Systems that self-manage/repair and improve.

Agorics - A system based on the market forces generally with currency + bidding

I have been thinking about an agoric architecture for a while that can manage low-level resources, so that the system can adapt as much as possible to the problem at hand. I'm trying to emulate some of the flexibility of neural plasticity.

The sorts of things the programs within the system should be able to do

  • Given two garbage collectors in the system, they should be able to pick the one that least interferes with their important operations.
  • Similarly pick the best scheduler
  • Pick the best virtual memory manager
  • Cope with new instances of these low level systems (schedulers/GCs etc), and the removal of others it might have been relying on
  • Adjust the stack space assigned to it, if needed

This is as well as deciding which normal programs to interact with, etc.

So I need a language that allows the programmer to adjust all these strategies. Preferably a language that can also allows the programmer to ignore all these considerations and be as close to a normal language as possible (using default handlers for all these considerations).

Has there been any previous research about this sort of programming language? I had been thinking of an imperative C like language (perhaps taking a leaf from C--), with special functions a la main() that handle these sorts of things when the program is loaded into memory. I'm also interested in abstracting away as much as possible from the underlying architecture.

I have blog-in-making here for other discussions.

By Will Pearson at 2009-02-06 11:44 | LtU Forum | previous forum topic | next forum topic | other blogs | 5566 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Interesting Problem

This is quite an interesting problem. There has been interest in making programs less brittle, and more organic, in the languages community for a long-time. This was actually raised during the panel discussion at POPL as a future direction for research. Although I'm not familiar with his work, judging the comments in the panel you might want to look at Martin Rinard's work.

The problem that appears to be hardest in your outline is finding concrete definitions of "best" and "least interferes". There are many possible criteria for the best scheduler - most efficient, smallest, fairest etc. The appropriate notion of best will probably be program dependent. So one language-type problem is how to formulate what the program requires from the scheduler, and then finding a way to let the programmer express it.

Another issue is how to handle graceful degradation. Autonomic systems avoid hard failure, and instead degrade service as things go wrong. Just sticking with the scheduler issues, there is also the question of how can a programmer express which degradations are acceptable, and what is a ranking between them of desirability.

Going beyond what you have above (a post of yours on listbox comes up on Google) you might find some interesting reading on Fault Attacks in crypto. From what I've seen the analysis of Fault Attacks is still at an early stage in the crypto community because they are still in the process of wrestling with definition questions : What is a valid fault to inject into a running program? Your commments about low-level failures like memory corruption would indicate a similar type of analysis. Again the language problem would seem to be a way for the programmer to express some sort of fault model, and provide a desirability ranking between competing faults.

On the subject of Agorics I can give a more concrete pointer, which is the LSCITS project. They are very interested in using market-based techniques to provide reliability in large-scale systems. The project is run by Dave Cliff, the inventor of the zip algorithm used for market making. It sounds like your direction is very close to theirs, and they are always looking for collaborative partners.

By Andrew Moss at Thu, 2009-02-12 11:39 | login or register to post comments