2010-06-29 2 views
7

Quando stavo imparando .NET l'ho visto come una piattaforma che esegue i miei programmi .NET che ha il suo Stack & Heap.Framework .NET dal punto di vista di un programmatore di basso livello

Ma ora, dopo aver appreso di più sulle cose, vedo un'applicazione .NET come qualsiasi altra applicazione nativa C/C++. Si trova nel formato di file Portable Executable (PE) con la nuova directory di dati &. La sezione di testo è piena di codice MSIL invece di codice macchina. L'unica differenza sono le DLL (che sono considerate piattaforme .NET) (come qualsiasi altra dipendenza Dll) caricate.

Suppongo che al punto di ingresso ci sia un codice macchina che richiama la DLL caricata (piattaforma .net) e le funzioni di tali DLL leggono l'MSIL dalla sezione .text (il segmento è più corretto) e generano una macchina equivalente codice e metterlo in una sorta di buffer (non so quale area sarebbe esso. Non posso essere .text & .Data come sono readonly. saranno stack o heap?). Quindi fai in modo che l'EIP faccia riferimento a questo buffer di istruzioni. Le ultime poche istruzioni richiamano nuovamente in DLL per ripetere il processo per il resto di MSIL.

Al Managed Heap & Managed Stack sono solo una parte di tali processi heap & pila. è solo che poche funzioni (indicate come GC) manterranno traccia delle assegnazioni di memoria & deallocations da questa parte della memoria.

Mi piace questa vista realistica. Non so quanto sono vero. Sto solo indovinando queste cose. Per favore correggimi & dimmi di più su questo. Quanto sarà simile a questa vista? Dove posso saperne di più sulla piattaforma .NET da questo punto di vista?

+1

lo consiglio si mette Java in una domanda separata per ottenere risposte migliori. Inoltre, con Java la risposta non è la stessa su tutte le piattaforme (ad eccezione di un livello elevato - il codice viene eseguito in una VM). Sei interessato solo a come è fatto su Windows? – Yishai

+0

Sono d'accordo con @Yishai; Java ha numerose * significative * differenze rispetto a .NET che potrebbero intorbidire la domanda. Salvalo per una domanda a parte. – Randolpho

risposta

3

Per il check CLR: CLR via C#.

È davvero un ottimo libro soprattutto se sei interessato a "basso livello" .NET/CLR.

Per il check JVM: Java Virtual Machine

+0

+1 per CLR tramite C#. Ho trovato particolarmente interessante la sezione sulla raccolta di dati inutili, in quanto il GC CLR sta facendo molto di più del semplice rilevamento dell'allocazione. CLR e GC collaborano affinché il tuo codice di esecuzione possa essere effettivamente dirottato, fare in modo che i tuoi riferimenti puntino a nuove posizioni di memoria e poi ricominciare a correre come se nulla fosse accaduto. –

2

La tua descrizione manca una cosa: la maggior parte del codice in un assembly .NET è just-in-time (JIT) compilato, il che significa che MSIL non viene convertito in codice macchina fino al momento appena prima che il metodo sia chiamato per la prima volta, a quel punto è memorizzato nella cache per il futuro. Ciò accelera notevolmente il tempo di avvio, al costo di un rallentamento minore la prima volta che viene chiamato ogni metodo. (Tralascio dettagli come il fatto che il compilatore JIT potrebbe ri-ottimizzare la funzione dopo che è stato chiamato un paio di volte.)

Il codice JIT-compilato vive sullo heap, dal punto di vista del sistema operativo. Il compilatore JIT segnerà il codice come eseguibile e farà qualsiasi altro voodoo necessario per farlo funzionare correttamente.

2

Non è preciso al 100%, ma direi che hai una panoramica decente di alcune parti del framework.

Se desideri saperne di più, ti suggerisco di dare un'occhiata prima allo .NET Framework FAQ e quando hai finito leggi la serie di articoli .NET 1.1 Inside the .NET Framework. Questi articoli non copriranno molti dei progressi che si sono verificati nelle ultime 4 versioni, ma forniranno una base solida e valida su cosa sia il .NET Framework.

1

Ultimamente sto leggendo Pro C# 2008 and the .NET 3.5 Platform (ora c'è anche una versione VS2010/.NET 4.0), e fa un ottimo lavoro spiegando come funziona il bytecode .NET sul back-end, e come si può imparare su ciò che viene realmente chiamato da usando il riflettore, ecc. È denso e lungo (ea volte più informazioni di quanto volessi), ma è una buona lettura informativa.

3

CLR via C# descrive alcune cose .NET interne, incluso il processo di caricamento PE e l'hosting di CLR nel proprio processo.

+0

quale capitolo di questo libro spiega cosa hai detto? – claws

+0

1 e 22, per la 3a edizione. – wRAR

4

Hai perso un punto molto importante: il codice CIL (precedentemente MSIL) è un codice sicuro.Non è possibile eseguire il puntatore arbitrario voodoo, digitare il cast o cose del genere simili (ad eccezione di alcune nelle regioni di codice non sicure). Questa è probabilmente la differenza più importante per altri linguaggi come C (++), Pascal e così via. Queste garanzie di sicurezza sono profondamente integrate nella lingua, nel sistema di tipo e nella progettazione runtime.

+0

+1 accidenti! Mi è davvero mancato. – claws

+0

+1, ma aggiungerei 'impossibile accedere alla matrice al di fuori dei suoi limiti', che impedisce totalmente gli scenari di sovraccarico del buffer. –

+1

beh, puoi fare * qualche * voodoo. O almeno un po 'di hocus-pocus. Alcune delle lingue lo chiariscono, ad esempio facendovi dichiarare le regioni "non sicure". Ci sono anche * molti * di costrutti MSIL non verificabili (ma validi). –