Stephen Fuld wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB5BEFA.8355ACC@deming-os.org...
>
> It isn't obvious, at least to me :-), that a garbage collected language will work for an operating system.  I know there has been much gnashing of teeth over Java's GC system among the people who want to use JAVA for embedded applications.  I don't know all of the details, but much of it revolves arount having the system decide to do GC at inopportune times, like when a response is required in reeal time to some external event.

Well, hopefully (for the existing code) Linux already does all of the memory allocation manually...so there never will be any leftover objects for the GC to cleanup.  However, I figure a port of Linux would require a custom (or modified) GC.  When somebody turns off interrupts, then you can disable the GC at the same time, or something like that...

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB750BE.21B151D7@deming-os.org...
> Stephen Fuld wrote:
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> > news:3CB5BEFA.8355ACC@deming-os.org...
> > It isn't obvious, at least to me :-), that a garbage collected language
will
> > work for an operating system.  I know there has been much gnashing of
teeth
> > over Java's GC system among the people who want to use JAVA for embedded applications.  I don't know all of the details, but much of it revolves arount having the system decide to do GC at inopportune times, like when
a
> > response is required in reeal time to some external event.
> Well, hopefully (for the existing code) Linux already does all of the
memory
> allocation manually...so there never will be any leftover objects for the
GC to
> cleanup.  However, I figure a port of Linux would require a custom (or
modified)
> GC.  When somebody turns off interrupts, then you can disable the GC at
the same
> time, or something like that...

It may not be obvious, but unlike Java, D does not force you to allocate objects using the garbage collector. You can revert to using the underlying C functions (which is what the GC implementation itself does for the tables). The linux kernel is written in C anyway, does not use class objects, and so would be readilly portable to D.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB50812.32369985@deming-os.org...
> Ok, another question...as I read the specs, unittest() sounded like it only was available as a member function of classes.  But adi.d has a bunch of them out at module level.  I presume that this means that all of them are run automatically as the unit test of the module.  If this is correct, the QA dept should have noted that in the spec ;-)
>
> --
> The Villagers are Online! http://villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>
>

"the QA dept should have noted that in the spec ;-)"


Fire 'em I say!

:)



--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a97nl1$2b4i$1@digitaldaemon.com...
> "the QA dept should have noted that in the spec ;-)"
> Fire 'em I say!

Good suggestion.
...
[lots of shouting and banging]
...
Ok, they're gone now.

"Walter" <walter@digitalmars.com> wrote in message news:a97juu$273c$1@digitaldaemon.com...
>
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CB750BE.21B151D7@deming-os.org...
> > Stephen Fuld wrote:
> > > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> > > news:3CB5BEFA.8355ACC@deming-os.org...
> > > It isn't obvious, at least to me :-), that a garbage collected
language
> will
> > > work for an operating system.  I know there has been much gnashing of
> teeth
> > > over Java's GC system among the people who want to use JAVA for
embedded
> > > applications.  I don't know all of the details, but much of it
revolves
> > > arount having the system decide to do GC at inopportune times, like
when
> a
> > > response is required in reeal time to some external event.
> > Well, hopefully (for the existing code) Linux already does all of the
> memory
> > allocation manually...so there never will be any leftover objects for
the
> GC to
> > cleanup.  However, I figure a port of Linux would require a custom (or
> modified)
> > GC.  When somebody turns off interrupts, then you can disable the GC at
> the same
> > time, or something like that...
>
> It may not be obvious, but unlike Java, D does not force you to allocate objects using the garbage collector. You can revert to using the
underlying
> C functions (which is what the GC implementation itself does for the tables). The linux kernel is written in C anyway, does not use class objects, and so would be readilly portable to D.


You're right!  It wasn't obvious, but it is interesting.  So, if I understand this correctly, you could port the Linux kernel, but if you wanted to do any enhancements that weren't just ports of the underlying C implementation, you would have to be a little carefull about what D constructs you used.  Is one assured that all of the D library one would need to link in conforms to the restrictions?  Would it make sense in some future release to add a compiler option that would enforce the restrictions and even mark the resutling output such that the GC wasn't even linked in if it wasn't needed?

So you would get some of the advantages of D, but not all of them and must exerise more than normal care.   Not a bad price to pay.  Thanks Walter.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a99prg$2acq$1@digitaldaemon.com...
> > It may not be obvious, but unlike Java, D does not force you to allocate objects using the garbage collector. You can revert to using the
> underlying
> > C functions (which is what the GC implementation itself does for the tables). The linux kernel is written in C anyway, does not use class objects, and so would be readilly portable to D.
> You're right!  It wasn't obvious, but it is interesting.  So, if I understand this correctly, you could port the Linux kernel, but if you wanted to do any enhancements that weren't just ports of the underlying C implementation, you would have to be a little carefull about what D constructs you used.

Correct. It wouldn't be a job for a novice, but then again, Linux kernel hacking is for experts anyway <g>.

> Is one assured that all of the D library one would
> need to link in conforms to the restrictions?  Would it make sense in some
> future release to add a compiler option that would enforce the
restrictions
> and even mark the resutling output such that the GC wasn't even linked in
if
> it wasn't needed?

The thing to do would be to create a special D library (note that the linux kernel uses its own C runtime library anyway, not the standard one, so this wouldn't be any travesty) that doesn't contain the GC.

> So you would get some of the advantages of D, but not all of them and must exerise more than normal care.   Not a bad price to pay.  Thanks Walter.

You're welcome. There are plenty of other benefits D can bring to the kernel, for example, versioning, elimination of the preprocessor, modular name spaces, unit testing, contracts, a MUCH better inline assembler <g>, etc.

"Walter" <walter@digitalmars.com> wrote in message news:a9clk6$1sfj$2@digitaldaemon.com...

> The thing to do would be to create a special D library (note that the
linux
> kernel uses its own C runtime library anyway, not the standard one, so
this
> wouldn't be any travesty) that doesn't contain the GC.

What about making the GC built into the kernel? Yes, an OS with built-in garbage collection memory allocation system!

API with contracts would be really nice as well.

I'm not convinced that GC in a kernel is a bad idea...provided you can turn it off, and you have enough smarts to not require memory cleanup during interrupt handlers and the like.

Also, kernel-side GC would have to run in supervisor mode, and we wouldn't want that to be a blocking, non-preemptible process, but Linux is moving toward preemptible kernel processes anyway.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a9cnvi$1v5a$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a9clk6$1sfj$2@digitaldaemon.com...
> > The thing to do would be to create a special D library (note that the
> linux
> > kernel uses its own C runtime library anyway, not the standard one, so
> this
> > wouldn't be any travesty) that doesn't contain the GC.
> What about making the GC built into the kernel? Yes, an OS with built-in
> garbage collection memory allocation system!
> API with contracts would be really nice as well.

I think GC would benefit if it was built in to the operating system's virtual paging system. I don't know enough about the kernel to know what kinds of issues there are with GC for the kernel itself.

Pavel Minayev wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:3CB5BEFA.8355ACC@deming-os.org...
> 
> 
>>Frankly, I'm excited about using D for all my applications...and
> 
> somebody's
> 
>>going to have start porting the Linux kernel over ;-)  (Pavel, you seem
> 
> the most
> 
>>avid porter of all of us...there's a project for you!)
> 
> 
> Well, since I don't like Linux, I guess it's not a project for me... =)
> 
> 
> 
Then you will start something new ;-)