Bassem Elkarablieh is a Ph.D. student at the University of Texas at Austin. The subject of his thesis is ‘Assertion-based Repair of Complex Data Structures’ which is a pretty cool concept. I’m not sure if I would be all that comfortable with an application that implements it, but it is cool nonetheless.
- Normally, when an assertion fails your application terminates and you restart it duplicate and debug the problem. But what if you cannot terminate the app and debug it? Why you train it to repair itself of course!
- However, can we guarantee that just because the structure of the data is corrected that the state of the program is correct? Well, no. But it might be one that allows the system to continue without crashing. But do we want it to? I tend to think not as I cannot predict or trust the application from the repair point forward.
- As an implementation note, the developer needs to provide the underlying structure for the data rather than through discovery.
- Which leads to when do you call the magic structural integrity assert?
- In apps that need high reliably, every garbage collection
- Everywhere else, any time the system throws and exception might be a good determining heuristic
- The assertions describe what the structure should look like, repair routines describe how to fix it
- Apparently similar solutions are used currently inside IBM’s MVS and Lucent 5ESS switches
- Some pretty big gotchas:
- If the repair routine is complete, then the repair can be complete. but if there is a bug in the repair routine then your program might not crash, but you cannot trust it (not that you really can even if the repair was complete)
- If the data itself is corrupt as a result of the structural issues, you cannot repair it; only the structure
- Something for the future (and is being studied by a colleague of his) — automatically generating and inserting a fix based upon the repair action that was necessary
Direct link here.