>> >> 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.
Im not suggesting replacing dlls as a compilation module , they still have a roll eg a 3D maths lib but services which wrap a bunch of code have a lot of advantages as a reusable "module". I have seen a lot of issues with dlls as a reusable code base and associated dependencies and versioning. The key to doing it in services is breaking along paths of little communications. SOA systems are doing exactly that and I know many practitioners who go too far (IMHO) and use full SOA services ( with the whole Soap stack as seperate process ) within an application , some even go down to 1 class is 1 service . >Microkernels attempted to place the > kernel<->driver interface out-of-process and have all since died for > performance reasons. Answered below. >Deep program modularity is still handled with > in-process extension (photoshop plugins, VBA, chrome-extensions, gimp > plugins, emacs extensions, to name a few) Which is dying for reliability and security reasons no add ins in IE11 Metro and some of Apples stuff. ( Note they even tried the separate process model) . VBA had lots of issues with crashing and got replaced with .NET assembly which communicates to via COM. > >> >> 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 . > > 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. Yet browser have done exactly that - not out of choice but necessity ( reliability , security). The malware companies are now saying the scanning cost is on an exponential track with serious consequences for the current model. It doesnt matter if you call a browser an OS the problem is the same. Your comments about performance is important ( up to a point) though most software houses tend to write slow stuff cheaply , however security and reliability are import considerations also - if your critical program is compromised through an extension it can look bad on your business . Then again flash business sadly is not suffering ( i hope soon) but its slow and insecure. > > 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) Yes malloc can do this and have some bad pauses on the current thread. And yes lots of free space makes GCs pause a lot less. > >>> >>> 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? Do you think that system is flexible and extensible ? The first lib did it that way and most of the existing functions are still there 40 years later. > 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. I think our requirements should be stability , security and an option . 95% C performance with small pauses OR 85% with no pauses. The rest has been answered. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
