As I understand it JAVA half compiles stuff into bytecode ... the Linux
community should design a virtual machine and associated byte code
processor and then port linux to that virtual machine, this would eliminate
assembly code for the various machines, etc. The idea being to design a
standard setting virtual machine, here are some of my ideas:
1. Every one talks about registers, is the next generation hardware
going to have this many or that many etc. etc., the virtual machine should
not have registers --- just memory.
2. Minimize the set of instructions --- this should be a fast virtual
machine.
3. input and output done through a single I/O pipe --- the bus protocol
should be
4. No intrinsic bit width-- 8 bit, 16 bit, 64 bit, and all that garbage.
I have been working on encoding schemes that make the size of the data
and the data one self describing unit without limiting the size of the
data.
And so on ... the point is that the VIRTUAL MACHINE is designed by a lot of
hackers.
On Tue, 25 Mar 1997, Andrew Vanderstock wrote:
> Miguel, I'm not good with sarcasm, so I'm hoping that your statement is one
> oozing with sarcasm. If it's not sarcastic, then please take my apologies
> now.
>
> The ideas behind implementing anything in like an OS in Java is
> groundbreaking, but ultimately, bnound to fail as Java stands now - it has
> too few OS necessities (like pointers, the ability to control hardware, the
> list goes on).
>
> But - Linux as it stands has a few major failings:
> * non-dynamic object allocation (see recent >256 fd thread for just one
> example)
> * non-re-entrant kernel
> * non-threaded kernel
>
> Now, why would we need these things? We would need far fewer compilation
> options or tuneable areas if we simply allowed objects to be allocated from
> a dynamically resizeable pool. Memory is cheap, and in many circumstances,
> a well chosen algorithm will be better than just allocating enough for the
> average user. For a single user box, a well chosen algorithm will use less
> memory and be faster, and for a high end Internet server, with 4
> processors, lots of RAM and fast disk, a well chosen algorithm can extend
> the necessary objects as necessary to support the load. No tuning required.
> Computers are far better tuners than humans anyway.
>
> A re-entrant kernel would allow us to have different parts of the kernel
> alive at different times. This would help SMP machines no end. How to do a
> re-entrant kernel? Basically globals are out unless they are OS-Wide
> constants. It will require some work (an understatement of the century),
> but since we're Unix compatible, and not unix, we can still provide POSIX
> services to a program, whilst supporting it upon a much better foundation.
> I am not saying here that we throw away support for 2.0/2.1 binaries, just
> that we can do better with the kernel.
>
> A fully threaded kernel, (for example) breaking down device drivers into
> their own threads would help again, as we could schedule them on any
> available processor, and be more independant of the kernel state. This
> would give us a major speed boost, particularly on SMP machines.
>
> I'd also like to see much better boot management. The idea of an OS booting
> to a textual display in 1997 is ridiculous. Also, the current boot strategy
> is an all or nothing approach. If you don't make it to a login prompt, you
> better have a recovery boot disk around. That sucks.
>
> At this stage of the game, we should be laying down ideas for a 3.0 version
> of Linux, and trying to stabilize 2.1 for final release, and definitely
> maintenance mode 2.0 to encourage upgrades to the next stable release. As
> far as I can tell, there are far too few reasons for any reasonable user to
> upgrade to 2.1 at the moment if you have a recent 2.0 kernel - we need to
> change that.
> --
> "Hate is not a family value" - bumper sticker
> Andrew Vanderstock (ajv@greebo.svhm.org.au)
>
> ----------
> > From: Miguel de Icaza <miguel@nuclecu.unam.mx>
> > To: linux-kernel@vger.rutgers.edu
> > Subject: Now, why didn't we think of this before?
> > Date: Tuesday, 25 March 1997 6:05
> >
> >
> > And I wonder, why were we ever concerned about speed issues?
> >
> > Miguel.
> >
> > Date: Mon, 24 Mar 1997 10:16:50 -0800 (PST)
> > From: "W. Reilly Cooley" <wcooley@navi.net>
> > To: mach4-users@cs.utah.edu
> > Subject: Re: Portability
> > In-Reply-To: <199703241352.NAA06096@odie.barnet.ac.uk>
> > X-X-Sender: wcooley@navi.net
> > MIME-Version: 1.0
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> >
> >
> > I had an idea for an interesting project, which would provide
> > remarkable portability: A Java VM server for a Mach4 MK, which could
> then
> > run Sun's JavaOS, or any other OS written in Java. Considering that
> > JavaOS is not free, it would perhaps be a good excuse to implement the
> > Linux kernel in Java, as had been thrown around a bit. This second
> > project could draw also from the work done on MkLinux.
> >
> > Maybe when I return to school and have more time...
> >
> > What do you think?
> >
> > Wil
> >
> > - -------------------------------------------------------------
> > W. Reilly Cooley
> > NakedApe Consulting & Navi.Net representative
> > 1509 NE 10th Ave., #104 Portland, OR 97232
> > 503 287-2165 wcooley@navi.net
> > www.navi.net/~wcooley www.navi.net/~nakedape
> >
> > As a service, I provide analysis for viruses and poor grammar to senders
> > of unsolicited commercial e-mail at a rate of US$250 per hour. Delivery
> of
> > said correspondence constitutes a request for the aforementioned services
> > at said price.
> > ------- End of forwarded message -------
>