Moja poprzednia wersja, chociaż nie była fałszywa, była szybko napisanym uproszczeniem.
Zmiana z 32 na 64 bity nie spowoduje automatycznego przyspieszenia działania aplikacji, może to w niektórych przypadkach doprowadzić do odwrotności. Po stronie "ujemnej" Odsadzanie wskaźników pamięci w JVM może trwać dłużej ze wskaźnikami 64-bitowymi niż 32-bitowymi. Pełne zbieranie śmieci i zagęszczanie sterty o wielkości 16 GB prawdopodobnie zajmie więcej czasu niż w przypadku sterty 2 GB.
Po stronie pozytywów: Są tam 64-bitowe instrukcje procesora, które są bardziej skuteczne niż te 32-bitowe. 64-bitowa maszyna JVM pozwoli ci mieć rozmiar sterty 2^32 razy większy niż ten, nieco mniejszy niż 4 GB, który możesz uzyskać za pomocą 32-bitowego. (Jeśli możesz pozwolić sobie na zakup takiej ilości pamięci RAM) Niektóre maszyny JVM mogą pracować ze skompresowanymi referencjami, jeśli masz rozmiar sterty mniejszy niż 4 GB, co daje ci przewagę 64-bitowych instrukcji bez konieczności płacenia 64-bitowej ceny porównawczej .
Jeśli masz dobrą maszynę JVM, udałbym się na 64 bity, bez względu na wielkość sterty, po prostu przygotuj się, że być może będziesz musiał wykonać uderzenie wydajności, aby mieć naprawdę dużą stertę.
Czy korzystanie z większej ilości pamięci niż około 1,5 GB nie jest jedną z korzyści, przynajmniej w systemie Windows? Jest taki limit dla 32-bitowego procesu Java. http://mystyleit.com/blogs/mystyleit/archive/2009/05/27/32bit-windows-memory-and-java.aspx – Jonik
Czy najnowsze 64-bitowe maszyny JVM nie są jednak mądrzejsze w przydzielaniu referencji? To znaczy, używając tylko 32-bitowych odniesień, jeśli nie potrzebuje pełnego 64-bitowego. Myślę, że gdzieś to przeczytałem. –