Open source Java VM op Linux

[Baron]

Heeft er iemand al JamVM geprobeerd?

Volgens http://sourceforge.net/projects/jamvm/ is het een nieuwe Java Virtual Machine volledig conform de JVM specificaties
JamVM zou extreem klein zijn 70K op i386.

Helaas voor mij draait het onder Linux en daar ken ik niet zoveel van.
Graag had ik toch reacties van jullie hierover gehad want 1 van de nadelen van de Sun VM is dat het geheugen VREET.

[im_ik]

Ik ben hem nu eve aan het proberen......
Moet er wel eve bij zeggen dat het allen een interpet is dus er zit geen JIT in..

En verder denk ik dat je in NOS meer reacties hierover krijgt.

edit:

code:

Currently JamVM has been used to run fairly major command-line programs includin
g
Javac, SPECJvm 98 benchmark suite and jBYTEmark.  Unfortunately classpath's AWT
support is at an early stage so JamVM can't be used for graphical applications,
but this is independent of the VM, so it will improve in the future as
classpath matures.

uit de readme..

Dus heb eve wat gekeken wat voor cui java app ik nog had liggen..
En heb allen EchoPoolServer example werkted gekregen..
Maar om toch een testje te posten ....

code:

PID      USER   PRI NI   SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
15589 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15590 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15591 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15592 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15593 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15594 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15595 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15596 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15597 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15598 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15599 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15600 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15601 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15602 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm
15603 willemc    9   0  1804 1800   556 S     0.0  0.2   0:00 jamvm


15762 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15763 willemc   11   0  9824 9824  5356 S     0.0  1.2   0:00 java
15764 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15765 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15766 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15767 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15768 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15769 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15770 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15772 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15773 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15774 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15775 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15776 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15777 willemc    9   0  9824 9824  5356 S     0.0  1.2   0:00 java
15778 willemc   10   0  9824 9824  5356 S     0.0  1.2   0:00 java
15779 willemc   10   0  9824 9824  5356 S     0.0  1.2   0:00 java
15780 willemc   10   0  9824 9824  5356 S     0.0  1.2   0:00 java
15781 willemc   11   0  9824 9824  5356 S     0.0  1.2   0:00 java


15801 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15802 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15803 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15804 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15805 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15806 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15807 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15808 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15809 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15810 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15812 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15813 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15814 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15815 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15816 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15817 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15818 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15819 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15820 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java
15821 willemc    9   0 11908  11M  6872 S     0.0  1.5   0:00 java

Dit zijn de comando's die ik heb gebruikt...in dezelfde volgorde als boven.
jamvm PoolEchoServer
java -cp . PoolEchoServer
java -server -cp . PoolEchoServer

De java versies:

willemc@myhouse:~/java/3dserver$ jamvm -version
JamVM version 1.0.0
<[e-mail]>
Copyright (C) 2003 Robert Lougher

willemc@myhouse:~/java/3dserver$ java -version
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

Uiterraad kan je dit niet als een echte test beschouwen aangezien JIT mijn voorkeur
toch uitlaat gaan naar de sun jre al heb ik de snelheid van jamvm niet getest heb.
Meschien doe ik dat later nog eens.

edit2: vreemd got haalt me 2 enter weg in de code...
Maar het mag duidelijk zijn dat de -server opties de java is waar 11M in staat

[ Voor 97% gewijzigd door im_ik op 21-03-2003 14:54 ]

[Baron]

Ik wist niet waar dit topic moest plaatsen.
Voor mijn part mag men het verhuizen.

[mbravenboer]

Daar zit vast geen jitter in (wat overigens ook niet vereist is)

[TheGhostInc]

mbravenboer schreef op 21 March 2003 @ 14:21:
Daar zit vast geen jitter in (wat overigens ook niet vereist is)

Zouden jullie even kunnen uitleggen welke beperkingen dit op legt?
JIT snap dat het Just in Time betekent,
maar wat betekent dat voor het runnen van Java apps? Kun je dan niet rechtstreeks de source draaien, maar moet je eerst compilen?

70KB is freaking klein, zit hier dan wel al grafische toei in?

[Baron]

JIT in dit geval wil zeggen dat de Java byte-code juist voor uitvoering naar native-code wordt gecompileerd, wat achteraf voor een snellere uitvoering zorgt.

[Jelmer]

TheGhostInc schreef op 21 March 2003 @ 14:26:
[...]


Zouden jullie even kunnen uitleggen welke beperkingen dit op legt?
JIT snap dat het Just in Time betekent,
maar wat betekent dat voor het runnen van Java apps? Kun je dan niet rechtstreeks de source draaien, maar moet je eerst compilen?

70KB is freaking klein, zit hier dan wel al grafische toei in?

Nee, dat is onder licentie van SUN. Dit is alleen de echte basis met alleen java.lang/.io/.net/.math/.util/.text denk ik.

[mbravenboer]

Je hebt kans dat SWT er op kan draaien qua GUI library.

[Verwijderd]

Ik denk dat je je hier niet teveel bij voor moet stellen. Dat het open source is, is leuk, maar het zal waarschijnlijk nooit kunnen tippen aan de snelheid van Sun en IBM VMs. Het schrijven van een snelle JVM (met Just in Time complilation e.d.) is echt niet iets dat je in je vrije uurtjes voor elkaar krijgt.

[Soultaker]

TheGhostInc schreef op 21 March 2003 @ 14:26:
70KB is freaking klein, zit hier dan wel al grafische toei in?

Nee, het is slechts een virtual machine met basisfunctionaliteit. Alle extra functionaliteit (zoals grafische "toei") zit in (standaard) libraries, die apart geinstalleerd moeten worden. Op de website wordt GNU Classpath aangeraden.

Verwijderd schreef op 21 March 2003 @ 14:46:
Ik denk dat je je hier niet teveel bij voor moet stellen. Dat het open source is, is leuk, maar het zal waarschijnlijk nooit kunnen tippen aan de snelheid van Sun en IBM VMs. Het schrijven van een snelle JVM (met Just in Time complilation e.d.) is echt niet iets dat je in je vrije uurtjes voor elkaar krijgt.

Een geoptimaliseerde JVM is niet altijd van het grootste belang. Soms is het voldoende om een kleine, efficiente VM te kunnen starten (die ook nog open source is) en dan is de VM van Sun overkill.

Als een "scriptje" van enkele honderden statements uitgevoerd moet worden, zou deze kleine VM in een praktijksituatie (met beperkt geheugen en beperkte disk access) best eens sneller kunnen zijn dan de VM van Sun, die belachelijk veel geheugen nodig heeft (maar, toegegeven, op de langere termijn ongetwijfeld beter presteert).

[im_ik]

pfft topic is hard gegaan...

Maar hij is inderdaad behoorlijk klein:
willemc@myhouse:~/java/3dserver$ ls -la /usr/local/libexec/jamvm
-rwxr-xr-x 1 root staff 71756 Mar 21 15:15 /usr/local/libexec/jamvm

zo'n 71kb wel netjes voor een java interperter.

edit:
oeps mijn clock staat 1 uur voor

[ Voor 9% gewijzigd door im_ik op 21-03-2003 14:57 ]

[Glimi]

Ik zie nergens staan of ie garbage collection ondersteund en in welke mate hij dat doet. Dat is nl. niet verplicht volgens de Sun eisen.
Ik heb ook zo'n beetje het vermoeden dat ze het niet geïmplementeerd hebben, ik zie ook nergens documentatie, alleen iets reppen over finalisation.

[im_ik]

Glimi schreef op 21 March 2003 @ 17:01:
Ik zie nergens staan of ie garbage collection ondersteund en in welke mate hij dat doet. Dat is nl. niet verplicht volgens de Sun eisen.
Ik heb ook zo'n beetje het vermoeden dat ze het niet geïmplementeerd hebben, ik zie ook nergens documentatie, alleen iets reppen over finalisation.

uit de README:

code:

JamVM "Features"
================

For those interested in the design of virtual machines, JamVM includes a number
of optimisations to improve speed and reduce foot-print.  A list, in no
particular order, is given below.

- Uses native threading (posix threads).  Full thread implementation
  including Thread.interrupt()

- Object references are direct pointers (i.e. no handles)

- Supports class loaders

- Efficient thin locks for fast locking in uncontended cases (the
  majority of locking) without using spin-locking

- Two word object header to minimise heap overhead (lock word and
  class pointer)

- Execution engine supports basic switched interpreter and threaded
  intepreter, to minimise dispatch overhead (requires gcc value labels)

- Stop-the-world mark and sweep garbage collector

- Thread suspension uses signals to reduce supend latency and improve
  performance (no suspension checks during normal execution)

- Full object finalisation support within the garbage collector
  (with finaliser thread)

- Garbage collector can run synchronously or asynchronously within its
  own thread

- String constants within class files are stored in hash table to
  minimise class data overhead (string constants shared between all
  classes)

- Supports JNI and dynamic loading for use with standard libraries

- Uses its own lightweight native interface for internal native methods
  without overhead of JNI 

- JavaVM is written in C, with a small amount of platform dependent
  assembler, and is easily portable to other architectures.  Currently
  JavaVM supports PowerPC and Intel - port in progress to ARM (iPAQ)

Daar staat wel GB tussen.