anonym | Anmelden | Neues Konto anmelden | 2021-01-24 13:06 UTC |
Startseite | Übersicht | Probleme anzeigen | Änderungsprotokoll | Roadmap | Dokumentation | Konto |
Einfache Problemansicht anzeigen [ Zu Notizen wechseln ] | [ erweiterte Anzeige ] [ Problem-Historie ] [ Drucken ] | ||||||
ID | Kategorie | Auswirkung | Reproduzierbar | Meldungsdatum | Letzte Aktualisierung | ||
0000058 | [Cafesterol] general | schwerer Fehler | nicht getestet | 2010-02-08 04:27 | 2014-07-15 00:27 | ||
Reporter | akemp | Anzeigestatus | öffentlich | ||||
Bearbeitung durch | xclerc | ||||||
Priorität | normal | Lösung | erledigt | ||||
Status | geschlossen | Produktversion | 1.4 | ||||
Zusammenfassung | 0000058: Excessive memory usage in ocamljava compiled programs | ||||||
Beschreibung |
I was interested to see that ocamljava brought OCaml to the JVM, so wanted to see how it performed. I grabbed the nbody code from the shootout (see http://shootout.alioth.debian.org/u64q/program.php?test=nbody&lang=ocaml&id=1) [^] and compiled it with both ocamlopt and with ocamljava. The ocamlopt version uses constant memory (and is faster); the ocamljava version is slower largely because it uses *tons* of memory and does *tons* of GCs. See: http://www.alsonkemp.com/wp-content/uploads/ocamljava.profile.png [^] (from Sun's VisualVM) The image shows a small fraction of the Finalizer and Block objects that were created over the life of the program. The nbody program is creating tons of blocks and then releasing them. ocamljava looks like an impressive piece of work, so I hope this feedback is useful to you. |
||||||
Zusätzliche Information | |||||||
Tags | Keine Tags zugeordnet. | ||||||
Angehängte Dateien | |||||||
|
![]() |
|
(0000207) xclerc (Administrator) 2010-02-08 18:42 |
Thanks for the feedback. I was already aware of the memory problem; indeed ocamljava is much slower than other JVM-language mainly because of this problem. Some early design decisions I made before I grasped the whole picture turned out to be disastrous regarding memory usage. And excessive memory usage trashes the garbage collector and makes programs run slowly... On the bright side, the version labeled 1.4 released a few day ago is quite probably the last one in the 1.x series. Version 2.0 will feature an optimized memory model to fight the problem you report. The changes were not made before because I wanted to have a full proof of concept before working on performances isssues, and because the changes will break compatibility with existing code. The goal is to have a version with decent performances for JDK 7 release. So, stay tuned but do not hold your breath... |
(0000208) akemp (Reporter) 2010-02-08 18:47 |
Figured as much, but wanted to make sure. I'm excited about the prospect of a good functional language for the JVM (I'm not a fan of Scala), so I look forward to OcamlJava 2.0. |
(0000285) xclerc (Administrator) 2014-07-15 00:27 |
The new version available at http://www.ocamljava.org [^] should resolve these problems. |
Mantis 1.1.7[^] Copyright © 2000 - 2008 Mantis Group |