Libraries

[Andreas Arff]

Hi to everybody.

(> is Michael and > > is Dennis and > > > is Michael again)

Even though Dennis is taking a "pause" to collect our ideas into a working
doc. we don't have to stop the discussion. My mailbox was almost empty this
morning :-).
> >
> > > Hi!
> > >
> > > I think that having the seperate concepts of module, library and object
> > > is overkill. Can't we merge these into a single concept and simplify life?
> > >
> > > Michael
> >
> > I think the reason I came up with these concepts in the first place had to
> > deal with what was being loaded into memory at one time.  Objects tend to be
> > small, and if they were each loaded seperately, linking would be hell and
> > take up lots of overhead.  The concept of a module is to put into a single
> > unit a group of related objects *and* functions *and* data (not just objects).
>
> You mean we're having data that is NOT encapsulated in objects? My god,
> what will he come up with next? Blasphemy! :-) :-)

Not only data, functions too!!! :-)

> Seriously though, if the only reason for separarting objects into libraries
> and modules is efficiency then we'd be better off (IMHO) to keep them as one
> concept and just take care to make the implementation efficient.

Yes, but I think it would be easier if we made it hierarchical. It is easier
to handle the concept then, but whether or not the implementation will
contain this hierachical system is something that has to be considered at
implementation time. Even though our code may be dirty (havn't we all reached
Tao:-), it doesn't mean that our documents have to be dirty :-)

> > I can't see doing away with the concept of a library - our system stuff itself
> > may need 20 to 30 modules, the GUI may need 10 or 20, and so on.  Combining
> > these into a library simplifies life on disk, so this is a concept important
>
> You're more or less assuming a comventional file-system that doesn't like
> small files -- this is not a good thing to assume automatically.

After all a disk is a disk. Even though your system equally "likes" large and
small files, it doesn't automatically mean that it will be equally efficient.
It is faster to load one large file (if it is contigous) with subfiles in it,
than 50 small files (spread over the disk).

> > to the filesystem only.  (A group of files within a file?)  If the *entire*
> > system library were loaded at run-time, we'd have the same problem as OS/2
> > and Windows - it would take tons of memory to run.  To load only those parts
> > necessary, libraries are broken into modules which can be loaded and linked
> > to at run-time of an application.  If an app runs and the module exists in
> > memory already, no load is necessary.  (Just like DLLs, just different names.)
> > Only those portions used by a program are loaded, at run-time.
>
> i think it's simpler just to have objects and to let the virtual memory system
> handle loading.

Well, are there any practical difference? I agree with Michaels way of doing
it though.

> Do you think this is unworkable from an efficiency view?

It depends on how much of the OS that is needed in the Memory at a time.
It should be possible to mark (at least) the kernel as a MEM_PHYSICAL block.


> > In this scheme, a program *is* a module with (in C terminology) a "main"
> > function to be called once the program is loaded.
> >
> > Again, if objects are loaded individually the overhead would be tremendous -
> > if the entire OS or GUI is put in a single module, memory usage would be
> > outrageous.
>
> Not with virtual memory.
Virtual memory won't simplifie the change of objects when we have made
improvements to parts of the OS, and want to exchange maybe two out of 50
objects.
Just another aspect of it.

Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--