0000058: Excessive memory usage in ocamljava compiled programs - Mantis

Mantis Bugtracker

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

Problem-Beziehungen

Notiz
(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.

Problem-Historie
Änderungsdatum	Benutzername	Feld	Änderung
2010-02-08 04:27	akemp	Neues Problem
2010-02-08 18:42	xclerc	Problemnotiz hinzugefügt: 0000207
2010-02-08 18:42	xclerc	Bearbeitung durch	=> xclerc
2010-02-08 18:42	xclerc	Status	neu => Rückmeldung
2010-02-08 18:47	akemp	Problemnotiz hinzugefügt: 0000208
2014-07-15 00:27	xclerc	Problem beobachten: xclerc
2014-07-15 00:27	xclerc	Problemnotiz hinzugefügt: 0000285
2014-07-15 00:27	xclerc	Status	Rückmeldung => geschlossen
2014-07-15 00:27	xclerc	Lösung	offen => erledigt

Mantis 1.1.7[^]

Copyright © 2000 - 2008 Mantis Group