Java et désallocation explicite

François-Gérard wrote:

Bonjour,

je sais que le Java ne permet pas la désallocation explicite.
Néanmoins je voudrais savoir si il y a un moyen de la "forcer".
Ce que je veux dire par là, c'est est-ce qu'il existe des classes
de "haut-niveau", haut-niveau dans le sens ou elles permettent de faire
ds choses vraiment intéressantes et que le "programmeur de base"
n'utilise pas forcément tous les jours (comme les classes de
java.lang.reflect ou le chargement à chaud de plugin), qui permettraient
de faire ça ?

Si non, y-a-t il des projets indépendants de Sun et qui font ça ?

Si la réponse est non là aussi, qu'elle devrait être l' "astuce" pour
réaliser cela ? Est-ce qu'on peut le faire d'une manière pas très
catholique, mais relativement "facilement", est-ce que ça nécessiterai
de créer une JVM, etc .... ?

Merci d'avance.

François-Gérard

D'ailleurs je viens d'avoir une idée. Est-ce qu'on ne pourrait pas
modifier le memory manager, qui à mon avis doit être écrit en C grâce
à la JNI, pour le forcer à faire des désallocations explicites.
Je me rends bien compte que ce que je demande est un peu "fou", mais
ça pourrait être le sujet d'un projet perso ou d'un sujet de TER
pour mon Master à la fac qui m'intéresserait bien.

François-Gérard

François-Gérard,

Je me rends bien compte que ce que je demande est un peu "fou", mais
ça pourrait être le sujet d'un projet perso ou d'un sujet de TER

Il existe plusieurs JVM dont le code source est disponible et qui
pourraient se prêter à ce type d'expérimentation : SableVM, LaTTe,
Kaffe, Japhar, etc.

Sous réserve de ne pas se faire d'illusion sur la possibilité de les
utiliser pour faire tourner des applications "industrielles", elles
peuvent servir de base à des variations très diverses par rapport au
standard Java.

Laurent

Laurent Bossavit wrote:

François-Gérard,

Je me rends bien compte que ce que je demande est un peu "fou", mais
ça pourrait être le sujet d'un projet perso ou d'un sujet de TER

Il existe plusieurs JVM dont le code source est disponible et qui
pourraient se prêter à ce type d'expérimentation : SableVM, LaTTe,
Kaffe, Japhar, etc.

Sous réserve de ne pas se faire d'illusion sur la possibilité de les
utiliser pour faire tourner des applications "industrielles", elles
peuvent servir de base à des variations très diverses par rapport au
standard Java.

Laurent

Merci pour ta réponse !

Je crois que c'est ce que je vais faire.

Mais à tout hasard est-ce qu'il n'y aurait pas moyen de modifier le code
(écrit en C je pense) d'une classe Java en gestion de la mémoire et qui
pourrait s'appeler genre MemoryAllocator.
Le but serait donc de trouver le source de cette classe en question,
j'imagine qu'il doit y en avoir une, surement une classe système.
Et en se basant sur ce source écrire une classe MonAllocateurPerso
qui aurait comme méthodes Object alloueDynamiquement(String nomObjet)
ou Object alloueDynamiquement(Class objet) et void
desallocationExplicite(Object objet).

Ceci me permettrait donc de créer et de détruire des objets mais
uniquement en faisant appel explicitement à MonAllocateurPerso, car mon
but n'est pas de faire changer le comportement par défaut de Java qui ne
désalloue rien et laisse faire le GC, car là ça serait beaucoup plus tendu.

François-Gérard

je sais que le Java ne permet pas la désallocation explicite.
Néanmoins je voudrais savoir si il y a un moyen de la "forcer".
Ce que je veux dire par là, c'est est-ce qu'il existe des classes
de "haut-niveau", haut-niveau dans le sens ou elles permettent de faire
ds choses vraiment intéressantes et que le "programmeur de base"
n'utilise pas forcément tous les jours (comme les classes de
java.lang.reflect ou le chargement à chaud de plugin), qui permettraient
de faire ça ?

Si non, y-a-t il des projets indépendants de Sun et qui font ça ?

Si la réponse est non là aussi, qu'elle devrait être l' "astuce" pour
réaliser cela ? Est-ce qu'on peut le faire d'une manière pas très
catholique, mais relativement "facilement", est-ce que ça nécessiterai
de créer une JVM, etc .... ?

Ca vole haut là, je pense que ma réponse est un peu basique, mais on peut
appeler le garbage collector avec System.gc()...

Lilian

François-Gérard wrote:

Bonjour,

je sais que le Java ne permet pas la désallocation explicite.
Néanmoins je voudrais savoir si il y a un moyen de la "forcer".
Ce que je veux dire par là, c'est est-ce qu'il existe des classes
de "haut-niveau", haut-niveau dans le sens ou elles permettent de faire
ds choses vraiment intéressantes et que le "programmeur de base"
n'utilise pas forcément tous les jours (comme les classes de
java.lang.reflect ou le chargement à chaud de plugin), qui permettraient
de faire ça ?

Si non, y-a-t il des projets indépendants de Sun et qui font ça ?

Si la réponse est non là aussi, qu'elle devrait être l' "astuce" pour
réaliser cela ? Est-ce qu'on peut le faire d'une manière pas très
catholique, mais relativement "facilement", est-ce que ça nécessiterai
de créer une JVM, etc .... ?

Merci d'avance.

François-Gérard

Une question bête : pourquoi faire ?
Je ne dis pas que ta question n'est pas sensée mais je ne vois pas
d'application ...

Pour les systèmes temp réel, qui nécessitent des temps de réponse
prévisibles, il existe des JVM adaptées avec des algorithmes de garbage
collection adaptés.



Cédric

Une question bête : pourquoi faire ?
Je ne dis pas que ta question n'est pas sensée mais je ne vois pas
d'application ...

Pour les systèmes temp réel, qui nécessitent des temps de réponse
prévisibles, il existe des JVM adaptées avec des algorithmes de garbage
collection adaptés.



Cédric

En fait ça serait soit pour moi comme ça pour le plaisir de le faire :-)
quand j'aurais du temps ... soit pour proposer ça comme sujet de TER
pour le Master Informatique dans lequel je suis.

L'intérêt, et attention je ne veux aucunement troller, c'est que
personnelement je trouve que Java c'est super vu qu'il y a une API
excellente qui peut à peu près tout faire, et que bon c'est bien
sympathique de pas avoir à se farcir les delete ou les free dans des
parties de code simples et non "critiques", mais que dans un programme
qui ferait énormément d'allocations mémoire (pas nécessairement de
grosses allocations mais des allocations répétées), et qui devrait être
aussi à peu près aussi rapide que du C/C++ là je trouve que AMHA ça pose
problème.

Alors bon on peut forcer l'appel au GC mais bon ça va freezer le
programme surtout si il y des interfaces graphiques. On peut aussi
allouer un pool d'objets au lancement et s'en servir quand on a besoin
d'objets, mais bon j'aimerai pouvoir dans certains cas, donc je ne dis
pas que le GC ça soit nul en soit, mais donc pouvoir dans certains cas
où cela améliorerait énormément la consommation mémoire, pouvoir forcer
les désallocations.

Pour résumer, jusqu'au début de l'année universitaire j'étais "faché"
avec Java car je préferait nettement le C/C++ mais j'ai eu droit à des
cours vraiment intéressant ce qui m'a réconcilié avec le Java!
Voilà donc le seul truc qui me chagrine toujours un peu c'est de ne pas
pouvoir, dans des cas bien particuliers, forcer la désallocation mémoire.

Donc je me dis si je peux proposer un projet qui permettrai d'utiliser
toute la puissance de Java : excellente API, refléxivité, Java-Bean,
JDBC, plug-in etc..., et à la fois pouvoir forcer la désallocation ça
serait le pied !!!
D'ailleurs je suis sûr que du coup certains programmeurs C/C++
complètement hermétiques car "mariés" à free/delete et ne voulant pas
entendre parler de Java, pourrait du coup y trouver un nouvel intérêt.

Voilà.

François-Gérard

Tu lis aussi le NG fr.comp.lang.c++ ?, il y a quelques semaines il y
a eu un débat sur l'utilisation d'un GC en c++, des implementations
existent, je pense que le thread peut t'interesser (courant décembre voir
novembre mais pas avant).

Coté gestion mémoire soit on le fait a la mode c/c++ c'est a dire à
la main, soit on utilise un GC, maintenant quand est il du fait
de faire cohabiter les 2 cela ne me semble pas évident :s

De toute facon qui dit gc, dit asynchronisme, donc thread, on se retrouve
donc avec un gc qui sollicite la mémoire(new,delete), et le thread principale qui
sollicite aussi avec la mémoire (new,delete).

A mon avis il faut faire le choix au debut, soit on fonctionne en GC (asynchrone),
soit en gestion de la mémoire par new,delete (synchrone).

Qu'en pensez vous ?

Une question bête : pourquoi faire ?
Je ne dis pas que ta question n'est pas sensée mais je ne vois pas
d'application ...

Pour les systèmes temp réel, qui nécessitent des temps de réponse
prévisibles, il existe des JVM adaptées avec des algorithmes de garbage
collection adaptés.



Cédric

En fait ça serait soit pour moi comme ça pour le plaisir de le faire :-)
quand j'aurais du temps ... soit pour proposer ça comme sujet de TER
pour le Master Informatique dans lequel je suis.

L'intérêt, et attention je ne veux aucunement troller, c'est que
personnelement je trouve que Java c'est super vu qu'il y a une API
excellente qui peut à peu près tout faire, et que bon c'est bien
sympathique de pas avoir à se farcir les delete ou les free dans des
parties de code simples et non "critiques", mais que dans un programme
qui ferait énormément d'allocations mémoire (pas nécessairement de
grosses allocations mais des allocations répétées), et qui devrait être
aussi à peu près aussi rapide que du C/C++ là je trouve que AMHA ça pose
problème.

Alors bon on peut forcer l'appel au GC mais bon ça va freezer le
programme surtout si il y des interfaces graphiques. On peut aussi
allouer un pool d'objets au lancement et s'en servir quand on a besoin
d'objets, mais bon j'aimerai pouvoir dans certains cas, donc je ne dis
pas que le GC ça soit nul en soit, mais donc pouvoir dans certains cas
où cela améliorerait énormément la consommation mémoire, pouvoir forcer
les désallocations.

Pour résumer, jusqu'au début de l'année universitaire j'étais "faché"
avec Java car je préferait nettement le C/C++ mais j'ai eu droit à des
cours vraiment intéressant ce qui m'a réconcilié avec le Java!
Voilà donc le seul truc qui me chagrine toujours un peu c'est de ne pas
pouvoir, dans des cas bien particuliers, forcer la désallocation mémoire.

Donc je me dis si je peux proposer un projet qui permettrai d'utiliser
toute la puissance de Java : excellente API, refléxivité, Java-Bean,
JDBC, plug-in etc..., et à la fois pouvoir forcer la désallocation ça
serait le pied !!!
D'ailleurs je suis sûr que du coup certains programmeurs C/C++
complètement hermétiques car "mariés" à free/delete et ne voulant pas
entendre parler de Java, pourrait du coup y trouver un nouvel intérêt.

Voilà.

François-Gérard

--
Cordialement,

Patrice Trognon
http://wwW.javadevel.com

l'appel du gc n'implique pas que les objets dé-référencés soient
recupérés par le gc, si ca lui coute trop cher il laisse pour
un prochain appel.

je sais que le Java ne permet pas la désallocation explicite.
Néanmoins je voudrais savoir si il y a un moyen de la "forcer".
Ce que je veux dire par là, c'est est-ce qu'il existe des classes
de "haut-niveau", haut-niveau dans le sens ou elles permettent de faire
ds choses vraiment intéressantes et que le "programmeur de base"
n'utilise pas forcément tous les jours (comme les classes de
java.lang.reflect ou le chargement à chaud de plugin), qui permettraient
de faire ça ?

Si non, y-a-t il des projets indépendants de Sun et qui font ça ?

Si la réponse est non là aussi, qu'elle devrait être l' "astuce" pour
réaliser cela ? Est-ce qu'on peut le faire d'une manière pas très
catholique, mais relativement "facilement", est-ce que ça nécessiterai
de créer une JVM, etc .... ?

Ca vole haut là, je pense que ma réponse est un peu basique, mais on peut
appeler le garbage collector avec System.gc()...

Lilian

--
Cordialement,

Patrice Trognon
http://wwW.javadevel.com

François-Gérard wrote:

Bonjour,

je sais que le Java ne permet pas la désallocation explicite.
Néanmoins je voudrais savoir si il y a un moyen de la "forcer".
...

pour le programmeur de base on a 2 méthode :
- System.gc pour demander au system de penser a garbager ....
mais ca peu être contre productif car une bonne jvm le fait quand
c'est nécessaire (une barrière a été franchie)
- mettre les pointeurs a null
ca peut parraitre évident mais souvent certains programmeurs
gardent des variables inutiles longtemps, dans des variables locales
ou dans des conteneurs (map...)

d'ailleurs a mon avis mettre a nul est un cache misère. le plus propre
c'est d'utiliser un bloc et d'y mettre les variables locales...

pluto que
{
Toto t=getGrosToto();
run(t);
t=null; // pour autoriser le garbage
Toto t2=getGrosToto()
runWith(t2);
}
je préfère
{
{
Toto t=getGrosToto();
run(t);
}
{
Toto t2=getGrosToto()
runWith(t2);
}
}
qui enplus évit de se tromper de variable...

sinon il faut savoir qu'avec les JVM récente la désalocation est plus
efficace qu'en C++. en effet la plupart sont des GC générationels ou
il y a une zone pour les objets récents qui ont de bonne chance d'être
détruits rapidement, puis des zone de plus vieux et de très vieux
qui sont rarement détruits et donc rarement garbagés...

en plus les GC modernes sont "concurents" et "incrémentaux", et gênen
assez peu l'exécution... le seul soucis c'est qu'il faut savoir les
régler (taille des zones d'objets permanents, ancien ou jeunes)

none wrote:

L'intérêt, et attention je ne veux aucunement troller, c'est que
personnelement je trouve que Java c'est super vu qu'il y a une API
excellente qui peut à peu près tout faire, et que bon c'est bien
sympathique de pas avoir à se farcir les delete ou les free dans des
parties de code simples et non "critiques", mais que dans un programme
qui ferait énormément d'allocations mémoire (pas nécessairement de
grosses allocations mais des allocations répétées), et qui devrait être
aussi à peu près aussi rapide que du C/C++ là je trouve que AMHA ça pose
problème.

Pour faire ce genre de choses, la Bonne Méthode A Suivre en Java est
d'utiliser le paquetage java.lang.ref. Je te laisse le découvrir, peut être
ai-je mal compris ce que tu cherches de toutes façons, et si cela te parait
jouable, n'hésite pas à poser de nouvelles questions, j'essaierai d'y
répondre.


--
Hervé AGNOUX
http://www.diaam-informatique.com