Java-Linux

[gerdich]

Es gibt mittlerweile einige mobile Geräte auf denen eine JAva-VM läuft.

Debian-Linux lässt sich mittlerweile in verschiedenen Architekturen kompilieren.

Wäre es nicht denkbar C-,C++-Code in Java-Bytecode zu kompilieren?

Könnte man Linux nicht oberhalb einer JAVA-VM aufsetzen?

Dann könnte man wenigstens einfache Linux-Programme, die nicht so zeitkritisch sind, auf Maschinen laufen lassen, für die es noch keinen nativen Linuxkernel gibt.

(Die gleiche Frage stellt sich auch für dotnet-Bytecode.)

[TRex]

Wäre es nicht denkbar C-,C++-Code in Java-Bytecode zu kompilieren?

Nein.

[damack]

Also ich bin davon ausgegangen das Dotnet keinen Bytecode hat. Sondern das es wie bei Java ist, dass
der Code zur Laufzeit Interpreter werden. Liege ich da falsch?

[gerdich]

Also ich bin davon ausgegangen das Dotnet keinen Bytecode hat. Sondern das es wie bei Java ist, dass
der Code zur Laufzeit Interpreter werden. Liege ich da falsch?

Du liegst doppelt falsch. Sowohl Java als auch Dotnet sind Bytecode-Interpreter. Der Quelltext wird in Bytecode KOMPILIERT der Bytecode wird von der VM INTERPRETIERT (oder zusätzlich optimiert und zeitweise lokal in Maschinensprache assembliert.)


Ich sehe keinen Grund, warum ein C-,C++-Quelltext nicht in JAVA oder Dotnet-Bytecode kompiliert werden könnte.
Mittlerweile habe ich sogar schon einfache Kompiler gefunden.


Ich sehe keinen Grund, warum man Debian nicht auf einer VM laufen lassen könnte. Mit einem passenden Kompiler könnte man alle Debian-Packages genau so auf VM kompilieren, wie man das für x86, arm, mipsel ... auch tut.
Das wäre sehr nützlich und würde ein Debian erlauben, das auf ALLEN javafähigen Computern liefe.

[cosmac]

hi,

Wäre es nicht denkbar C-,C++-Code in Java-Bytecode zu kompilieren?

Nein.

einfach unvorstellbar oder kennst du konkrete Hindernisse? Ob ein Compiler jetzt x86-Maschinenbefehle oder Bytecode erzeugt, ist doch egal? (wobei Bytecode sogar einfacher sein sollte).

Allerdings scheinst du Recht zu haben, bei Javum geht anscheinend nichts mehr weiter, schade.

[yeti]

...googelt findemaschinelt mal nach UCSD-System oder UCSD-Pascal.
Das UCSD-System war Soetwas: Ein OS auf einer VM, nur nannte man das damals noch nicht so.
So war es dann "leicht" zu portieren: Nur der PCode-Interpreter musste auf die neue Hardware angepaßt werden und alles Andere lief dann auf diesem virtuellen Prozessor.
Egal ob Appöle-][, C64, TRS-80, "Kompatibler", ... UCSD war weitreichend verfügbar und zeitweilig auch stark verbreitet. Mit einer anderen Lizenz- oder Preispolitik wäre diese Technologie nicht zwischenzeitlich in Vergessenheit geraten, so daß es verhindert hätte werden können daß alle Welt nun eine VM für eine Erfindung der Javanesen hält... UCSD war schlicht 2 Jahrzehnte zu früh da...

[gms]

hi,

Wäre es nicht denkbar C-,C++-Code in Java-Bytecode zu kompilieren?

Nein.

einfach unvorstellbar oder kennst du konkrete Hindernisse? Ob ein Compiler jetzt x86-Maschinenbefehle oder Bytecode erzeugt, ist doch egal? (wobei Bytecode sogar einfacher sein sollte).

ja, aber die Java-VM muß ja auch erst einmal für diese Zielplattform übersetzt werden. Daher gibt es auf dieser Plattform zuerst einen C/C++ Compiler und danach erst eine Java-VM. Warum sollte man also versuchen C/C++ Code in Java-Bytecode zu übersetzen ( wofür es noch keinen Compiler gibt ), wenn man diesen gleich in Maschinencode übersetzen könnte ?

Dann könnte man wenigstens einfache Linux-Programme, die nicht so zeitkritisch sind, auf Maschinen laufen lassen, für die es noch keinen nativen Linuxkernel gibt.

auch der Kernel wird notwendiger Weise vor einer Java-VM vorhanden sein müssen, damit die Systemcalls die diese Java-VM benötigt, verarbeitet werden können
edit: und was sollte es für einen Sinn machen, einen Linuxkernel in einer Java-VM laufen zu lassen ?

Gruß
gms

[gerdich]

ja, aber die Java-VM muß ja auch erst einmal für diese Zielplattform übersetzt werden.

Es gibt (auf den kleinen mobilen Geräten) zahlreiche Plattformen, für die eine VM existiert (oder dotnet), aber KEIN Linux.
(Man braucht für ein Linux nämlich nicht nur C resp C++, sondern auch die Quellen der Hardware-Treiber und die bekommen die Hersteller von VM oder dotnet-Implementationen leichter, als die tüchtigen Entwickler von Debian.)

auch der Kernel wird notwendiger Weise vor einer Java-VM vorhanden sein müssen, damit die Systemcalls die diese Java-VM benötigt

Ich denke nicht, dass der Kernel VOR der Java-VM vorhanden sein muss.
Er kann selber IN der VM-laufen, genau so wie ein Mipsel oder Arm-Kernel in Mipsel oder Arm-Maschinensprache läuft. Alle Systemcalls werden IN der Java-VM aufgerufen, weil die Systemprozesse in einem solchen Linux selber in der VM laufen.

Das wäre ein generischer Kernel, der für alle VM's laufen würde. Er wäre weitgehend hardwareunabhängig.

Ein solches Linux könnte man sofort auf jedem x-beliebigen Computer starten, sobald er eine VM besitzt (resp. Dotnet).

was sollte es für einen Sinn machen, einen Linuxkernel in einer Java-VM laufen zu lassen ?

Allein schon der Umstand, dass man völlig unabhängig wird von allen echten Hardware-Treibern und nur noch mit allgemeinen virtuellen Treibern arbeitet, rechtfertigt ein solches Projekt vollständig.
Debian muss sich dann nicht mehr selber um die Hardware-Treiber kümmern, sondern die Ersteller der VM oder einer hardwarespezifische dotnet-Implemention.

[gms]

ja, aber die Java-VM muß ja auch erst einmal für diese Zielplattform übersetzt werden.

Es gibt (auf den kleinen mobilen Geräten) zahlreiche Plattformen, für die eine VM existiert (oder dotnet), aber KEIN Linux.

und ? aber einen Kernel haben die ja trotzdem

Ich denke nicht, dass der Kernel VOR der Java-VM vorhanden sein muss.

das mag ja sein, nur wirst du dann die Java-VM für diese Zielplattform nicht übersetzen können ( falls du einen Java-Prozessor meinst, der quasi den Byte-Code als Maschinencode verwendet, dann solltest du von diesem sprechen und nicht von einer Java-VM )

[gerdich]

aber einen Kernel haben die ja trotzdem

Ja und? Der ist für die JVM transparent. Der Zugriff auf das darunter liegende Betriebssystem ("Kernel") wird vermieden, Stichwort Sandbox.

nur wirst du dann die Java-VM für diese Zielplattform nicht übersetzen können

Die will ich ja gar nicht übersetzen! Die ist schon da!!! Das ist bei mir Voraussetzung. Ich spreche von Maschinen, auf denen eine JVM bereits existiert, aber kein Linux.
Natürlich hätte ich lieber ein natives Linux. Aber wenn es das nicht gibt, dann braucht man eine andere Lösung.

falls du einen Java-Prozessor meinst, der quasi den Byte-Code als Maschinencode verwendet, dann solltest du von diesem sprechen und nicht von einer Java-VM

Das macht für meine Überlegungen gar keinen Unterschied.
Das ist nur eine Frage der Implementierung (softwaremässig oder hardwaremässig).
Der Java Prozessor läuft genau gleich wie die JVM. Das ist ganz einfach eine hardwaremässig implementierte JVM.
Da gibt es keinen Unterschied, ausser der Geschwindigkeit.

[cosmac]

Es geht doch viel einfacher: man muß nur qemu in Bytecode übersetzen und als Anwendung direkt auf der JVM laufen lassen. Da kann man dann ein Original Lenny für i386 installieren

[gms]

Es geht doch viel einfacher: man muß nur qemu in Bytecode übersetzen und als Anwendung direkt auf der JVM laufen lassen. Da kann man dann ein Original Lenny für i386 installieren

Qemu wollte ich auch gerade einbringen, aber wozu der Umweg über die JVM ist mir unklar, wenn es auf der Zielplattform offensichtlich Möglichkeiten gibt, Qemu native für diese Plattform zu übersetzen

[yeti]

Noch besser: http://javapc.sourceforge.net/home_home.html

[gms]

Noch besser: http://javapc.sourceforge.net/home_home.html

nette Idee, dürfte in etwa das sein, nachdem "gerdich" gesucht hat

Der Zugriff auf das darunter liegende Betriebssystem ("Kernel") wird vermieden, Stichwort Sandbox.

eine Java-VM hängt nicht in der Luft, daher kann dieser Zugriff nicht vermieden werden ( auch bei einer Sandbox nicht )

nur wirst du dann die Java-VM für diese Zielplattform nicht übersetzen können

Die will ich ja gar nicht übersetzen! Die ist schon da!!! Das ist bei mir Voraussetzung. Ich spreche von Maschinen, auf denen eine JVM bereits existiert, aber kein Linux.

du sprichst daher von Maschinen, für die ein C/C++ Compiler existiert, jedoch kein Compiler der C/C++ Code in Bytecode übersetzen könnte

Der Java Prozessor läuft genau gleich wie die JVM. Das ist ganz einfach eine hardwaremässig implementierte JVM.
Da gibt es keinen Unterschied, ausser der Geschwindigkeit.

doch, den daß der Java-Prozessor einen Kernel beinhaltet, die Java VM jedoch nicht

Gruß
gms

[gerdich]

Vielen Dank für den tollen Link!

Das kommt meinen Vorstellungen schon sehr nahe.

Hier gibt es aber einen Umweg:
Es wird erst ein PC emuliert und dann darauf mit 86-Assembler Linux installiert.

Ich möchte direkt Debian in Bytecode kompiliert sehen. Das ist dann nicht bloss ein Emulator.

eine Java-VM hängt nicht in der Luft, daher kann dieser Zugriff nicht vermieden werden ( auch bei einer Sandbox nicht )

Die JVM selbst greift auf das Betriebssystem zurück (Das interessiert den Java-Prrogrammierer nicht, sondern den Programmierer der JVM). Aber innerhalb der JVM werden Zugriffe auf das Betriebssystem vermieden. Allerdings gibt es auch in Java die Möglichkeit Bibliotheken des Betriebssystems nach Java zu exportieren. Das ist aber grundsätzlich nicht nötig. Man kann vollständig in Java bleiben und trotzdem auf die Multimedia Hardware zugreifen, im Rahmen des Vorgesehenen.

du sprichst daher von Maschinen, für die ein C/C++ Compiler existiert, jedoch kein Compiler der C/C++ Code in Bytecode übersetzen könnte

Nicht genau. Sicher gibt es einen solchen Kompiler schon irgendwo (ohne GPL). Dein Emulator muss ja so etwas verwendet haben.

Häufig kann man auf einer Plattform Debian nicht zum Laufen bringen, obwohl ein C/C++-Compiler besteht. Der Grund ist häufig, dass die Sourcen der Hardware-Treiber nicht bekannt ist. Hier könnte man Debian wenigstens auf der JVM aufsetzen.

doch, den daß der Java-Prozessor einen Kernel beinhaltet, die Java VM jedoch nicht

Der Java-Prozessor beinhaltet genau so wenig einen Kernel wie die JVM. Der Kernel versorgt den Prozessor und ist nicht Teil des Prozessors.

Innerhalb der JVM wird der Kernel technisch wohl folgendermassen aussehen:
Die JVM startet automatisch eine aktive Klasse (Hauptthread).
Dieser Thread wird als Kernel programmiert.

Ohne die Details der Implementierung der verschiedenen Java-Prozessoren zu kennen, nehme ich an, dass das auch hier gleich aussehen wird.
Auf jeden Fall wird der Kernel NICHT auf dem Prozessor sein, sonst wäre es kein Kernel.

[gms]

Auf jeden Fall wird der Kernel NICHT auf dem Prozessor sein, sonst wäre es kein Kernel.

du hast anscheinend noch nichts von einem "microprogrammed Kernel" gehört und natürlich baucht der Java-Prozessor etwas Derartiges, um auf die Resourcen ( IO, Netzwerk, RAM,... ) zugreifen zu können und natürlich verwendet eine Java-VM im Gegensatz dazu das darunterliegende OS bzw dessen Kernel

Ohne die Details der Implementierung der verschiedenen Java-Prozessoren zu kennen, nehme ich an, dass das auch hier gleich aussehen wird.

... ich habe jetzt aber nicht weiter vor, deine wilden Annahmen zu korrigieren, du kannst von mir aus alles Mögliche ( und Unmögliche ) annehmen

[yeti]

Linux auf einer rein virtuẽllen Plattform: http://labs.freehackers.org/projects/zeta

[gerdich]

du hast anscheinend noch nichts von einem "microprogrammed Kernel" gehört

Ich habe das Gefühl, dass du nicht verstanden hast, was ein "microprogrammed kernel" ist.
Das ist wie das Wort sagt PROGRAMMIERTER Code mit dem der Maschinenbefehlssatz des Prozessors intern erweitert wird.
Selbst dieser Code gehört nicht zur CPU, sondern findet sich getrennt davon auf einem ROM oder EPROM.
Der Code wird in die CPU geladen.

Man nennt dies einen CPU-"Kernel" aber das hat nichts mit dem Kernel des Betriebssystems zu tun. Zusätzlich zu so einem "CPU-Kernel" braucht man noch ein Betriebssystem für die Zugriffe auf Speicher und andere Hardware.

Natürlich braucht die JVM unter sich ein Betriebssystem (Kernel), um auf die Hardware zuzugreifen. Die JVM kennt nämlich keine Hardware spezifischen Treiber, sondern setzt diese voraus.

Hierin unterscheidet sich eine Hardware-Implementation von JAVA überhaupt nicht von einer softwaremässigen.
Die Microprogrammierung dient nur dazu den Bytecode als Maschinensprache der CPU zu etablieren. Sie dient nicht dazu das Betriebssystem zu ersetzen. Das ist unmöglich, weil der Speicher und die übrige Hardware nicht CPU-intern sind.

Will man aber eine Maschine realisieren, die GANZ in Java läuft (also ohne anderen Code), dann muss man den Kernel innerhalb von Java in einem eigenen Thread kapseln. Ohne einen Kernel kann kein System laufen. Nimmt man aber den nativen Kernel braucht man Java-fremden Code.
Deshalb gehe ich davon aus, dass dies auf reinen Javamaschinen so realisert ist und der Kernel gekapselt ist.

Das ist aber wie gesagt nur eine Vermutung.

Auf jeden Fall ist es möglich dies zu tun, ganz gleich ob das bisher jemals so realisiert wurde und dein Emulator muss das auch so machen. Hier kann man auch einen Debian_Kernel nehmen, den man in Bytecode kompiliert hat.

Auch hier sind Hardware- und Softwareimplementation von JVM in der selben Lage.

[gms]

Selbst dieser Code gehört nicht zur CPU, sondern findet sich getrennt davon auf einem ROM oder EPROM.
Der Code wird in die CPU geladen.

spätestens wenn der Code geladen wäre, wäre also diese/deine Aussage falsch:

Der Java-Prozessor beinhaltet genau so wenig einen Kernel wie die JVM.

Übrigens ist es für mich ziemlich nebensächlich, ob du den Micocode/Firmware ( bzw in diesem Fall Kernel ) als Teil des Java-Prozessors siehst, oder nicht. Nachdem dieser für die Instructions dieses Prozessors benötigt wird, der Java-Prozessor daher ohne diesem nicht funktionsfähig wäre, befindest du dich diesbezüglich natürlich in der Minderheit

Natürlich braucht die JVM unter sich ein Betriebssystem (Kernel), um auf die Hardware zuzugreifen. Die JVM kennt nämlich keine Hardware spezifischen Treiber, sondern setzt diese voraus.

na endlich

Der Zugriff auf das darunter liegende Betriebssystem ("Kernel") wird vermieden,

daher wollen wir den Zugriff auf diese Harware auch nicht vermeiden

Die Microprogrammierung dient nur dazu den Bytecode als Maschinensprache der CPU zu etablieren.

und wenn hierfür nur die Kleinigkeit eines "micoprogrammed Kernels" benötigt wird, wird man daran kaum etwas daran ändern können

[uljanow]

Innerhalb der JVM wird der Kernel technisch wohl folgendermassen aussehen:
Die JVM startet automatisch eine aktive Klasse (Hauptthread).
Dieser Thread wird als Kernel programmiert.

Ohne die Details der Implementierung der verschiedenen Java-Prozessoren zu kennen, nehme ich an, dass das auch hier gleich aussehen wird.
Auf jeden Fall wird der Kernel NICHT auf dem Prozessor sein, sonst wäre es kein Kernel.

Das spielt in der Praxis keine Rolle, denn da hat man eine ARM-CPU mit Jazelle/ThumbEE Unterstützung, welche Bytecode nur in einem speziellen Modus ausführt. Andere Aufgaben werden in 32-bit ARM Machinencode erledigt, d.h. ein Kernel ist Voraussetzung.

Aber Interrupt Initialisierung und Handler würden in java bestimmt lustig aussehen.

[bmario]

in meinen Augen macht so ein Vorhaben überhaupt keinen Sinn.

Hast du dich mal intensiv damit beschäftigt, was so ein Kernel wie Linux eigentlich macht?
Grob gesagt gibt es das Memory Management, was in verschiedenen Abstraktionsstufen anfällt (siehe physical memory management, virtual memory management, paging, swaping usw.), der Scheduler (dazu gehört dann auch Prozess- und Threadverwaltung, sowie die Kommunikation der einzelnen Prozesse und Threads untereinander) und die Hardwareverwaltung. Dafür gibt es unter jeder Architektur wie x86, arm usw. spezielle Vorgaben der Hardwarehersteller, wie so ein System benutzbar wird. Aber allen ist gleich ist, dass alles dafür getan wird, um Betriebsysteme auf diesen Systeme zu ermöglichen. Bei x86 gibt es da z.B. die Ringe, Page-Tables, die Directory-Table, Hard- und Softwareinterrupts, sowie die Interrupt-Table und vieles mehr. Als gute Lektüre empfehle ich zu dem Thema das Low-Level-Magazin.

Und ich bezweifle stark das die JVM ähnliche Techniken anbietet, warum sollte sie auch? Schließlich ist die JVM rein für Anwendungsprogramme gedacht.

Ganz davon abgesehen sehe ich keinen Grund, warum man Linux innerhalb einer JVM laufen haben will. Wie bereits gesagt, gibt es eher für die Architektur Linux als eine JVM. Und auf den Geräten wo es wirklich nur eine JVM gibt, wie z.B. Handies, macht es ohnehin mehr Sinn ein Java Programm zu schreiben, da man somit auf alles Zugriff erhält was nötigt ist.

Und wenn es simpel darum geht, bestimmte Linux Programme überall laufen zu lassen, und sei es über die Krücke Java, kommt man mit einer richtigen Portierung dieser Programme auf die Zielplatform besser.

Zudem ist ein Linux in einer JVM noch größerer Mist als das Emulieren mit Qemu oder ähnlichem.

Mario

[gerdich]

Und wenn es simpel darum geht, bestimmte Linux Programme überall laufen zu lassen, und sei es über die Krücke Java, kommt man mit einer richtigen Portierung dieser Programme auf die Zielplatform besser.

Auch du hast meines Erachtens etwas gründlich missverstanden:
Du verwechselst JAVA mit JVM. (Wir reden ja nicht von JRE).

Auf der JVM brauchst du kein JAVA. Sondern du kannst genau so gut mit C/C++ programmieren und in Bytecode compilieren (genau so, wie du für dotnet kein C# brauchst). Es gibt sogar Assembler, die Bytecode produzieren.

Bytecode kannst du als eine virtuelle Maschinensprache auffassen, genau so wie Arm, Xscale, Mipsel, i386, powerpc ... .
(Halt etwas langsamer.)

Du behauptest, man könne kein Speichermanagement, kein Prozessmanagement und keine IPC in Bytecode programmieren.

Das widerspricht direkt den Fakten:
Die JRE macht es ja.

Statt der JRE kannst du genau so gut einen Linux-Kernel in Bytecode kompilieren.

Es ist schön, dass du so viel über das Speicher-Paging von Linux weisst. Das ist aber hier nicht wichtig. Wichtig ist nur, dass es sich 1-zu-1 in Bytecode kompilieren lässt und dort auf der JVM laufen kann.



PS.:
Wenn es so einfach wäre, wie du meinst, eine richtige Linux-Portierung zufinden, wäre mein Vorschlag allerdings sinnlos.
Die Realität sieht anders aus.
Ich habe einen
PocketLoox T830
Mobilepro 900c
Axim x30

Auf allen gibt es keine Debianportierung, die alle Hardware ansteuern kann.

Wie toll eine solche Portierung wäre erlebe ich mit meinem eeepc, den ich seit Debian-Linux nur noch ausschliesslich benutze.

[bmario]

Ich habe nie behauptet, dass es einfach ist eine Linux-Portierung zu FINDEN, ich finde es nur sinnvoller eine Linux Portierung auf diese Geräte zu MACHEN. Das Java <> JVM ist, ist mir schon klar. Nur ist es doch so, zumindest soweit ich weiß, gibt es in einer JVM nur eingeschränkte Möglichkeiten auf die Hardware des physischen Systems zu zugreifen. z.B. gibt ein keinen USB Support in Java, was es für mich nahe legt, dass dies a) schlicht nicht möglich ist oder b) zu aufwändig ist. Ich meine es gibt mehr zu beachten, also das die JVM simpel irgendwelche Pointer auf Speicherbereiche zurück gibt. Ich glaube einfach nicht daran, dass Linux in einer JVM Spass macht. Du musst ja auch mal so sehen, was ich beschrieben haben ist nur ein kleiner Teil des Linux 0.1 Kernels und der war zwar nicht sehr groß aber dennoch schon komplex.
Dann schau mal in den aktuellen Kernel rein. Hast du eine Vorstellung davon, wieviel des Codes geändert werden müsste um das Teil in einer JVM zum laufen zu bringen?

Und wenn ich deine letze Aussage so sehe glaube ich, es geht dir nichtmal darum einzelne Programme zu nutzen, sondern das komplette GNU/Linux mit z.B. Gnome? Das ist Irrsinn. Dafür müsstest du nicht nur den Kernel anpassen sondern den kompletten Userspace.
Und selbst wenn das gelänge, gehe ich jede Wette ein, das ein Windows 7 auf einem 386 mit 4 MB Ram performanter läuft als dieser Stack von virtualisierter Virtualisierung.

Nebenbei, diese Teile klingen als wären es PocketPC's mit WinMob drauf? Flasht du auch deinen E-Herd auf Linux

Mario

[gerdich]

Nur ist es doch so, zumindest soweit ich weiß, gibt es in einer JVM nur eingeschränkte Möglichkeiten auf die Hardware des physischen Systems zu zugreifen.

Das ist schon so. Aber die Entwicklung geht immer mehr zu generellen virtuellen Geräte-Drivern. Natürlich kann man damit nicht mehr alles direkt ansprechen und ist von der Implementierung der JVM abhängig. Aber sie lassen sich genau so wie einfache Hardware-Driver behandeln.
Wenn man die wenigen JVM-High-Level-Driver im Kernel implementiert hat, kann man dafür alles auf jeder Platform ansprechen, falls die JVM darauf Zugriff hat, und braucht sich nicht mehr um konkrete Details zu kümmern.

Für USB hoffe ich, dass sich das Linux USB-System oberhalb der JVM kompilieren lässt und die JVM dazu genug Hardware-Zugriff auf die Ports bietet.

(Was USB betrifft: Ich sprach nicht nur von Java-Bytecode, sondern auch von dotnet-Bytecode. Das würde sich hier besser eignen.)

Ich glaube einfach nicht daran, dass Linux in einer JVM Spass macht.

Vielleicht wegen der Geschwindigkeit. Ansonsten erwarte ich keine grossen Unterschiede.

Hast du eine Vorstellung davon, wieviel des Codes geändert werden müsste um das Teil in einer JVM zum laufen zu bringen?

Hast du eine Ahnung, wie sehr sich die Architektur eines Arm-Computers z.B. von einem gewöhnlichen PC unterscheidet?
Ich vermute sehr, dass es einfacher ist einen PC-Kernel an die Anforderungen der JVM anzupassen, als an ARM, Mipsel und Co. Die haben eine völlig andere Speicherstruktur. Die JVM hat wohldefinierte Schnittstellen.

Und wenn ich deine letze Aussage so sehe glaube ich, es geht dir nichtmal darum einzelne Programme zu nutzen, sondern das komplette GNU/Linux mit z.B. Gnome? Das ist Irrsinn. Dafür müsstest du nicht nur den Kernel anpassen sondern den kompletten Userspace.

Gnome wird wohl nicht brauchbar sein, wegen der Geschwindigkeit und des Speichers.
Aber der Userspace sollte keine grossartigen Anpassungen mehr verlangen, wenn der Kernel linuxkonform ist. Der wird nach Bytecode kompiliert und fertig! Die Anwendungen lade ich mit apt-get. Der Strom kommt schliesslich aus der Steckdose!

Und selbst wenn das gelänge, gehe ich jede Wette ein, das ein Windows 7 auf einem 386 mit 4 MB Ram performanter läuft als dieser Stack von virtualisierter Virtualisierung.

Da hast du wohl recht. Aber bei den kleinen Geräten geht es ja häufig nicht um Performanz, sondern um einfache Benutzerhilfen.

Nebenbei, diese Teile klingen als wären es PocketPC's mit WinMob drauf? Flasht du auch deinen E-Herd auf Linux

Du lachst. Aber in einer Firma in der ich gearbeitet habe war das die Devise. Es kann billiger sein, in eine Waschmaschine einen vollständigen embedded PC zu stecken mit einem kleinen Linux drauf, als eine billige abartige Elektronik mit einem schwer programmierbaren Prozessor, der Spezialinstrumente und Spezialentwickler braucht.

[gms]

Wichtig ist nur, dass es sich 1-zu-1 in Bytecode kompilieren lässt und dort auf der JVM laufen kann.

ja, das wäre wohl wichtig, spielts halt leider nicht bei einer Java-VM, die nicht mal alle primitiven C-Datentypen unterstützt, deren Opcodes für Java-Programme ausgelegt wurden, die keine Register kennt....

denkbar wäre natürlich, daß man aus der Java-VM eine Java und C/C++ VM bastelt, aber wer will das schon ? Das war ja nicht einmal deine Intention