Back from ASPIC'2000Back from ASPIC'2000François-René Rideau France Telecom R&D - DTL - ASR 38-40 rue du Général-Leclerc 92794 Issy-les-Moulineaux Cedex 9 FRANCEHere is my report about ASPIC'2000that took place on Monday 2000-04-03.This report is based on the notes I took and my recollections,but it is full of gaps.Although other attendants proof-read it,this account forcibly reflects my own point of view and interests,with some discussions being stressed while others were elided or forgotten.I made no attempt at preserving the chronological order of the talks,and instead tried to group things together by themes.On the other hand, I also tried to expand and explaina few things that were said but not otherwise discussedsince the participants seemed to be in phase.As a result, this report contains both more and lessthan was said during the symposium.IntroPliantis a computing system based on dynamic compilation infrastructuredriven by a reflective language.It took 15 years of efforts for its original author, Hubert Tonneau,before the initial concept and the first usable implementation,as exists today.The peopleASPIC began around 10 o'clock.There were 12 participants on this first edition.Since all were french-speaking,french was used as the language for the symposium.Since there were so few people, all with converging interests,the atmosphere was very relaxed.From Heliosam, there were Hubert Tonneau (HT), Loïc Dumas (LD) and Jean-Michel Tonneau.From the CAMS, Patrice Ossona de Mendez (POM), Pierre Rosensthiel and Hubert de Fraysseix.From Croissancenet, there were Jérôme Jubelin (JJ), Gilles Grandon.Were also present Michel de Mendez (MM), Yvan Gaudin (YG), Michel Deza and,of course, from FTR&D DTL ASR, there was yours truly.Heliosam is a company that does "heliogravure",but has plans to provide documentation and maybe also training around Pliantfor individuals or companies that plan to start contributions.HT explained that for Heliosam, Pliant was the wayto achieve cutting-edge computerization of its services at affordable price.LD explained that he became a webmaster and programmer at Heliosam using Pliantdespite having little previous experience, and how the Pliant .page formatallowed him to do now on the server side what CSS promised to bring to HTMLbrowsers, with his creating style files from HTML produced by a WYSIWYG tool(such as WebExpert, that produces code 5 times smaller than FrontPage).POM explained that the CAMS was planning to use Pliantas the language for reimplementing their graph manipulation tools.A true object implementation of these toolswould lead to a huge horror of C++ messthat grew exponentially in complexity with the number of independentgraph properties studiedand hence, the actual C++ version is losely object orientedand has to check properties at run-time,whereas reflection would allowan efficient true object programmation in Pliant(of complexity linear in terms of the number of independent properties).JJ explained that Croissancenet is a startup specializedin collaborative workflow applications targeted at commercial departments,consulting, implementation of secured extranets and intranets.JJ has 10 years of experience in the targeted businessand wants to use it to adapt today's tools according to it.Their main current tools are Lotus Domino and HTML.They intend to invest in Pliant as a wayto federate and integrate together existing services.Its reflective architecture is expected to simplify the workof developers as well as that of service deployers and of end-users:the control it gives should enable to taylor system parametrizationso that even little qualified staff can deploy systems.FTR&D DTL ASR is interested in reflective techniquesto build flexible distributed systems,and I am investigating in the context of a PhD on reflective systems.Interfacing PliantPliant is a platform whose dynamic interface is the web,and is going to stay that way for quite some time,unless someone steps up to code a full-fledged interface.Netscape, whether on Windows, MacOS, or Linux,is the browser of choice to interface Pliant,and the way currently investigated to enhance the Pliantinterfacing experience is by developing a Netscape plugin(someone proposed to write the plugin portably in java).On the security front,HT has ported to Pliant a few well know algorithms such as RSA and Blowfish,and the overall functionality is currently reduced to thatof a proxy for communication between a Web browser and a Pliant server.However, it seems that the way to go for secure browsing is SSL,so this feature might be temporary, until Pliant groks SSL.Another problem with encryption is that it may not be legalto export it from France,so that unless we choose to link to some standard external library (openssl),a full Pliant reimplementation of SSL would have to be written and publishedfrom Germany, Canada, or another such free country.The real plans for the plugin, however,are to enhance the browser interaction with something along the lines of VNC,with rectangles of Pliant interaction being inserted along the passive HTML(rather than doing fullscreen/fullwindow VNC).HT talked about his experience about configuring and fixing remote computerwith either X or VNC on 64kbps lines, with VNC being much better.VNC looked to him as the right protocol (or kind of protocol) to use/copy.Another proposed solutions to enhance interaction with Pliant through web pageswas to insert a collection of Javascript hacks, but it seemed that thiswould be a lot of ugly and complex things with limited power.The main advantage of web-browser based solutions is that they don't requirepeople to upgrade their client hosts to Linux, when they might need to accessservices that only have clients under Windows.[Maybe that'll change if WINE or Plex86 is successful enough]In the long run,it remains to see what capabilities will be included in Gecko/Mozilla,and what capabilities must be added to it with a plugin,so as to adapt Pliant interface developmentto what is expected to become the common browser.2001 is when this question will be raised.In any case, HTML won't become indefinitely complicated,be it only because of interoperability problemsraised by increasing complexity;the server, not the browser, is the place where to expect the intelligence.In the longer run, a real solution might be to builda real interface for Pliant, something like Emacs with Pliant inside.Concerns were about dependency upon Xlib and/or communicationwith the X server being a hell and introducing instability;a solution would be to split them into a separate process,and use a VNC-like solution as with the intended Pliant plugin.However, there seems to be no universal compromise in splitting tasksbetween client and server, and if tasks must be split,then the browser+plugin model is as good as another one.Suggested systems on top of which to build an X interface,or to inspire from, wereEfuns,DrScheme,Oberon (inspiration only).Miscellaneous:LD explained how dynamic documentation could be integratedwith the user interface so that beginners can easily learn as they doand do as they learn.HT suggested that one simple trick to learn programmingwas that a command line showed the equivalent command to type for every click;even on the web, some Javascript might do it, just like JS can handleDrag&Drop with VNC subwindows in HTML.POM said that 60% of his mistakes in Pliant are due to his mismanagingindentation when code was longer than one or two screenfulls,which brought on the problem of the utility and realizability ofan Emacs mode or web tool to manage indentation properly. Persistence with Pliant: a Tree-based Distributed Data ModelHT explained that he has quite some (bad) experiencewith the previous infosystem architecture at Heliosamusing relational databases.He shared his vision of how he intends to use Pliantin the new generation of this infosystem.To him, the relational database modelworks well with a centralized server,but doesn't scale to a distributed architecture.Relational Tables are not meant to be distributed.Now, only distribution allows high-availability for world-wide services.The model proposed by HT is to organize persistent data into a structural tree,a privileged one among those that cover the graph structure of the data.This tree can be much more easily distributed than tables;a straightforward way to implement it is as aas distributed hierarchical file system of XML files.The infosystem architect would selectthe granularity at which the system is split into files;typically, each customer, order, etc, would correspond to a file,that describes the attribute of said customer, order, etc.Division into files is made so as to facilitate distribution of service;at each moment, each file is somewhere on the distributed network of server;since customers are localized, having them match a file makes sense(in a typical infosystem).More generally, the datastructure tree is designedso as to facilitate the expected dataflow of the intended services.Such a model allows for localized synchronization between serverswith weak and affordable coherence constraints(e.g. file modifications need not be propagated immediately),unlike the relational model,that typically requires expensive strong coherence constraints(ouch about mirroring huge modified global tablesinstead of mirroring small modified local files).XML files can also be served as HTML files with hidden tags,so that the very same pages could be served both for human visualizationand for consumption by automated scripts.One advantage of the tree data model is thatmany services need not understand all parts of the tree,as long as they propagate them,whereas in the relational model,services typically need to be aware of all the tables fieldsbecause records are a fixed set of fields.However, Pliant's reflection is most useful here,in allowing automated marshalling and translationbetween internal data graphs or classical stucturesand external XML/whatever representation.And since this is dynamic compile-time reflection,this translation is both seamless and efficient,unlike what you get with other languages/systems.XML is by no means a perfect framework,but since it's standard and relatively simple, it looks like the way to go.HT thinks that there shouldn't be unnecessary multiplication of languages.The Pliant programming language for code, XML for data, that seems enough.Lots of domain-specific code and data languages could be devised,but it seems better to HT to embed them inside Pliant and XML,than to reinvent the wheel every time.A first working prototype by HT is meant to be deployedwithin three months at Heliosam.Note: there was no claim by HT about this model being original.Managing Distributed Systems with PliantHT and LD told that they managed a parkof heterogeneous Debian machines with Pliant,although the code is currently too specific to the setup at Heliosamto be published,but that they are working at documenting it enough to publish it.Their Pliant engine maintains a databaseof hardware available on each machine and of software to be deployed there.The Debian system makes it easy to save the state of a machine(list of installed packages, configuration files for each package),so that in the event that anything breaks,an older state can be easily recovered.Pliant, however, cannot go directly through the Debian package installation,since many Debian packages still assume an interactive session with thesystem administrator; instead, it must edit some Debian installation scriptsto replace the interactive questions with unconditional settings,depending on the machine database.A bug in Perl even prevented dpkg from being called from Pliant,otherwise some packages couldn't install their documentation (!?).According to HT, the Debian installation systemis a hell of a collection of perl monster scripts.To avoid the problems of such forced upgrades/downgrades,HT expressed the wish that the heart of Pliant stay asindependent as possible (at least at runtime) from any external software,although some advanced options might depend on such software.Someday, Pliant could be written entirely in Pliant,and be able to dump proper file headersto produce complete standalone executables.As for the Windows version, MM emitted the wish that it become a toolboxthat implement services removed from latest Windows releases(such as the FTP server).[Note from FRR:Together with a Linux kernel, it could even provide a "superuser" modeto remotely manage the installation/update/recovery of windows systems]There was quite some discussion about how to make Plianteasy to deploy on Windows machines with as little and simpleuser interaction as possible.Ideally, the automatic installation should decompress the Pliant installationthen start a Pliant web server on a predefined or autodetected port,and open a browser with a configuration page served by the server;the server would then configure itself, restart, and put itself in autostart.No one volunteered to implement this wish feature.Some considered jokingly that no windows userwould consider Pliant a serious programunless it asked the user to reboot the machine after installation;a possible solution was to sell a enhanced commercial editionapart from the freeware edition, and that the commercial editionwould ask for reboot as a "plus" (or was it the contrary?).HT complained how difficult existing systems made it to upload a filefrom one system to the other.I asked HT how he intended running systems to detect updated filesand to handle synchronization.HT said that the current Pliant http server would cache pagesfor 15 unconditional seconds(the exact value can be changed usingthe 'dynamic_page_recheck_delay' option of the HTTP server),but check for an update in the sourcewhen a cache entry hit is older than that;however, this doesn't solve the case when modules used by an untouched pagehave themselves been updated. It would be too expensive for Pliantto track a precise dependency graph for every object, so that the currentsimple solution is to kill and restart the Pliant server when some meta codechanges.The Pliant Architecture: a System built atop a Code GeneratorHT said that Pliant was originally designed as a code generator,not as a reflective system.It just happened that the reflective architecture was achieved naturallyas the language and its code generator were developed one with the other.To HT, dynamic compilation is fundamental.Twisted kludges have been invented to partly compensatethe fact that compilation was purely static:DLLs, interpreters, option parsers, etc.But they are basically inflexible kluges,they only replace a tiny part of what dynamic compilation allows,they introduce a huge complexity in the system,and they induce a terrible performance penalty.For instance,if the Linux kernel had dynamic compilation,there could be only one kernel for everyone,yet it would run in an optimized way on each computer.Instead, Linux users currently have to recompile their kernelto get one that is fully adapted to their hardware,and it is a barrier to entry to the world of Linux.Another example was the CAMS's graph manipulation library,which in C++ would grow exponentiallywith the number of graph properties studied(in a fully object-oriented programmation),as a new class had to be generated for every combination of properties,whereas with Pliant, user-accessible methods were definedand optimization tactics were enabled depending on the properties verifiedby the considered graph.For managing applications as well as within applications,dynamic compilation is useful.So as to properly interact with their environment,programs need some knowledge of themselves (reflection).Code isn't only about being executed;sometimes, it is inspected by other code(for instance, code that will analyze other codeto implement marshalling/persistence/etc of its data).There is undeniably a cost to embed a compiler in a system.But the cost of not embedding the compiler in a system,although hidden, is very large, too:every programmer must then reinvent from scratchlimited minicompilers, option and configuration file parsers, etc,to interface each application with its environment.When you add up all the small costs paid by every single application,you end up with a much higher cost than in a system with dynamic compilation.HT reports that in a user space Linux kernel interface he read,the 50 lines of useful code is buried in 500 lines of parsing codethat serves to interface the external world.I suggested that Pliant could make use of external code generators,or code generation libraries(such as ccg),and maybe share efforts with other groups using them.HT replied that the low-level part of code generation (assembly) was fairly easy, although a bit long and very boring (a few hundreds of lines).whereas higher-level parts of code generationwere difficult to share in general,and preferably to be written in Pliant, anyway,so that little could be shared with other groups.However, he discussed of the tradeoffs concerninguse of external code generators, taking them as black boxesinstead of as open-coded collaboration projects.It is already possible to have Pliant dump C code that is piped into GCCand dynamically linked back into the Pliant runtime;this way, Pliant can take advantage of GCC's low-level optimizer;however, as far as low-level optimization goes,even C is limited by its clumsy calling conventions [Note from FRR: GCC accepts alternate parameter-passing conventionswith function attribute regparm(n)][Note from HT:this is what Pliant uses, but that's still not optimal,because you need to carry extra information that cannotbe deduced from the mere function prototype].Anyway, in traditional languages, compilers only optimize low-level aspects;that's also what an external code generator could bring.To HT, where Pliant shines is for its high-level code optimization,that are also the most interesting ones.Examples of simple high-level optimizationsthat are impossible in static languages includeprecompilation of dynamic pages into HTML generators(hence, no more runtime HTML generation, no more file copy,but direct memory mapping of HTML buffers),and preallocation of correctly-sized string buffers(hence no more dynamic allocation of a temporary string for eachstring concatenation operation).These can be done by walking the program at the right moment.I remarked that the whole interest of a reflective systemwas to take into account dynamically static invariants.Many people have shown how static compilation allowed totake advantage of static invariants to enable optimizations;dynamic compilation allows to take advantage of static invariantsthat only appear dynamically.By opening modules, etc,the programmer chooses which optimization tactics to use or not to use.As opposed to what happens in static systemswhere a set of optimization tactics comes bundled with the compiler,mostly without choice.It might be a good idea to look for optimization algorithmin academic literature and implement them in Pliant.One source of inspiration for high-level optimization isStalin.Pliant has no garbage collector (uses reference counting),but the standard environment is currently able to free every bytethat was allocated when it finishes.HT said that when a function is declared as dynamically modifiable,it might still be inlined and cross-optimized instead of called througha proxy, but that the system will remember which other functions use it,so as to update them when the shared function is modified.The Main Difficulty: RobustnessAccording to HT, there are essentially two difficult tasksin building a computer system:making the operating system robust even when heavily loaded,and making the highly optimizing code generator robusteven when stressed with unusual input.The problem with code generator robustness is correct handlingof registers and spilling, with arbitrary numbers of variables,and more generaly propagating properties in a way that is correctin all cases, even rare ones.Then, there is the algorithmic difficulty of achieving efficient results,while still preserving correctness, of course.The current Pliant code generator is seemingly and hopefully robust,but algorithmically very crude and doesn't optimize much.HT said that in a kernel like Linux, a local bug can stop the whole system.In Pliant, the core of the system is the language.HT is committed to maintain a strong coherence within the language,whereas applications needn't the same scrutiny. |
|
