Newsgroup: it.comp.programmare.win32
Titolo: aiuto malloc

Compilo con VC++ 6 prof, ho una applicazione SDI e ho bisogno di memoria (se
e' evitabile new e delete e' meglio, sto portando una vecchia applicazione
per DOS).
La domanda (da novellino): e' possibile usare impunemente malloc, calloc,
realloc ecc. ecc. in win32?
Quanta memoria posso mallocare (non so se usa l'heap del sistema o lo spazio
del processo)?
Grazie,
Marco

,

Nelle implementazioni del runtime C  e C++ che conosco, le varie
new e/o malloc finiscono per chiamare la API HeapAlloc(), che a sua
volta chiama la API non esposta RtlAllocateHeap().
L'heap di default del processo viene specificato quanto a dimensione
al momento del linking.
Se l'heap di defalt non dovesse soddisfarti puoi sempre creare
un Heap privato di dimensione "arbitraria" (il limite e' dato
dalla memoria disponibile, dall swap settato, e da quanta memoria
stanno usanto gli altri processi). Comunque l'heap di default
viene esteso automaticamente quando dovesse "esaurirsi".
Se le tue allocazioni/deallocazioni hanno una politica di gestione tale
per cui l'Heap non dovesse soddisfarti, allora esiste la
API VirtualAlloc() che riserva e/o impegna porzioni dello spazio di
indirizzamento del processo. BTW, VirtualAlloc viene usata dall'OS
quando si tratta di creare un nuovo Heap o di estenderne uno esistente.
Alcune applicazioni traggono beneficio dall'uso di File Mappati in
memoria, specialmente se la memoria viene usata per leggere da/verso
un file, elaborare i dati e poi riscriverli.
Tipicamente, se fai delle malloc() consistenti, allora l'Heap di
default, pur continuando a funzionare egregiamente, tende a diventare
inefficiente. VirtualAlloc viene consigliata in questi casi.
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 del processo)?
Se non hai fatto "stranezze" di configurazione di sistema, dipende anzitutto dal
tuo disco fisso, e da quanto spazio libero tu abbia su di esso.
Se hai un bel disco grande e pulito, entra in gioco la limitazione dello
spazio di indirizzi tipica dei processori a 32 bit; normalmente, nei S.O.
Microsoft, il limite sarebbe sotto i _2 giga_ (ridicolmente poco, visto
quanto poco costa oggi un bel disco da 10 giga o piu`); con qualche
trucco si puo` arrivare a 3 giga (solo su NT, mi pare -- non sui sistemi
giocattolo come Win95); e con trucchi ulteriori, si possono usare piu`
bit di indirizzo (solo su NT Server, mi pare; o, su Win2000) e avere
un minimo di respiro (ma i giga in piu` di memoria non sono semplici
da usare intercambiabilmente agli altri; non e` un caso che si corra
velocemente verso i 64 bit...!-).
Naturalmente, se si allocano molti giga di memoria, bisogna stare
attenti a come li si usa, perche`, se la memoria allocata e` molto
superiore a quella fisica, si puo` altrimenti rischiare il "trashing"
del disco -- le prestazioni crollano man mano che il sistema passa
tutto il suo tempo a scambiare pagina da memoria fisica a disco e
viceversa.  Se non usi disciplina e attenzione nell'accesso a grandi
memorie virtuali, indicativamente, non superare, grosso modo, un
fattore 2 o 3 rispetto alla memoria fisica disponibile come working
set -- con 128 M di memoria fisica, ad esempio, non dovresti
superare di molto i 200-300 mega allocati (non e` un limite rigido,
solo una indicazione al di la` della quale le tue prestazioni avranno
seri problemi... a meno che tu non stia attento a _come_ la usi,
quella memoria!-).  Nulla di nuovo rispetto ai problemi che, sui
mainframe, abbiamo da 30 anni o piu`, naturalmente.
Una "novita`" (spiacevole!-) e` che i SO moderni tendono a
permettere di mischiare lo spazio disco riservato per memoria
virtuale ("paging space") con quello usato per i file.  E` bello,
per un verso, perche` rende facilissimo il "memory mapping"
di un file; pero`, si rischia che lo spazio disco usato per la
paginazione soffra di frammentazione, con un ulteriore crollo
di prestazioni.  Su Linux, avevo sempre suggerito di farsi una
partizione apposta, dedita esclusivamente alla paginazione.  Su
Win/95, non vale probabilmente la pena, ma, almeno, ricordarsi
di de-frammentare SPESSO.  Su /NT, e` una decisione non facile,
perche` molto, troppo, dipende da come la macchina viene
usata.  Chi, facendo calcoli scientifici, usa memorie virtuali
gigantesche (accedute con disciplina:-) trarra` probabilmente
abbastanza beneficio, su NT, perche` valga la pena di allocare
in anticipo (e deframmentare) il paging-file -- evitando come la
peste qualsiasi eventuale partizione FAT (meglio non averne
proprio -- NTFS e` un filesystem assai migliore, comunque).
Ma qui stiamo scivolando decisamente sulla system administration,
piu` che non sulla programmazione, quindi forse e` meglio
passare per queste discussioni ad altri gruppi.
Alex

Non danno ne` piu`, ne` meno, problemi, che su qualsiasi altra piattaforma.
Mille grazie.
Marco

Ciao,
puoi usare malloc() senza problemi, non saprei dirti se ci sono
dei limiti rispetto ad es. alla VirtualAlloc() dell'API, ma probabilmente
no.
ciao, Franco.
--
Posted from [194.184.225.66] by way of 
law2-oe21.hotmail.com
 [216.32.180.125]
via Mailgate.ORG Server - 
http://www.mailgate.org


Che intendi "consistenti" ?
Io ho fatto una dll che in modo massiccio delle allocazioni, la maggior
parte con new/delete ed alcune con malloc/realloc/free su dei buffer per
ottimizzarne le prestazioni, visto che per estendere un'area di memoria
posso utilizzare la realloc invece che fare la new[]/memcpy/delete[].
Il problema e: Devo usare particolari accorgimenti se il client della mia
dll chiama le API exportate dalla libreria e magari lo stesso client
alloca/disalloca aree di memoria allocate dalla libreria ???
Grazie, ciao Lvca.

 alloca/disalloca aree di memoria allocate dalla libreria ???
Altro che se devi...!
_Esporta dalla tua API_ la funzione da usarsi per liberare cio`
che tu hai allocato.  E` l'unica cosa sensata: cosi`, se un
domani invece di malloc vuoi usare new[], o che altro, o
se il tuo cliente non ha _esattamente_ lo stesso release di
compilatore che hai tu, o se uno dei due lati si vuole
linkare staticamente alle runtime, .... (infiniti problemi
snippati:-) .... , tutto va a posto comunque.
Alex

inefficiente. VirtualAlloc viene consigliata in questi casi.
Intanto grazie mille,
se per "consistenti" intendi come dimensione del blocco allocato allora c'e'
qualche malloc "pesante" (un blocco da 64M e alcuni blocchi minori), ma lo
spazio viene richiesto una volta sola all'inizio e rilasciato alla fine.
Spero che questo non pregiudichi le prestazioni... e' cosi'?
Marco

 wrote in message
news:82jfov$ljq$1...@serv1.iunet.it...


 giusto ???
Giusto, eccetto che, invece che metodi di classe, io ne farei
delle funzioni extern "C", cosi` un domani puo` chiamarle
senza impazzire chi usa altri release di compilatore, che
chissa` cosa fanno sul "name mangling" (o anche lo stesso
compilatore con opzioni di compilazione appena appena
diverse...).  A causa delle differenze, magari di dettaglio,
su name mangling, object model/layout, ecc, e` sempre
meglio che cio` che si rende visibile sull'interfaccia di una
DLL sia "pulito pulito" (funzioni extern "C"), se appena
appena e` possibile (e qui lo e`, nel senso che vederle
come appartenenti a classe ha modesto valore aggiunto).
Incidentalmente, il COM adotta questo approccio, eccetto
che tutte le varie funzioni le vede naturalmente come
membri di una _interfaccia_ COM (IMalloc) di cui puoi
avere un puntatore con l'API CoGetMalloc (ma riveste
anche i casi comuni con CoTaskMemAlloc, equivalente a
una opportuna CoGetMalloc seguita dalla chiamata alla
funzione Alloc di quell'interfaccia; CoTaskMemFree,
analogamente; ecc).  Questo, oltretutto, permette la
"trasparenza" (fra alloc e free) anche fra processi
diversi e persino fra macchine diverse...
Alex