De term “virtuele machine” wordt binnen de IT op minstens twee verschillende manieren gebruikt. De tegenwoordig gangbare interpretatie is afgeleid van hardwarevirtualisatie en de bijbehorende hypervisors (zoals VMware ESX en andere): een virtuele machine is dan een door software nagebootste representatie van een volledig computersysteem (CPU, memory, I/O).
Bij met name Java ontwikkelaars heeft de term echter meestal een geheel andere betekenis: die van een runtime omgeving voor een applicatie-proces binnen het operating systeem. Om dit onderscheid te maken worden de laatste ook wel “process virtual machines” of “application virtual machines” genoemd. De Java-specifieke naam is “Java Virtual Machine”, oftewel JVM.
Een vraag die nu opkomt is de volgende: gedraagt een Java applicatie – met een JVM – zich anders binnen een hypervisor – zoals VMware ESX – dan een willekeurig andere applicatie? Met andere woorden, moet je voor een Java-applicatie binnen ESX rekening houden met het feit dat ook Java zelf al een virtuele machine in zich heeft?
Het antwoord is “tot op zekere hoogte“. En om dit nader uit te leggen heeft VMware een goede white paper geschreven. De essentie daarvan is:
- Het memory-gebruik van Java applicaties is nogal anders dan van een willekeurig andere applicatie.
Dit betreft met name de zogenoemde “heap” en de bijbehorende “garbage collector”. - Het aantal virtuele CPU’s binnen de ESX virtuele machine is van grote invloed op de performance en vergt meer fine-tuning.
Dit is onder andere een gevolg van de manier waarop JVM zelf al gebruikt maakt van multi-threading. - Het aantal JVM applicaties binnen elke ESX virtuele machine is bij voorkeur beperkt tot één.
Ook dit heeft alles te maken met de toekenning van virtuele CPU’s en de manier waarop ESX je daarbij middels Distributed Resource Scheduling (DRS) kan helpen.
De white paper zelf beschrijft e.e.a uiteraard in veel meer detail en is hier als een PDF-document van 16 pagina’s te downloaden.
