On Fri, Apr 13, 2012 at 2:48 AM, Bennie Kloosteman <[email protected]>wrote:
> I think CIL is a improvement but to go further you are really talking > about re-use ( including team factors such as discovery) , versioning and > contracts and I ask is the problem of modularity at the lib / dll/code > level inherently flawed especially in a 8+ core world ? > > To me your statement sounds like classic naive futurism. My answer to your question is obviously "No! in-process dll-style code modularity will remain a critical type of modularity long into the future, because it's very very fast." 90% of our stack ( kernel<->driver and program<->shlib ) is based on in-process DLL/code-level modularity. Microkernels attempted to place the kernel<->driver interface out-of-process and have all since died for performance reasons. Deep program modularity is still handled with in-process extension (photoshop plugins, VBA, chrome-extensions, gimp plugins, emacs extensions, to name a few) > Consider Browsers - is the current plugin solution good ? The problem is > so bad that some browsers are going as far as having no plugins Apple and > IE11 Metro for example .. SOA services are the right idea if a bit > heavy and some advocates like Juval Lowey are even going as far as 1 class > = 1 service ( which i disagree with) , however SOA is constrained by > cross machine limitations . I also note Multi processing is moving to > message parsing "agent" libraries . > > There are many types of code-modularity. Designing modularity for a given situation depends on factors such as.... How rich is the data-interaction? What is the frequency of the interaction? What is the bandwidth of the interaction? What are the safety requirements of the boundary? Browsers are beginning to act as operating systems themselves. We shouldn't confuse "plug-ins" such as a full-panel PDF reader, which are really separate programs loaded within the browser, with "extensions" that require rich access to program data structures. For rich performance-dependnt code-modularity, such as program-extension and kernel<->driver boundaries: Solutions with GC pauses will not be used because pauses are unacceptable for a leveraged software stack. Out of process solutions will not be used because they are too slow. These are the situations where time-and-time-again we are using C-shlibs. This is not a small amount of our software stack, it's most of it. If you can deal with 15% what is wrong with a ref counting collector ? > There are advanced ones but even primitives ones can run a mark /sweep to > remove cycles when the programmer wants - eg levels loads , when there is > a dialog etc . > There is simply never a good time to incur a stop-the-world pause, so any solution which requires it will not succeed in replacing C and shlibs. Implementing a mark/sweep cycle finder without stop-the-world is the same challenge as GC without stop-the-world. Refcounting+AzulC4-style no-stop cycle finding is entirely acceptable. The reason pauses are unacceptable in our leveraged software stack is in some sense an economical one. In software technology businesses, software engineering costs generally don't scale with profits. --> Which means in very-popular or very-profitable software there is no reason to compromise user-experience for coding-efficiency. <-- If it makes the customer-experience better (i.e. no pauses), economics and game-theory will dictate us rewrite it all in assembler if it's necessary (which is basically what C is, and basically what we are doing). This economic basis is why pausing-GC-systems are only viable for the top of our stack.... Lower-volume solutions such as scripting, business specific customization, low-volume apps, low-volume webservers, and top-of-stack programs where authors don't realize the pauses are problem until later (like webservers). High-volume software must be pause free because customers would choose a non-pausing alternative otherwise. As a result, it's written in C/C++/Obj-C with no pausing-GC. This includes system software on Windows, Mac, Linux, Win7Phone, iOS, plus all major applications (word, photoshop, Firefox, Chrome, Safari, Apache, IIS, MySQL, MS-SQL, etc. etc.) > Is interesting that C4 does incur significant pauses for small ( 4G) > heaps (obviously for the current thread) > By my read of the paper, this wasn't because of a small heap, this was because of the ration of used-space to free-space. (i.e. when there is memory pressure, there is a chance that allocation catches up-to-reclamation, and then there is a pause. Note that malloc/free could deadlock in such a situation because of fragmenting and lack of compacting) > There needs to be something done buts its difficult , the problem has >> been around for a long time.. many solutions and attempts have been made , >> many languages were written to address the modularity concept but they >> dont really get there., >> > If it's so difficult, then why has such a simple system (the C-shib) solved this problem so well and for so long? I think the "difficult" part about building a better system is avoiding the classic v2.0 problem of throwing out the critical requirements of v1.0. We need to admit the requirements are zero-pause, and typed forward-upgradable in-process code-modularity. For as long as we think we can ignore these goals, we will watch 90% of our stack be written in C and wonder why. If we admit these two goals, we can design something which is the safe-and-strong-typed replacement for the C-shlib. Then we can write typesafe kernels, and typesafe system runtimes.. instead of coding in C. Will it fundamentally change software? Hard to say, but it will make us all a heck of alot more productive. I believe the path to this is zero-pause GC, combined with at least CIL-level support for structs/value-types, JIT, and possibly a constrained forward-compatible-upgradable polymorphic interface boundary for modules. There might be room for immutability and linear-types in some form of fast-safe message-passing without copying. I don't think it's really that "hard" to do zero-pause GC.. the technique Azul is using could have been written a decade ago. Nobody is working on this stuff, we're all too busy telling our selves the pauses are acceptable and scratching our heads about why everything is still written in C.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
