Programowanie Aplikacji Lokalnych w Środowisku .NET Organizacja pamięci Samodzielne zarządzanie pamięcią Pamięć w .NET

Stronicowanie 32 bitowy adres w kodzie  AdresFizyczny Strony 4kB (!CE), (adres strony: 0xXXXXX000) Proces -> katalog stron Sprzętowa realizacja mapowania adresów Całkowita izolacja procesów w NT/Win2K/XP/Vista Brak problemów z konsolidacją zwalnianej pamięci Zrzucanie pamięci na dysk (inf. w tablicy stron) Usuwanie stron z pamięci np dll (inf. w tablicy stron)

Atrubuty stron PAGE_NOACCESS PAGE_READONLY PAGE_READWRITE PAGE_EXECUTE PAGE_EXECUTE_READ PAGE_EXECUTE_READWRITE PAGE_WRITE_COPY* PAGE_EXECUTE_WRITE_COPY* PAGE_NOCACHE, PAGE_WRITECOMBINE** PAGE_GUARD*** * współdzielenie danych przez aplikacje ** łączenieoperacji w bloki – sterowniki *** notyfikacja o zapisie (wyjątek) – np. dla realizacji stosu wątku

Pamięć > 2GB W systemach 32b (począwszy od Windows 2000 Advanced Server), Windows XP Pro można zredukować przestrzeń jądra do 1GB (i uzyskać 3GB w trybie użytkownika) /3GB w boot.ini linker - /LARGEADDRESWARE Problemy z kompatybilnością przy niestand. wykorzystaniu przez programistów górnego bitu wskaźnika do Żeby zobaczyć więcej niż 3GB system musi pracować w trybie PAE –> pot. problemy ze sterownikami Windows 64B – 4TB

Mapa pamięci Win 64b Win98 Strefa Win2K/Xp 3GB Win2K/Xp 2GB 0xFFFFFFFF’FFFFFFFF 0xC000000 0xFFFFFFFF 0x80000000 0xFFFFFFFF 0xC0000000 0xFFFFFFFF Tryb jądra 0x000003FF’FFFFFFFF 0xBFFF0000 0xBFFFFFFF 0x7FFF0000 0x7FFFFFFF ND zewnętrzne 64KB 0x00001000 0x003FFFFF Kompatyb. z DOS16 0x80000000 0xBFFFFFFF Dzielony plik mapw. 0x00000000’00001000 0x000003FF’FFFFFFFF 0x00010000 0xBFFFFFFF 0x00010000 0x7FFFFFFF 0x00400000 0x7FFFFFFF Tryb użytkown. 0x00000000’00000000 0x00000000’0000FFFF 0x00000000 0x0000FFFF 0x00000000 0x00000FFF Pusty wskaźnik Win 64b Win2K/Xp 3GB Win2K/Xp 2GB Win98 Strefa

Systemowy alokator pamięci Lektura: Heap: Pleasures and Pains, Murali R. Krishnan, Ms Corp

Pamięć Procesu start (32) - przydział przestrzeni adresowej 2GB (3GB) Bloki na granicy ziarnistości (64kB) – nie dotyczy samego systemu rozmiar - wielokrotność strony (dla x86 - 4kB) XP – rozszerzenie Żądanie dostępu Jeśli dane nie są w pamięci wczytanie danych z pliku wymiany lub pliku (DLL) Jeśli brak miejsca zwolnienie strony (w przypadku ew. modyfikacji zapis do pliku wymiany) Mapowanie adresu wirtualnego na fizyczny

Operacje na pamięci (Win32) dwa etapy pobierania bloku pamięci VirtualAlloc rezerwacja MEM_RESERVE przydzielenie MEM_COMMIT dwa etapy zwalniania bloku pamięci VirtualFree oddzielenie MEM_DECOMMIT przydzielanie MEM_RELEASE atrybuty dostępu do bloku pamięci VirtualProtect blokowanie zrzucania pamięci na dysk VirtualLock / Unlock

Pamięć wirtualna – dostęp VirtualAlloc najpierw sprawdza czy pamięć już została zamapowana i ew. nie robi tego ponownie. Próba dostępu do pamięci zarezerwowanej, ale nie przydzielonej generuje wyjątek (ktory można obsłużyć)

Stan pamięci statystyka systemu: GlobalMemoryStatus : 32Bit -> przestrzeń 4GB 2GB aplikacja 2GB system 3GB+1GB – system boot.ini: „/3GB” oraz IMAGE_FILE_LARGE_ADDRESS_AWARE dla aplikacji 64Bit -> >4GB .NET: System.Management.ManagementClass("Win32_OperatingSystem") System.Management.ManagementClass.GetInstances System.Management.ManagementObject.Properties stan przestrzeni adresowej: VirtualQuery VirtualQueryEx (hProcess, ...)

Umieszczający operator new konstruktor klasa::klasa(A a, B b, C c); operator new klasa * w = new klasa(a,b,c); delete w; funkcja operator new: void * operator new(size_t rozmiar); void * pamiec = operator new(sizeof klasa); operator delete(pamiec) umieszczający operator new w = new (pamiec) klasa(a,b,c); w -> ~klasa();

Smart pointers template <class T> class Ptr { T* p; public: Ptr(T* p_) : p(p_) { p->upcount(); } ~Ptr(void) { p->downcount(); } operator T*(void) { return p; } T& operator*(void) { return *p; } T* operator->(void) { return p; } Ptr& operator=(Ptr<T> &p_) { return operator=((T *) p_); } Ptr& operator=(T* p_) { p->downcount(); p = p_; p->upcount(); return *this; } }; Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Reprezentacja danych Typy wartościowe: typy proste, stuktury alokowane na stosie nie można po nich dziedziczyć Typy referencyjne: obiekty alokowane na stercie zarządzalnej unikatowa tożsamość dodatkowe pola (sync block, Method Table Pointer )

Reprezentacja Kolejność pól LayoutKind.Auto — o kolejności ułożenia decyduje CLR. LayoutKind.Sequential — kolejność ułożenia odpowiada kolejności definicji pól obiektu w kodzie źródłowym. LayoutKind.Explicit – kolejność jest określona przez podanie konkretnych offset’ów. Boxing/unboxing

Boxing/unboxing struct PktValue { public byte X; public byte Y; } Object Test(Object obj) { return obj; } PktValue v = new PktValue(); Object o = Test(v); v = (PktValue) o; Kolekcje generyczne Przeciązanie matod Equals, Implementacja Equatable<T>,IComparable<T>

interface IChangeBoxedPoint { void Change(Int32 x, Int32 y); } struct Point : IChangeBoxedPoint { private Int32 m_x, m_y; public Point(Int32 x, Int32 y) { m_x = x; m_y = y; } public void Change(Int32 x, Int32 y) { m_x = x; m_y = y; public override String ToString() { return String.Format("({0}, {1})", m_x.ToString(), m_y.ToString()); };

Point p = new Point(1, 1); // 1 Console. WriteLine(p); // 2 p Point p = new Point(1, 1); // 1 Console.WriteLine(p); // 2 p.Change(2, 2); // 3 Console.WriteLine(p); // 4 Object o = p; // 5 Console.WriteLine(o); // 6 ((Point) o).Change(3, 3); // 7 Console.WriteLine(o); // 8 ((IChangeBoxedPoint) p).Change(4, 4); // 9 Console.WriteLine(p); // 10 ((IChangeBoxedPoint) o).Change(5, 5); // 11 Console.WriteLine(o); //12

Point p = new Point(1, 1); // 1 Console.WriteLine(p); // 2 Konwersja p.Change(2, 2); // 3 Console.WriteLine(p); // 4 Konwersja Object o = p; // 5 Konwersja + pot. niespójność -> 2 kopie Console.WriteLine(o); // 6 ? ((Point) o).Change(3, 3); // 7 Konwersja jaka jest zawartość o? Console.WriteLine(o); // 8 ((IChangeBoxedPoint) p).Change(4, 4); // 9 Konwersja + zaw. p? Console.WriteLine(p); // 10 Konwersja ((IChangeBoxedPoint) o).Change(5, 5); // 11 Console.WriteLine(o); //12

Życie obiektu wg. GC Rezerwacja - new (IL->newobj) Inicjalizacja (konstruktor) Użycie Deterministyczne uwolnienie zasobów (Dispose) Zaznaczanie nieużytków (Mark) Ew. Uwolnienie zasobów (Finalizacja) Zwolnienie pamieci (Sweep&Pack)

GC Mark&Sweep&Compact GC - Poszukuje o oznacza obiekty, które mają korzeń w zmiennych statycznych zmiennych lokalnych referencjach miedzy-generacyjnych obiektach w kolejce do finalizacji Niezaznaczone obiekty usuwa i kompaktuje stertę

Sterta zarządzana Przydział nie wymaga przeglądania list wolnych bloków) Możliwa jest reorganizacja sterty Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

W momencie braku pamięci przeprowadzane jest odśmiecanie Obiekty i śmieci W momencie braku pamięci przeprowadzane jest odśmiecanie Zaznaczane są: statyczne obiekty Lokalne obiekty paramerty funkcji Obiekty będące własnością ów już już zaznaczonych Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Ile razy wykona się GC? class Program { static void Main(string[] args) { Timer timer = new Timer(OnTimer, null, 0, 1000); Console.ReadLine(); } static void OnTimer(object state) { GC.Collect(); // wymuszenie pracy GC

Ile razy wykona się GC? class Program { static void Main(string[] args) { Timer timer = new Timer(OnTimer, null, 0, 1000); Console.ReadLine(); } static void OnTimer(object state) { GC.Collect(); // wymuszenie pracy GC 1 raz – optymalizacja: kompilator “zapamietuje miejsce do którego jest używana zmienna lokalna”

Generacje Założenia: starsze obiekty żyją dłużej, starsze obiekty są potencjalnie silniej związane Po zakończeniu oznaczania usuwane są martwe obiekty z b. Pokolenia a żywe są przemieszczane Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Generacje Sprzątanie Gen 0 – 1ms? Gen 1 – domyslnie 0.5-4MB Przypięte obiekty są promowane Wolania m. generacyjne (sprawdzane w momencie przypisania) Sterta dużych obiektów (>85KB dla .Net <=4.5.1) Od razu trafiają di generacji 2 Nie podlega kompaktowaniu (od wersji 4.5.1 jest to możliwe jest ale tylko na rządanie) Zarządzana poprzez listę wolnych miejsc Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Zarządzanie automatem void GC.Collect(Int32 Generation) void GC.Collect() GC.Collect(GC.MaxGeneration); Int32 GetGeneration(Object obj) void WaitForPendingFinalizers(); Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Konfiguracja GC Wokstation -> praca przy jednym procesorze Niewspółbieżna – wszystkie wątki robocze są zawieszone na cały czas sprzątania Współbieżna – przed .Net 4.0 większa część fazy oznaczania jest wykonywan współbieżnie (2 generacja) Współbieżna – od .Net 4.0 2 wątki I foreground blokująco odśmieca 0,1 generację oraz upakowuje 2 II background jest nieblokujący I odznacza (ale nie upakowuje) 2 generację Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Konfiguracja GC Serwer -> każdy procesor ma swoją stertę, alokacja I sprzątanie odbywają sie równolegle. Od 4.5 Praca w tle (2 wątki – analogicznie do workstation) Zbalansowana alokacja dużych obiektów – rownomiernie rozłożona na wszystkie sterty Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu GC.Collect(2, GCCollectionMode.Optimized) GCCollectionMode: Default | Forced | Optimized.

Konfiguracja GC Batch – aplikacje bez GUI/operacji serwerowych <gcConcurrent> jest zablokowany lub oba <gcConcurrent> i <gcServer> są włączone. Interactive – GUI <gcConcurrent> is włączony i <gcServer> is zablokowany LowLatency – aplikacje z wymaganym krótkim czasem odpowiedzi, wrażliwe na spowolnienie spowodowane przez GC (-> renderowanie grafiki ?) SustainedLowLatency: (od .NET 4.5) zarówno dla trybu stacji roboczej, jak i serwera. Pozwala odwlekać pełne odzyskiwanie pamięci dla długotrwałych operacji. GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Uwalnianie zasobów Na życzenie: Dispose Automatyczne: Finalizator

IDisposeable // Font : IDisposeable; Font font1 = new Font("Arial", 10.0f) ... font1.Dispose(); // finally? using (Font font1 = new Font("Arial", 10.0f)) { } Gdzie zwalniany jest obiekt?

Finalizator Jest przeznaczony do zwalniania zasobów Finalizatora nie definiuje sie explicite Finalizator jest generowany automatycznie - > destruktor public class BaseObj { public BaseObj() { } public ~ BaseObj () { // zwalnianie zasobów np. Close(db_connection); Console.WriteLine("In Finalize."); } /* protected override void Finalize() { // zwalnianie zasobów np. Close(db_connection); Console.WriteLine("In Finalize."); }*/ Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Finalizator w przypadku zabicia procesu nic nie pomoże Obiekty zawierające finalizator są wolniej alokowane, dużo wolniej zwalniane domyślnie „żyją jedną generację dłużej” dotyczy to również wszystkich obiektów, do których odwołuja się takie obiekty itd. nie jest znana kolejność wołań finalizatorów nie ma gwarancji ze finalizator zostanie uruchomiony MyObject : CriticalFinalizerObject void WaitForPendingFinalizers() w przypadku zabicia procesu nic nie pomoże F. nie sa wołane domyslnie dla klas bazowych (por. destruktor)

Kolejka do finalizacji kolejka obiektów do finalizacji – nie mogą one zostać usuniete bez finalizacji Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Kolejka do finalizacji kolejka obiektów po finalizacji ale przed dealokacją Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu powód: w jednej z kolejek (istnieją obiekty posiadające do nich wskaźnik)

Wskrzeszenie obiektu? GC.ReRegisterForFinalize(this); Powód: W czasie finalizacji powstaje nowa referencja do obiektu rzucany jest wyjątek (tragedia!!!) przypisujemy coś do wskaźnika globalnego, statycznego, atrybutu „żyjącego obiektu” Problem: obiekt może być już „sfinalizowany” Rozwiązanie: flaga – „finalizacja ukończona” wykluczająca operacje Sterowanie mechanizmem finalizacji – przydatne gdy chcemy finallizować na życzenie GC.ReRegisterForFinalize(this); GC.SuppressFinalize(this);

Pattern Finalize/Dispose public class MyClass : IDisposable { private bool disposed = false; ~MyResource() { Dispose (false); } public void Dispose() // Do not make this method virtual. { Dispose (true); } public void Close() // Do not make this method virtual. { Dispose (true); } Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Zwolnienie na życzenie private void Dispose(bool disposing) { // Check to see if Dispose has already been called. if(!this.disposed) { if(disposing) { AllComponent.Dispose(); GC.SuppressFinalize(this); } CloseHandle(handle); handle = IntPtr.Zero; disposed = true; } } Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Słabe referencje void Method() { Object o = new Object(); // silna referencja WeakReference wr = new WeakReference(o); o = null; // usuwamy silną referencję o = wr.Target; if (o == null) { // GC zwolnił obiekt } else { // obiekt ciągle istnieje } } Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

Czy jest możliwy wyciek pamięci w .NET? btn.Click += OnBtnClick Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

System.Diagnostics.PerformanceCounter Monitorowanie GC Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu System.Diagnostics.PerformanceCounter

Critical Object Finalizers Podczas tworzenia pierwszego obiektu danego typu, metoda finalizująca jest kompilowana przez kompilator JIT (minimalizujemy ryzyko wystąpienia błędu braku pamięci potem – brak kompilacji przy pierwszym wołaniu) Finalizator jest wykonywany po wszyskich finalizatorach obiektów zwykłych CLR wywołuje metodę finalizacji nawet gdy AppDomain jest niespodziewanie zamykana przez aplikację hostującą (np. IIS). Ale nie możliwe jest dziedziczenie po innym obiekcie (brak wielodziedziczenia) Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

dodac GC handle calling the DumpHeap() method in the CLRProfiler API calling the LogWriteLine method in the CLRProfiler API Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu

dodac class Host { public event EventHandler Click; } class Client { Host _host; public Client (Host host) { _host = host; _host.Click += HostClicked; } void HostClicked (object sender, EventArgs e) { ... } The following test class contains a method that instantiates 1,000 clients: class Test static Host _host = new Host(); public static void CreateClients() Client[] clients = Enumerable.Range (0, 1000) .Select (i => new Client (_host)) .ToArray(); // Do something with clients ... Ka¿dy obiekt systemowy taki jak proces, w¹tek, okno, obrazek, pêdzel itp. jest reprezentowany w systemie przez pewn¹ prywatn¹ strukturê danych. Program nie ma dostêpu do tej struktury danych, ale musi mieæ jakiœ sposób identyfikowania obiektu. W tym celu wprowadzono systemowy identyfikator obiektu nazywany niekiedy uchwytem obiektu (od ang. handle). Powody takiego podejœcia: zmiany struktury danych reprezentuj¹cej obiekt nie wp³ywaj¹ na program z ka¿dym obiektem mo¿na zwi¹zaæ prawa dostêpu