Livello di programmazione con vari linguaggi, allocazione dinamica della memoria

[-fidel-]

@TigerShark

Beh certo che riarrangiando il codice puoi evitare il leak
Ah, ma davvero non hai mai ridimensionato un array???????

[^TiGeRShArK^]

Originariamente inviato da cionci

Sinceramente credo che con questo non possa cambiare niente...

perkè?
allocando il nuovo array all'interno del metodo e poi restituendo l'indirizzo di memoria del nuovo array il vekkio array dovrebbe andare perduto alla distruzione del metodo... o no?

[cionci]

Hi visto che l'esempio è tratto da qui: http://www-128.ibm.com/developerwork...-jtp01246.html

[VICIUS]

Originariamente inviato da -fidel-

Vediamo se ora sei più contento Prova questo:

public class LeakyChecksum {
    private byte[] byteArray;
    
    public synchronized int getFileChecksum(String fileName) {
        int len = getFileSize(fileName);
        if (byteArray == null || byteArray.length < len)
            byteArray = new byte[len];
        readFileContents(fileName, byteArray);
        // Calcola il checksum e ritorna (omesso...)
    }
}

Prova pure con Java 1.5 ad usare questa classe, guardando lo stato della memoria con un profiler. Vedrai che, fino a quando non la distruggi, il memory leak c'è eccome, ed il GC non ci fa nulla se non prendi i dovuti accorgimenti. C'è un modo per correggerla ovviamente

Non vorrei dire una bestialata. Ma in questo caso non basta mettere un
byteArray = null; una volta terminata il calcolo? In questo modo si perde l'unico riferimento alla zona di memoria e il gc puo cancellarla.

ciao

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

Arrays are fixed-length structures for storing multiple values of the same type.
http://java.about.com/od/beginningjava/l/aa_array.htm

Leggilo meglio e tutto... Poi vai a guardare una trattazione più ampia sugli array, fixed-length non è proprio esatto...

[MenageZero]

Originariamente inviato da ^TiGeRShArK^

appunto con la funzione ke ho rsicritto prima si dovrebbe evitare questo problema...
byteArray = readFileContents(fileName, byteArray);

secondo me readFileContents è ininfluente:
fermo restando che non ne conosciamo il codice, sembra che non facia altro che riempire l'array di vo0lta in volta referenziato da byteArray...

scondo me il punto è solo "byteArray = new byte[len];" (unitamente al fatto che byteArray è var di istanza), perché noi riteniamo che ogni volta venga allocato un nuovo array, mentre fidel che lo stesso array ogni volta venga aumentato di lunghezza (ma mai diminuito) se necessario.

[^TiGeRShArK^]

Originariamente inviato da -fidel-

@TigerShark

Beh certo che riarrangiando il codice puoi evitare il leak
Ah, ma davvero non hai mai ridimensionato un array???????

non lo puoi ridimensionare..
Puoi solo allocare un nuovo array della dimensione nuova perdendo il riferimento al vecchio....
Quello che dici tu lo puoi fare con arraylist, vector, e tutti gli oggetti di tipo collection.
gli Array in java sono infatti per definizione strutture a lunghezza fissa....

An array is a structure that holds multiple values of the same type. The length of an array is established when the array is created. After creation, an array is a fixed-length structure.

va meglio preso dal sito ufficiale della sun?
http://java.sun.com/docs/books/tutor...ta/arrays.html

[^TiGeRShArK^]

Originariamente inviato da VICIUS

Non vorrei dire una bestialata. Ma in questo caso non basta mettere un
byteArray = null; una volta terminata il calcolo? In questo modo si perde l'unico riferimento alla zona di memoria e il gc puo cancellarla.

ciao

ovvio.. ma mi pare piu' logico spostare la new all'interno del metodo cosi viene deallocato automaticamente il vecchio all'uscita del metodo senza porlo a null esplicitamente

[-fidel-]

Originariamente inviato da cionci

Hi visto che l'esempio è tratto da qui: http://www-128.ibm.com/developerwork...-jtp01246.html

Ahahah visto! Queste cose le ho proprio studiate dai vari whitepaper della ibm

[^TiGeRShArK^]

Originariamente inviato da -fidel-

Leggilo meglio e tutto... Poi vai a guardare una trattazione più ampia sugli array, fixed-length non è proprio esatto...

ma come non è proprio esatto???
diglielo a quelli della sun allora che hanno sbagliato la descrizione nel loro sito ufficiale
kakkio.. te lo stiamo dicendo in tre...
ti ho postato un link...
ti ho postato il link ufficiale della sun e ancora insisti che puoi variare la dimensione di un array dopo averlo allocato???

[MenageZero]

Originariamente inviato da VICIUS

Non vorrei dire una bestialata. Ma in questo caso non basta mettere un
byteArray = null; una volta terminata il calcolo? In questo modo si perde l'unico riferimento alla zona di memoria e il gc puo cancellarla.

ciao

si se si ritiene che il problema sia che l'ultimo Array istanziato "campi" almeno fino quando "campa" l'intero oggetto LeakyChekSum, ma non sembrava essere questo il punto e cmq allora semplicemente byteArray lo dichiari nel metodo, non come var di istanza

[cionci]

Originariamente inviato da ^TiGeRShArK^

perkè?
allocando il nuovo array all'interno del metodo e poi restituendo l'indirizzo di memoria del nuovo array il vekkio array dovrebbe andare perduto alla distruzione del metodo... o no?

Viene perduto anche così...infatti c'è scritto in quel link che questo metodo mette "pressione" al GC... Quindi il Garbage Collector interviene sul vecchio buffer... Il problema è il ciclo vita di byteArray...che è maggiore del suo arco di utilizzo... Ma ripeto...a me più che leak mi sembra un designa errato...

[mjordan]

Piccola pausa per festeggiare il mio compleanno ...

Originariamente inviato da ekerazha

Per cortesia risparmiami questi patetici esercizi di retorica.

Non è retorica, sono dei libri

Tu li hai letti tutti questi libri? Si parla dell'argomento di cui stiamo discutendo? In quali termini? E si parla di questo in tutti i libri o solo in alcuni? Quali? Quali argomentazioni vengono portate a sostegno delle loro tesi (e quali sarebbero le loro tesi?). Se le argomentazioni sono le stesse che hai portato tu, credo sia meglio non buttare i soldi

Certo che li ho letti.
Nessun libro fortunatamente viene pubblicato per parlare di queste cose. I primi libri che ti ho dato, in realtà, non sono libri. Sono dispense pubblicate dal Servizio Editoriale dell'Università di Pisa e sono considerate dei capisaldi dell'informatica teorica. Diciamo che trattano le basi da cui ogni linguaggio formale ha origine. Dovrebbero metterli in pubblicazione da qualche editore serio, visto che io li considero delle bibbie in merito. Dopo averli letti cambia il modo di considerare un linguaggio di programmazione. Ti da un'ottica piu' formale all'argomento. Non è tanto facile trovare simile materiale in libri commerciali, visto che è roba davvero specializzata. Per quanto riguarda il dragon book, basta studiarlo per capire da soli (senza ulteriori libri) quando un linguaggio è di alto e basso livello. Abbiamo detto che il concetto di "medio" è puramente formale e non si considera in genere nella classificazione. I puntatori esistono anche in Pascal. Secondo alcuni ragionamenti che si sono fatti, anche Pascal allora dovrebbe essere di medio/basso livello? Basta contare il numero di parole riservate per dare una stima approssimativa.

P.S.
Visto che pur non sapendo a quali progetti partecipo io dici che "scrivo software banale", mi piacerebbe molto conoscere cosa hai sviluppato TU.
Poi metteremo a confronto le due cose e vedremo chi si farà quattro risate

Io non ho detto che scrivi software banale, ho detto che chiunque partecipi in progetti non banali si rende conto che un bug (anche quelli piu' comuni) non dipendono esclusivamente dall' "attenzione", "cura del codice", "progettazione dell'architettura", tutte cose che tu invece hai elencato come "metodi" per eliminare simili bug. Il livello di attenzione, forte o debole che ognuno di noi ha, rimane "umano". Vista l'impossibilità di scrivere codice complesso senza introdurre bug comuni, è nata l'ingegneria del software. Disciplina che cerca di dare un metodo al processo. E nonostante ciò, non ha eliminato il problema. Da cui i libri che ti ho consigliato di leggere. Ti fanno rendere conto che magari esiste una complessità del software che, da come parli, evidentemente sembri ignorare. Tutto qui. E' inutile sfidarmi sul piano personale. Come non ti conosco io non mi conosci tu. Da dove proviene tutta questa certezza di "vincere"?
Posso scrivere una funzione completamente "bug free". Tuttavia il ruolo di una funzione va considerato anche sul piano semantico in relazione al codice complessivo. Quella funzione "bug free" potrebbe diventare completamente priva di senso in seguito a una modifica da un'altra parte del codice. Moltiplica il tutto per milioni di righe, strutture dati non banali che interagiscono fra loro, funzioni che si basano sul contenuto di una struttura che al minimo cambiamento diventano inconsistenti e ti rendi conto che il discorso "dell'attenzione" che facevi tu si continua ad applicare solo a software banale.
Il cervello umano riesce a gestire (male) un massimo di 3 cose contemporaneamente. E' la biologia che lo dice, non serve neanche considerare l'informatica.

[^TiGeRShArK^]

Originariamente inviato da cionci

Viene perduto anche così...infatti c'è scritto in quel link che questo metodo mette "pressione" al GC... Quindi il Garbage Collector interviene sul vecchio buffer... Il problema è il ciclo vita di byteArray...che è maggiore del suo arco di utilizzo... Ma ripeto...a me più che leak mi sembra un designa errato...

ma infatti E' un desing errato...
questo è proprio il problema del passaggio per riferimento...
facendo la new nel metodo appena chiamato e ricevendo il riferimento al nuovo vettore non si stressa per niente il GC dato che quell'oggetto viene eliminato automaticamente alla morte del metodo...
ripeto... MAI effettuare passaggi per riferimento... porta sempre a errori di questo tipo...

[^TiGeRShArK^]

Originariamente inviato da mjordan

Piccola pausa per festeggiare il mio compleanno ...

AUGURI!

[mjordan]

Originariamente inviato da ekerazha

Comunque mjordan... quei libri (dai titoli) sembrerebbero abbastanza "basilari" (tranne "Ingegneria del software", materia tra l'altro trattata nel corso di Ingegneria Informatica) e mi sembrerebbero più adatti ad un pubblico come te

Se li leggi ti accorgi che non sono proprio elementari come li consideri... Come fai a stipulare un verdetto dai soli titoli... Un qualcosa prima di essere giudicato va letto. Il Fowler che ti ho dato non è proprio banale. Ti fa rendere conto che UML non è soltanto un class diagram. Il dragon Book all'unanimità è pure considerato un testo "difficile", non adatto ai principianti e l'ho preso proprio perchè ho visto un esperto come te.
Leggili.

Tra l'altro alcuni di quelli sono poco inerenti all'argomento di discussione

L'argomento trattato non è altro che una discussione che si basa su opinioni che invece hanno fondamento in quelle discipline. Da cui i libri che ti ho citato. Prima di discutere di qualcosa ci vuole fondamento.

[cionci]

Originariamente inviato da VICIUS

Non vorrei dire una bestialata. Ma in questo caso non basta mettere un
byteArray = null; una volta terminata il calcolo? In questo modo si perde l'unico riferimento alla zona di memoria e il gc puo cancellarla.

Sì, ma l'intenzione di chi l'ha scritto (si legge sempre nel link) è cachare l'array per ottimizzarne l'accesso (ovviamente fino a quando non necessitiamo di una dimensione maggiore)...

http://www-128.ibm.com/developerwork...-jtp01246.html

[mjordan]

Originariamente inviato da ekerazha

UML non mi sembra particolarmente ostico.

UML non è soltanto costituito da Class diagram. UML può diventare terrificante. Certo non è difficile da imparare, ma provare a implementare qualcosa che risci a concepire in UML è un'altro "esercizio" per capire dove può arrivare la complessità del software. E che quindi il livello di "attenzione" non c'entra ancora nulla.

[-fidel-]

Originariamente inviato da ^TiGeRShArK^

ma come non è proprio esatto???
diglielo a quelli della sun allora che hanno sbagliato la descrizione nel loro sito ufficiale
kakkio.. te lo stiamo dicendo in tre...
ti ho postato un link...
ti ho postato il link ufficiale della sun e ancora insisti che puoi variare la dimensione di un array dopo averlo allocato???

Hai ragione scusami, sono stato molto poco chiaro. Io (ma non solo io) lo chiamo ridimensionamento, e mi spiego meglio.
Nella funzione che ho scritto, quando la lunghezza del buffer non basta più, ho bisogno di crearne un altro più grande che andrà bene. Ora, se reinstanzio la stessa variabile, la vecchia memoria viene distrutta (perdendo tutto il contenuto) e viene riallocato con la nuova dimensione (ecco il ridimensionamento. Nell'esempio il problema sta nel fatto che, una volta riallocato, il buffer NON viene cancellato dal GC perchè il suo reference NON è nel metodo ma nella classe!

[cionci]

Originariamente inviato da ^TiGeRShArK^

ripeto... MAI effettuare passaggi per riferimento... porta sempre a errori di questo tipo...

Ma dov'era il apssaggio epr riferimento prima