90

Ben tu peux faire du swap avec, si un HeapAlloc/Realloc échoue après un GC de la RAM : tu y passe tous les handles non lockés, et à leur prochain deref tu tentes de les rebasculer en RAM s'ils sont en swap. Et si ya plus de RAM quand tu veux y redescrendre un handle, tu kill l'appli. smile

et au fait, pourquoi cette section est-elle définitivement inutilisable ? confus

91

parce que c'est la section qui contient les certificats ? grin

j'avais apprécié la manoeuvre aussi trioui

92

Ah merde trigni Mais ça empêcherais pas de créer un swap hehe

93

J'ai une idée, pour ce qu'elle vaut :
Utiliser une table référençant les fichiers dans la VAT :
- 4 octets par entrée : 2 octets pour le handle, 2 pour le compteur de lock
On démarre avec une table vide, seuls les fichiers se faisant locker recevront une entrée dans la table.

- En cas de Hlock/HeapLock, on regarde si le handle est dans la table, et on met à jour son compteur le cas échéant.
- Si le handle n'est pas dans la table, on regarde dans la VAT si c'est le handle d'un fichier pour lui créer une entrée le cas échéant (entrée initialisée à l'état du handle _avant_ le lock *)

- En cas de HeapUnlock, on décrémente le compteur si le handle est dans la table.

- En cas de HeapGetLock, on regarde dans la table, et on renvoie "locké" si c'est le cas, évidemment. Si la table ne contient pas l'entrée désirée, on parcours la VAT pour y chercher le handle et connaitre son état.

- En cas de Archive/Unarchive, on modifie le handle dans la table s'il existe. (?!? c'est pas une grosse connerie ça ?!?)

- En cas de HeapFree(Ptr), on efface l'entrée de la table s'il y en a une.

* Le cas àlakon est le cas où un programme ajoute un handle déjà locké à un symbole qu'il vient d'ajouter : on perd à ce moment-là la synchronisation VAT/Table. C'est pour ça qu'il faut se référer à la VAT dans certains cas.

Je ne vois pas d'autres cas pièges qui impliquent une telle vérification.

94

squalyl (./8) :
je suis sincère et même si je release pas , j'ai un vaporware secret qui est en train de se concrétiser. il pourrait même relacer l'intéret pour la plate forme si je me démerde bien.

pouet pouet poueeeeeeeeeeeeet !!!!! cheeky

95

BTW -> 12 octets de gagnés encore 891 -> 879
Mais j'ai rarement vu un code aussi imbitable, je dois être au niveau de GCC sur ce coup trioui

96

merde je parlais de quoi? cheeky

bon enfin là c'est rapé même pour 2042 quoi.

97

J'aurais mis mon billet sur une JVM moi grin

98

ah oui c'était bien ça.

bon, y'a des mois que j'ai pas touché au code, j'ai des soucis techniques au niveau du bootstrap. c'est vraiment du code qui se marche sur les pieds.

99

Folco (./9) :
#baaaaaaaaaaaaaaaaaaaaaaaaaveeeeeeeeeee#

• Folco file un ou deux ko de motivation à squalyl !!!!!!!!!!!!!!!!!!!!!!!!!!!!

Aller, bouge-toi le cul ! grin

100

sincèrement, ça intéresse vraiment quelqu'un a part moi et apparemment toi? cheeky

ce sera du CLDC.

101

Sincèrement, vraiment ? cheeky
(100 ! #banana#)

102

bah y'a rien qui l'empêche en fait.

ça tournait déja sur pocket pc et windows y'a un petit bout de temps.

j'ai recommencé une v2 from scratch parce que la v1 était vraiment mal foutue.
mais je sais toujours pas comment faire un chargement de classes correct.

parce que pour charger la classe java.lang.Class, faut charger la classe java.lang.Class triso, et je sais pas trop comment faire. Pour le moment c'est assez crade, je la charge "aux trois quarts" puis je mets un truc à jour au chargement de classe suivant.

puis j'ai aucune idée de comment faire un garbage collector EN PRATIQUE

puis je cherche un moyen de stocker efficacement les chaines de caractères sans bouffer trop de place. Ca risque de commencer par un stockage contigu.

et dans tout ça le problème, ça reste d'avoir à écrire le moins de code natif nécessaire, et faire un max de trucs en java.

bref en tout cas, en ce moment je bloque sur ça.