Programowanie Aplikacji Lokalnych w Środowisku .NET

Prezentacja na temat: "Programowanie Aplikacji Lokalnych w Środowisku .NET"— Zapis prezentacji:

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

2 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)

3 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

4 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

5 Mapa pamięci Win 64b Win98 Strefa Win2K/Xp 3GB Win2K/Xp 2GB
0xFFFFFFFF’FFFFFFFF 0xC xFFFFFFFF 0x xFFFFFFFF 0xC xFFFFFFFF Tryb jądra 0x000003FF’FFFFFFFF 0xBFFF xBFFFFFFF 0x7FFF x7FFFFFFF ND zewnętrzne 64KB 0x x003FFFFF Kompatyb. z DOS16 0x xBFFFFFFF Dzielony plik mapw. 0x ’ x000003FF’FFFFFFFF 0x xBFFFFFFF 0x x7FFFFFFF 0x x7FFFFFFF Tryb użytkown. 0x ’ x ’0000FFFF 0x x0000FFFF 0x x00000FFF Pusty wskaźnik Win 64b Win2K/Xp 3GB Win2K/Xp 2GB Win98 Strefa

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

7 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

8 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

9 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ć)

10 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, ...)

11 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();

12 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

13 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 )

14 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

15 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>

16 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()); };

17 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

18 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

19 Ż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)

20 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ę

21 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

22 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

23 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

24 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”

25 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

26 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 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

27 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

28 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 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

29 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.

30 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

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

32 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?

33 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

34 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)

35 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

36 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)

37 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);

38 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

39 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

40 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

41 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

42 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

43 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

44 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

45 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