ARM i Java.

0

Witam.

Szukam informacji o Procesorach ARM (Advanced RISC Machine) zdolnych wykonywać Bytecode Javy.

Zapraszam do dzielenia się informacjami na ten temat i związane z nim tematy.

Wiem praktycznie tyle: http://en.wikipedia.org/wiki/ARM_architecture .

0

Ale o co chodzi? Chcesz robić za konkurencję dla Wikipedii?

Jeśli chodzi o odpalanie bajtkodu na procesorze to chodzi konkretnie o: http://en.wikipedia.org/wiki/Jazelle

0
Wibowit napisał(a):

Ale o co chodzi? Chcesz robić za konkurencję dla Wikipedii?

Jeśli chodzi o odpalanie bajtkodu na procesorze to chodzi konkretnie o: http://en.wikipedia.org/wiki/Jazelle

Dzięki za linka do Jazelle.

Zbieram informacje bo od mniej więcej 3 lat pracuję nad technologią Javową (być może nie tylko Javową), nad Językiem Programowania (który być może będzie się kompilował do Bytecode Javy), i zamierzam pracować.

1

Do niedawna Azul oferowal komercyjnie Azul Vega-3 i o ile dobrze pamietam, to byl RISC. Jestem za to wiecej niz pewien ze Vega nie posiada mikrokodow obslugujacych JVMLS ale swietnie radzi sobie ze sprzetowym wsparciem GC. Jesli interesuja Cie projekty zwiazane z przyblizeniem Javy do metalu to polecam eksperymentalnego JVMa Shark czy kody zrodlowe czegos, co kiedys nazywalo sie Managed Runtime Initiative. Zawieraja np. patche na kernel linuxa znacznie usprawniajace zarzadzanie pamiecia w managed runtimes. Pamietam tez ze widzialem tam dosc sporo kodu dla Pausless Parallel GC opartego o C4 z Zing.
A moje pytanie brzmi nastepujaco: po co Ci sprzetowy interpreter bytecode?

0
wojciech.kudla napisał(a):

Do niedawna Azul oferowal komercyjnie Azul Vega-3 i o ile dobrze pamietam, to byl RISC. Jestem za to wiecej niz pewien ze Vega nie posiada mikrokodow obslugujacych JVMLS ale swietnie radzi sobie ze sprzetowym wsparciem GC. Jesli interesuja Cie projekty zwiazane z przyblizeniem Javy do metalu to polecam eksperymentalnego JVMa Shark czy kody zrodlowe czegos, co kiedys nazywalo sie Managed Runtime Initiative. Zawieraja np. patche na kernel linuxa znacznie usprawniajace zarzadzanie pamiecia w managed runtimes. Pamietam tez ze widzialem tam dosc sporo kodu dla Pausless Parallel GC opartego o C4 z Zing.
A moje pytanie brzmi nastepujaco: po co Ci sprzetowy interpreter bytecode?

Dziękuję za odpowiedź.

Sprzętowy interpreter bytecode przyspiesza działanie programu, a przynajmniej tak mi się wydaje.

Technologia którą tworzę wymaga dużo zasobów obliczeniowych i pamięciowych, jest obliczona na efektywność w przyszłości, bo nie na teraz.

Jest to technologia która korzysta z wielowątkowości w znaczącym stopniu.

1
neomahakala108 napisał(a):

Sprzętowy interpreter bytecode przyspiesza działanie programu, a przynajmniej tak mi się wydaje.

Rozgrzane sciezki traktowane sa mnostwem optymalizacji JIT-owo/OSR-owych w assembly pod konkretne architektury, wiec nie za bardzo rozumiem jaka wartosc mialby sprzetowy interpreter pracujacy tylko przez kilka pierwszych chwil dzialania aplikacji.
Mam wrazenie ze costam przeczytales i wydaje Ci sie ze rozumiesz jak dziala JVM, ale byc moze brakuje szerszego kontekstu i wiekszego zglebienia szczegolow implementacyjnych. Powod, dla ktorego Azul zrezygnowal z konstruowania wlasnych CPU jest wlasnie taki ze optymalizacje sprzetowe dla JVM od jakiegos czasu przestaly miec sens. Wspolczesne procesory sa wystarczajaco szybkie nawet w zastosowaniach ultra-low latency.
Gil Tene wypowiadal sie na ten temat wielokrotnie. Goraco polecam prezentacje jego, lub Martina Thompsona (zwlaszcza z obszaru "mechanical sympathy").

1

Sprzętowe wykonywanie kodu jak w ARM Jazelle było po to, by uzyskać wysoką sprawność energetyczną w warunkach w których JITowanie było poza zasięgiem. Jazelle jest tylko w starych ARMach, które były łączone z żałośnie małymi ilościami RAMu i to dlatego odpalanie normalnej, rozbudowanej i efektywnej JVMki było niemożliwe.

W sytuacji w której JIT może działać dobrze, bo jest duużo RAMu, sprzętowe wykonywanie bajtkodu Javy tylko spowolni wykonywanie programu, ponieważ bajtkod Javowy nie pozwala na szereg optymalizacji które przeprowadza JIT, a z drugiej strony tworzenie sprzętowego JITa to już kompletnie walenie głową w ścianę.

Bolączką typowych JVMek jest brak pamięci podręcznej na skompilowany kod która przeżywałaby zamknięcie JVMki, tak by przy następnym odpaleniu programu JVMka mogła skorzystać z optymalizacji przeprowadzonych w poprzednim. Każdorazowo podczas odpalania JVMki JITowane jest wszystko od nowa i dlatego programy Javowe startują dość wolno w porównaniu do programów natywnych.

0

Firma IS2T promuje i dostarcza narzędzia potrzebne m.in. do używania Javy na architekturach ARM:
http://www.is2t.com/
http://www.masters.com.pl/cs/files/art-masters-stm32-java.pdf

Lista obsługiwanych MCUs firmy STM32:
http://www.stm32java.com/products/java-ready-stm32-mcus/

1 użytkowników online, w tym zalogowanych: 0, gości: 1