Bagian 1: Komputer Tidak Memahami C#

Mulai dari sesuatu yang sangat sederhana. Baris kode berikut mungkin sudah ditulis ratusan kali:

Console.WriteLine("Hello World");

Bagi manusia, baris tersebut terlihat sangat jelas. Console menunjukkan bahwa operasi berkaitan dengan terminal, WriteLine terdengar seperti perintah untuk menulis sebuah baris, dan "Hello World" adalah teks yang ingin ditampilkan. Bahkan tanpa memahami seluruh aturan C#, nama-nama tersebut masih cukup mudah ditebak maknanya.

Namun, pemahaman tersebut hanya berlaku pada tingkat bahasa pemrograman. CPU tidak memiliki pemahaman terhadap bahasa C#. CPU tidak mengetahui apa itu Console, tidak memahami arti WriteLine, tidak mengenal konsep class, object, string, async, await, LINQ, dan berbagai fitur lain yang tersedia dalam C#. CPU bekerja pada tingkat yang jauh lebih rendah.

CPU Hanya Memahami Instruksi Mesin

CPU pada dasarnya bekerja dengan menjalankan instruksi yang direpresentasikan dalam bentuk machine code. Instruksi tersebut merupakan pola bit yang dapat diproses oleh CPU sesuai dengan instruction set architecture (ISA) yang dimilikinya, misalnya x86-64 atau ARM64.

Pada tingkat ini, konsep seperti:

Console.WriteLine("Hello World");

sudah tidak memiliki arti secara langsung.

CPU tidak melihat:

Console
WriteLine
"Hello World"

sebagai tiga bagian yang bermakna. CPU hanya menerima instruksi yang menjelaskan operasi sangat dasar, misalnya memuat data, menyimpan data, melakukan operasi aritmatika, membandingkan nilai, atau melakukan lompatan ke instruksi lain.

Secara sederhana, gambaran tingkatannya dapat dibayangkan seperti ini:

C#
│
│  Console.WriteLine("Hello World");
│
▼
Bahasa tingkat tinggi
│
│  diterjemahkan oleh compiler
▼
Instruksi tingkat rendah
│
│  diterjemahkan ke instruksi yang sesuai dengan CPU
▼
Machine Code
│
▼
CPU

Semakin ke bawah, bentuk program semakin jauh dari bahasa yang biasa dipahami manusia dan semakin dekat dengan cara kerja perangkat keras.

Lalu Apa yang Terjadi pada Console.WriteLine?

Ketika kode C# ditulis, sebenarnya belum ada instruksi CPU yang langsung dapat menjalankan baris tersebut. Kode tersebut masih merupakan source code, yaitu teks yang ditulis menggunakan aturan dan sintaks bahasa C#.

Sebagai contoh:

Console.WriteLine("Hello World");

memiliki arti bagi compiler C#. Compiler memahami bahwa:

• Console merupakan sebuah type yang tersedia dalam library .NET.

• WriteLine merupakan sebuah method.

• "Hello World" merupakan sebuah string literal.

• ; menandakan akhir statement.

• Keseluruhan statement meminta program memanggil method tersebut dengan sebuah nilai string.

CPU tidak memahami konsep-konsep tersebut. Compiler-lah yang memahami bahasa C# dan mengubah kode tersebut menjadi bentuk yang dapat diproses oleh lingkungan runtime .NET. Di sinilah compiler menjadi bagian penting dalam perjalanan sebuah program.

Compiler Sebagai Penerjemah

Compiler dapat dibayangkan sebagai penerjemah antara bahasa yang digunakan programmer dan bentuk program yang dapat diproses oleh komputer.

Manusia menulis:

Console.WriteLine("Hello World");

Compiler membaca kode tersebut, menganalisis struktur dan maknanya, memeriksa apakah kode tersebut valid menurut aturan C#, lalu menghasilkan output yang sesuai dengan target platform.

Pada .NET, hasil kompilasi C# bukan langsung berupa instruksi CPU native dalam bentuk akhir yang akan dijalankan CPU. Compiler C# biasanya menghasilkan Intermediate Language (IL) yang disimpan di dalam sebuah .NET assembly, misalnya file .dll atau .exe.

Gambaran sederhananya:

Source Code C#
       │
       │ Compiler C#
       ▼
Intermediate Language (IL)
       │
       │ .NET Runtime
       ▼
Machine Code
       │
       ▼
CPU

Ini merupakan salah satu hal penting yang membedakan model eksekusi .NET dari gambaran sederhana "compiler langsung mengubah source code menjadi machine code".

Apa Itu Intermediate Language?

Intermediate Language, atau IL, adalah bentuk instruksi yang berada di antara source code dan machine code. IL tidak bergantung secara langsung pada jenis CPU tertentu seperti x86-64 atau ARM64. Karena itu, IL dapat menjadi bentuk perantara yang memungkinkan ekosistem .NET mendukung berbagai platform.

Sebagai contoh, sebuah program C# dapat dikompilasi menjadi assembly yang berisi IL. Assembly tersebut kemudian dapat dijalankan pada lingkungan .NET di berbagai sistem operasi dan arsitektur CPU selama runtime .NET yang sesuai tersedia.

Secara sederhana:

C# Source Code
      │
      ▼
     IL
      │
      ├──────────────► x64
      │
      ├──────────────► ARM64
      │
      └──────────────► platform lain

Hal ini tidak berarti satu file IL dapat dijalankan tanpa adanya runtime. Program tetap membutuhkan komponen .NET yang bertugas memuat assembly, menyediakan library, mengelola memory, dan pada saat yang tepat mengubah IL menjadi instruksi native yang dapat dijalankan CPU.

Jadi, Apa yang Sebenarnya Menjalankan Program C#?

Pertanyaan ini membawa pembahasan menuju komponen penting dalam .NET: Common Language Runtime (CLR). CLR merupakan bagian dari .NET runtime yang menyediakan lingkungan untuk menjalankan managed code. Salah satu tugas pentingnya adalah menangani eksekusi IL.

Ketika sebuah method perlu dijalankan, runtime dapat menggunakan Just-In-Time compiler (JIT) untuk mengubah IL menjadi machine code yang sesuai dengan CPU yang sedang digunakan.

Gambaran yang lebih lengkap menjadi:

C# Source Code
      │
      │ C# Compiler
      ▼
.NET Assembly
      │
      │ berisi IL
      ▼
.NET Runtime / CLR
      │
      │ JIT Compilation
      ▼
Native Machine Code
      │
      ▼
CPU

Dengan demikian, CPU memang tidak pernah benar-benar "mengerti C#". CPU hanya menjalankan machine code yang sesuai dengan instruction set yang dimilikinya.

Mengapa Tidak Langsung Menghasilkan Machine Code?

Pertanyaan berikutnya adalah: jika pada akhirnya CPU membutuhkan machine code, mengapa compiler C# tidak langsung menghasilkan machine code untuk CPU? Salah satu alasannya adalah fleksibilitas.

Bayangkan sebuah program dikompilasi secara langsung menjadi machine code khusus x86-64. Program tersebut akan sangat bergantung pada arsitektur tersebut. Jika program yang sama ingin dijalankan pada ARM64, dibutuhkan hasil kompilasi yang berbeda.

.NET menggunakan IL sebagai bentuk perantara. Source code dapat dikompilasi menjadi assembly yang berisi IL, kemudian runtime yang sesuai dengan platform dapat menangani eksekusinya.

Pendekatan ini membantu .NET mendukung berbagai kombinasi sistem operasi dan arsitektur CPU. Tentu saja, dalam praktik modern .NET terdapat beberapa model deployment dan compilation, termasuk ReadyToRun dan Native AOT. Jadi, tidak semua aplikasi .NET selalu mengikuti alur JIT secara identik. Namun, untuk memahami konsep dasar, alur C# → IL → JIT → machine code merupakan fondasi yang sangat penting.

C# Sebenarnya Hanya Salah Satu Bahasa di Atas .NET

Hal menarik lainnya adalah .NET tidak hanya memahami C#. Ekosistem .NET juga mendukung bahasa seperti Visual Basic dan F#. Bahasa-bahasa tersebut memiliki sintaks yang berbeda, tetapi dapat dikompilasi menuju ekosistem runtime .NET yang sama.

Secara sederhana:

C# ──────────┐
             │
Visual Basic ├──► .NET Assembly / IL ──► CLR ──► CPU
             │
F# ──────────┘

Hal ini memungkinkan berbagai bahasa menggunakan infrastruktur yang sama, seperti .NET runtime, garbage collector, type system, library, dan mekanisme eksekusi yang disediakan oleh platform .NET.

Jadi, CLR bukan "mesin yang hanya memahami C#". CLR bekerja pada level runtime .NET dan dapat menjalankan managed code yang mengikuti aturan dan format yang didukung oleh platform tersebut.

Dari Satu Baris Kode Menjadi Program yang Berjalan

Baris sederhana:

Console.WriteLine("Hello World");

sebenarnya melewati beberapa tahapan sebelum menghasilkan teks di layar.

Secara konseptual:

1. Programmer menulis source code
           │
           ▼
2. Compiler C# membaca dan menganalisis source code
           │
           ▼
3. Compiler menghasilkan assembly yang berisi IL
           │
           ▼
4. .NET Runtime memuat assembly
           │
           ▼
5. CLR menangani eksekusi managed code
           │
           ▼
6. JIT mengubah IL menjadi native machine code
           │
           ▼
7. CPU menjalankan machine code
           │
           ▼
8. Program menghasilkan output

Setiap tahap memiliki tanggung jawab yang berbeda. Programmer berinteraksi dengan bahasa tingkat tinggi seperti C#. Compiler bertugas menerjemahkan dan memvalidasi kode. Assembly menyimpan hasil kompilasi. Runtime menyediakan lingkungan eksekusi. JIT menghasilkan native code ketika diperlukan. CPU akhirnya menjalankan instruksi tersebut.

C# Bukan Bahasa yang Dipahami CPU

Kesimpulan paling penting dari bagian ini adalah bahwa C# dan machine code berada pada dua tingkat yang sangat berbeda.

C# dibuat agar manusia dapat menulis program dengan cara yang lebih abstrak dan mudah dipahami. CPU bekerja dengan instruksi yang sangat spesifik terhadap perangkat keras.

Tidak ada konsep class, string, LINQ, atau async di dalam instruction set CPU. Konsep-konsep tersebut diterjemahkan dan ditangani oleh berbagai lapisan software sebelum pekerjaan akhirnya sampai kepada CPU.

Karena itu, ketika sebuah program C# berjalan, sebenarnya terdapat perjalanan panjang dari kode yang terlihat sederhana hingga instruksi yang benar-benar dieksekusi perangkat keras:

C# Source Code
      ↓
C# Compiler
      ↓
.NET Assembly
      ↓
IL
      ↓
CLR / .NET Runtime
      ↓
JIT
      ↓
Native Machine Code
      ↓
CPU

Perjalanan tersebut menjadi fondasi untuk memahami apa yang sebenarnya terjadi ketika sebuah aplikasi .NET dijalankan.

Bagian 2: Mengapa Source Code Perlu Di-compile?

Pada bagian sebelumnya, terlihat bahwa CPU tidak memahami C#. CPU hanya dapat menjalankan machine instructions yang sesuai dengan arsitektur CPU tersebut. Sementara itu, source code C# masih berupa teks yang ditulis menggunakan aturan bahasa pemrograman.

Muncul sebuah pertanyaan sederhana:

Bagaimana teks seperti Console.WriteLine("Hello World"); dapat berubah menjadi sesuatu yang akhirnya bisa dijalankan oleh CPU?

Jawabannya adalah compiler.

Apa Itu Compiler?

Compiler adalah sebuah program yang bertugas menerjemahkan source code dari bahasa pemrograman tingkat tinggi menjadi bentuk lain yang dapat diproses oleh komputer atau runtime.

Source code yang ditulis programmer masih menggunakan konsep-konsep yang nyaman bagi manusia, seperti variable, method, class, object, condition, loop, dan berbagai abstraksi lainnya.

Sebagai contoh:

int age = 26;

if (age >= 18)
{
    Console.WriteLine("Adult");
}

Bagi manusia, kode tersebut cukup mudah dipahami. Namun CPU tidak mengetahui apa arti int, age, if, Console, atau WriteLine.

Compiler memahami aturan bahasa C# dan mengubah source code tersebut menjadi bentuk yang lebih dekat dengan cara kerja runtime.

Gambaran paling sederhananya:

C# Source Code
      ↓
   Compiler
      ↓
   Output

Namun untuk .NET, kata output tersebut perlu dijelaskan lebih lanjut.

Pada beberapa bahasa pemrograman, compiler memang dapat menghasilkan machine code sebagai hasil akhirnya. Misalnya, compiler C atau C++ dapat menghasilkan native executable yang berisi instruksi machine code untuk arsitektur tertentu.

C# menggunakan pendekatan yang berbeda.

Compiler C# umumnya menghasilkan Intermediate Language (IL), bukan machine code CPU sebagai hasil utama compilation.

Alurnya menjadi:

C# Source Code
      ↓
   C# Compiler
      ↓
Intermediate Language (IL)
      ↓
.NET Runtime
      ↓
Native Machine Code
      ↓
      CPU

Jadi, compilation belum berarti source code C# langsung berubah menjadi instruksi CPU.

Mengapa Source Code Harus Di-compile?

Compilation bukan sekadar proses "mengubah tulisan menjadi bentuk lain". Compiler juga melakukan berbagai pekerjaan penting sebelum program dapat dijalankan. Salah satunya adalah memeriksa apakah source code mengikuti aturan bahasa C#.

Misalnya terdapat kode:

int age = "Hello";

Compiler dapat menemukan bahwa nilai "Hello" tidak sesuai dengan tipe int.

Kode tersebut secara sintaks mungkin terlihat seperti sebuah assignment yang valid, tetapi secara tipe tidak valid. Compiler dapat menghentikan proses compilation dan memberikan error.

Contoh lainnya:

Console.WriteLnie("Hello");

Jika method yang dimaksud sebenarnya bernama WriteLine, compiler dapat mendeteksi bahwa WriteLnie tidak ditemukan.

Dengan demikian, compiler juga berfungsi sebagai salah satu lapisan pemeriksaan terhadap source code.

Secara sederhana, compilation dapat dibayangkan sebagai proses:

Source Code
    ↓
Parsing
    ↓
Pemeriksaan aturan dan tipe
    ↓
Analisis kode
    ↓
IL

Detail internal compiler jauh lebih kompleks, tetapi gambaran tersebut cukup untuk memahami konsep dasarnya.

Source Code Hanyalah Teks

Hal penting yang sering terlewat adalah bahwa file .cs pada dasarnya hanyalah file teks.

Misalnya terdapat file:

Program.cs

yang berisi:

Console.WriteLine("Hello World");

File tersebut tidak bisa begitu saja diberikan kepada CPU.

CPU tidak mempunyai kemampuan untuk membuka Program.cs, membaca karakter C, o, n, s, o, l, dan kemudian memahami bahwa seluruhnya membentuk sebuah type bernama Console. File .cs adalah representasi program yang ditujukan untuk manusia dan compiler. Compiler kemudian memproses teks tersebut berdasarkan grammar dan aturan bahasa C#. Hasilnya bukan lagi sekadar teks C#.

Mengapa Tidak Langsung Menjadi Machine Code?

Sampai titik ini mungkin muncul pertanyaan:

Jika tujuan akhirnya adalah CPU, mengapa compiler C# tidak langsung menghasilkan machine code?

Secara teknis, .NET juga memiliki mekanisme yang memungkinkan compilation lebih dekat atau langsung menuju native code, seperti Native AOT. Namun model utama yang digunakan dalam banyak aplikasi .NET secara tradisional memanfaatkan IL sebagai intermediate representation.

Ada beberapa alasan penting di balik desain tersebut.

1. Portability

Machine code sangat bergantung pada arsitektur CPU. Machine code untuk x86-64 berbeda dengan machine code untuk ARM64. Misalnya sebuah aplikasi dikompilasi secara langsung menjadi native machine code x86-64. Hasil tersebut tidak dapat begitu saja dianggap sebagai native machine code ARM64.

Jika compilation selalu langsung menghasilkan machine code, compiler perlu menghasilkan output yang berbeda untuk berbagai target hardware. Dengan IL, source code dapat terlebih dahulu dikompilasi menjadi bentuk yang relatif independen terhadap CPU tertentu.

             ┌──► x86-64
             │
C# → IL → Runtime
             │
             └──► ARM64

Runtime kemudian menangani tahap yang berkaitan dengan platform tempat aplikasi dijalankan. Inilah salah satu alasan mengapa IL penting dalam desain .NET.

2. Memisahkan Bahasa dari Hardware

Compiler C# terutama bertanggung jawab memahami bahasa C#.

Compiler perlu memahami hal-hal seperti:

class Person
{
    public string Name { get; set; }
}

Compiler perlu mengetahui bahwa kode tersebut merupakan deklarasi class, property, tipe string, dan berbagai aturan C# lainnya. Compiler tidak harus menentukan seluruh detail instruksi CPU yang nantinya akan digunakan untuk menjalankan setiap method. Tanggung jawab tersebut dapat diserahkan kepada runtime dan komponen seperti JIT.

Pemisahan tanggung jawab ini dapat digambarkan sebagai:

C# Compiler
    │
    │ memahami C#
    ▼
    IL
    │
    │ Runtime/JIT memahami platform
    ▼
Machine Code

Dengan desain seperti ini, bahasa pemrograman dan hardware tidak perlu terikat secara langsung pada tahap compilation yang sama.

3. Satu Runtime untuk Banyak Bahasa

IL juga memungkinkan berbagai bahasa pemrograman menggunakan infrastruktur .NET yang sama.

Sebagai contoh:

C# ───────────────┐
                  │
Visual Basic ─────┼──► IL ──► .NET Runtime ──► CPU
                  │
F# ───────────────┘

C#, Visual Basic, dan F# memiliki syntax yang berbeda.

Namun setelah compilation, program-program tersebut dapat menghasilkan managed code yang dapat dijalankan oleh .NET runtime. Inilah salah satu alasan hubungan antara bahasa pemrograman dan platform .NET perlu dibedakan.

C# adalah sebuah bahasa pemrograman, sedangkan .NET adalah sebuah platform yang menyediakan runtime, library, tooling, dan infrastruktur untuk menjalankan berbagai aplikasi.

Dengan kata lain:

C# ≠ .NET

C# adalah salah satu bahasa yang dapat digunakan untuk membangun aplikasi di atas .NET.

4. Optimasi Dapat Dilakukan Saat Runtime

Keuntungan lainnya berasal dari fakta bahwa machine code tidak harus ditentukan sepenuhnya saat source code pertama kali di-compile.

Ketika runtime menjalankan aplikasi, runtime mengetahui informasi mengenai environment yang sedang digunakan.

Misalnya:

Operating System : Windows
CPU              : x86-64

atau:

Operating System : Linux
CPU              : ARM64

JIT dapat menggunakan informasi tersebut ketika mengubah IL menjadi native machine code. JIT juga dapat melakukan optimasi berdasarkan kode yang sedang dijalankan.

Hal ini menghasilkan pemisahan menarik:

Compilation
    ↓
C# → IL
    ↓
Runtime
    ↓
IL → Native Code

Compilation dan execution tidak sepenuhnya menjadi satu proses.

Compiler menghasilkan representasi perantara, sedangkan runtime menangani tahap eksekusi lebih lanjut.

Apa Sebenarnya IL Itu?

IL merupakan singkatan dari Intermediate Language. Dalam ekosistem .NET, istilah lain seperti CIL (Common Intermediate Language) dan MSIL juga sering ditemukan dalam berbagai referensi.

IL dapat dipandang sebagai instruksi untuk virtual execution environment .NET, bukan instruksi langsung untuk CPU tertentu.

Contohnya, source code:

int result = 10 + 20;

tidak harus langsung berubah menjadi instruksi x86-64 atau ARM64 pada saat compiler C# bekerja.

Compiler dapat menghasilkan IL yang merepresentasikan operasi tersebut.

Secara konseptual:

C#:
int result = 10 + 20;

        ↓ Compiler

IL:
instruksi .NET untuk
memuat nilai,
melakukan operasi,
dan menyimpan hasil

        ↓ Runtime / JIT

Machine Code:
instruksi spesifik CPU

        ↓

CPU

IL menjadi jembatan antara bahasa pemrograman dan hardware.

IL Tidak Berarti "Machine Code Versi Sederhana"

IL bukan sekadar machine code yang ditulis menggunakan kata-kata. IL memiliki instruction set sendiri yang dirancang untuk lingkungan eksekusi .NET. Instruksi IL bekerja bersama metadata dan type system .NET. Karena itu, sebuah assembly .NET tidak hanya berisi instruksi. Assembly juga membawa informasi mengenai type, method, reference terhadap assembly lain, dan berbagai metadata lainnya. Hal ini memungkinkan runtime memahami struktur program ketika aplikasi dimuat.

Sebagai contoh, runtime perlu mengetahui bahwa terdapat sebuah type bernama:

Person

yang memiliki method:

GetName()

Informasi semacam ini merupakan bagian dari metadata yang terdapat dalam assembly. Jadi, hasil compilation .NET bukan sekadar "kode lain".

Lebih tepat jika dibayangkan sebagai:

.NET Assembly
├── IL
├── Metadata
├── Type Information
└── References

Detail struktur assembly akan dibahas lebih jauh pada bagian berikutnya.

Mengapa Tidak Mengompilasi C# Langsung ke Setiap CPU?

Tanpa intermediate representation, compiler perlu menangani lebih banyak kombinasi.

Bayangkan terdapat:

3 bahasa
×
3 sistem operasi
×
2 arsitektur CPU

Secara konseptual, semakin banyak kombinasi bahasa dan target hardware, semakin banyak variasi compilation yang harus dipertimbangkan.

Dengan adanya IL, modelnya menjadi lebih terpisah:

C# ───────────┐
VB ───────────┼──► IL
F# ───────────┘
                  │
                  ▼
             .NET Runtime
                  │
          ┌───────┴───────┐
          ▼               ▼
       x86-64           ARM64

Bahasa cukup menghasilkan bentuk perantara yang sesuai dengan ekosistem .NET. Runtime kemudian menangani perbedaan platform.

Tentu saja, implementasi nyata .NET jauh lebih kompleks daripada diagram tersebut. Namun secara arsitektur, pemisahan ini merupakan salah satu ide penting yang membuat platform .NET dapat berkembang ke banyak bahasa, sistem operasi, dan arsitektur hardware.

Apakah Compilation Berarti Program Sudah Bisa Berjalan?

Belum tentu. Compilation dan execution adalah dua hal yang berbeda.

Misalnya source code berhasil di-compile:

Program.cs
    ↓
Compiler
    ↓
Program.dll

Keberhasilan compilation berarti compiler berhasil menghasilkan output berdasarkan source code yang diberikan.

Namun ketika Program.dll dijalankan, masih ada proses lain yang terjadi:

Program.dll
    ↓
.NET Runtime
    ↓
Assembly Loading
    ↓
CLR
    ↓
JIT
    ↓
Native Code
    ↓
CPU

Pada tahap execution, runtime perlu memuat assembly, menemukan informasi yang diperlukan, menyiapkan environment, dan menangani berbagai kebutuhan aplikasi selama program berjalan.

Karena itu, berhasil di-compile tidak sama dengan sudah dieksekusi. Compilation menghasilkan sesuatu yang siap digunakan oleh tahap berikutnya. Execution adalah proses menjalankan hasil tersebut.

Gambaran Besar Sejauh Ini

Sampai titik ini, perjalanan sebuah aplikasi C# dapat digambarkan sebagai berikut:

┌──────────────────────┐
│   C# Source Code     │
│      Program.cs      │
└──────────┬───────────┘
           │
           │ C# Compiler
           ▼
┌──────────────────────┐
│    .NET Assembly     │
│                      │
│  IL + Metadata       │
└──────────┬───────────┘
           │
           │ .NET Runtime
           ▼
┌──────────────────────┐
│        CLR           │
│                      │
│   Runtime Services   │
└──────────┬───────────┘
           │
           │ JIT
           ▼
┌──────────────────────┐
│  Native Machine Code │
└──────────┬───────────┘
           │
           ▼
        ┌─────┐
        │ CPU │
        └─────┘

Setiap lapisan memiliki tanggung jawab yang berbeda.

C# source code adalah kode yang ditulis menggunakan bahasa yang nyaman bagi manusia. Compiler memahami bahasa C# dan menerjemahkannya menjadi bentuk yang sesuai untuk ekosistem .NET. Assembly menjadi wadah hasil compilation, termasuk IL dan metadata. CLR dan .NET runtime menyediakan lingkungan untuk menjalankan managed code. JIT dapat menerjemahkan IL menjadi native machine code. CPU akhirnya menjalankan native machine code tersebut.

IL Menjadi Titik Pertemuan

Dengan memahami IL, hubungan antara C# dan .NET mulai terlihat lebih jelas. C# bukan runtime. C# bukan CLR. C# juga bukan .NET secara keseluruhan.

C# adalah bahasa pemrograman yang dapat digunakan untuk menghasilkan managed code yang kemudian dijalankan oleh .NET.

.NET menyediakan platform yang lebih luas, termasuk runtime dan library yang memungkinkan aplikasi tersebut berjalan.

Hubungannya dapat disederhanakan menjadi:

             Bahasa
               │
       ┌───────┼───────┐
       │       │       │
      C#       VB      F#
       │       │       │
       └───────┼───────┘
               ▼
              IL
               │
               ▼
          .NET Runtime
               │
               ▼
              CPU

IL menjadi salah satu titik pertemuan berbagai bahasa tersebut.

Karena itulah .NET dapat menyediakan satu ekosistem runtime yang digunakan oleh lebih dari satu bahasa pemrograman.

Pertanyaan Berikutnya

Sampai tahap ini, alur dasarnya sudah mulai terbentuk:

C#
 ↓
Compiler
 ↓
IL
 ↓
.NET Runtime
 ↓
Machine Code
 ↓
CPU

Namun masih ada bagian penting yang belum dijelaskan.

Di mana sebenarnya IL tersebut disimpan?

Ketika sebuah project C# di-build, mengapa muncul file seperti:

.dll
.exe
.pdb
.deps.json
.runtimeconfig.json

Apa isi sebenarnya dari file .dll?

Mengapa .dll yang dihasilkan oleh project .NET tidak sama dengan DLL native yang biasa ditemukan pada sistem operasi?

Dan bagaimana CLR dapat membaca sebuah assembly lalu menemukan class, method, metadata, serta IL di dalamnya?

Untuk menjawab pertanyaan tersebut, pembahasan berikutnya perlu masuk lebih dalam ke konsep assembly.

Bagian 3: C# Bukan .NET

Sebelum melangkah lebih jauh, ada satu konsep yang perlu diluruskan lebih dulu, karena dua istilah ini sering dianggap sama padahal cakupannya sangat berbeda.

C# adalah bahasa pemrograman. Titik. Tugasnya hanya menyediakan syntax dan aturan penulisan kode yang kemudian diterjemahkan oleh compiler menjadi IL, seperti yang sudah dibahas sebelumnya.

.NET jauh lebih luas dari itu. .NET adalah sebuah platform yang di dalamnya terdapat runtime untuk menjalankan aplikasi, Base Class Libraries yang menyediakan fungsi-fungsi siap pakai, SDK untuk keperluan development, CLI sebagai antarmuka command line, berbagai tooling pendukung, dan secara keseluruhan menjadi platform tempat aplikasi dibangun dan dijalankan.

C#
│
└── Bahasa pemrograman

.NET
│
├── Runtime
├── Base Class Libraries
├── SDK
├── CLI
├── Tooling
└── Platform aplikasi

Dengan gambaran ini, hubungan keduanya menjadi lebih jelas. C# adalah salah satu bahasa yang dipakai untuk membangun aplikasi .NET, tetapi .NET sendiri tidak identik dengan C#. Justru dari sinilah pertanyaan berikutnya muncul secara alami: kalau .NET bukan hanya soal C#, bahasa apa lagi yang bisa dipakai di atas platform yang sama?

Bagian 4: Mengapa .NET Bisa Menggunakan Banyak Bahasa?

Salah satu karakteristik menarik dari .NET adalah kemampuannya mendukung lebih dari satu bahasa pemrograman. Selain C#, ada juga Visual Basic .NET dan F# yang sama-sama bisa dipakai membangun aplikasi di atas platform ini.

Pertanyaannya, bagaimana bahasa-bahasa dengan syntax dan karakteristik yang jauh berbeda bisa berjalan di runtime yang sama? Jawabannya terletak pada desain .NET yang sudah dibahas sebagian di Bagian 2.

Compiler Berbeda, Runtime Bisa Sama

Perhatikan tiga baris kode berikut yang melakukan hal serupa di tiga bahasa berbeda.

C#:

Console.WriteLine("Hello");

VB.NET:

Console.WriteLine("Hello")

F#:

printfn "Hello"

Syntax ketiganya jelas berbeda, dan compiler yang memprosesnya juga berbeda satu sama lain. Namun ada satu titik pertemuan yang membuat ketiganya bisa berjalan di atas fondasi yang sama:

C# Source
    ↓
C# Compiler
    ↓
IL

VB.NET Source
    ↓
VB Compiler
    ↓
IL

F# Source
    ↓
F# Compiler
    ↓
IL

Setelah masing-masing compiler selesai bekerja, hasilnya sama-sama berupa IL. Dari titik itu, alurnya menyatu:

IL
 ↓
.NET Runtime
 ↓
JIT
 ↓
Native Code
 ↓
CPU

Runtime Tidak Perlu Memahami Syntax C#

Hal yang menarik dari pola di atas adalah CLR, sebagai bagian dari .NET Runtime, sama sekali tidak perlu tahu apakah IL yang sedang dijalankannya awalnya ditulis dalam C#, VB.NET, atau F#. Yang memahami syntax masing-masing bahasa adalah compiler-nya, bukan runtime. Setelah proses compilation selesai, runtime hanya berurusan dengan IL dan execution model .NET, tanpa peduli bahasa asal kode tersebut.

Pola ini bisa disederhanakan menjadi satu alur:

Different Languages
        ↓
Different Compilers
        ↓
Common Intermediate Representation
        ↓
.NET Runtime

Titik temu di "Common Intermediate Representation" inilah yang menjadi alasan mengapa .NET bisa terasa seperti satu ekosistem, meskipun bahasa yang dipakai di dalamnya bisa berbeda-beda.

Bagian 5: IL / CIL

Istilah IL sudah beberapa kali muncul pada bagian sebelumnya. IL disebut sebagai hasil utama dari proses compilation C#, sebagai bentuk perantara sebelum program akhirnya menjadi machine code.

Namun, apa sebenarnya IL itu?

Untuk memahaminya, perlu dilihat kembali perjalanan sebuah program .NET dari awal:

C# Source Code
      ↓
    Compiler
      ↓
      IL
      ↓
 .NET Runtime
      ↓
 Native Machine Code
      ↓
      CPU

IL berada di tengah-tengah perjalanan tersebut. IL bukan lagi source code C#, tetapi juga belum menjadi machine code yang spesifik untuk CPU.

Apa Itu IL?

IL (Intermediate Language) adalah kumpulan instruksi perantara yang dihasilkan oleh compiler .NET dari source code bahasa seperti C#.

Ketika compiler C# memproses kode:

int result = 10 + 20;

compiler tidak langsung menghasilkan instruksi CPU tertentu. Compiler menghasilkan bentuk perantara yang merepresentasikan operasi program tersebut dalam instruction set .NET.

Secara sederhana:

C#
│
│ Compiler
▼
IL

IL kemudian disimpan di dalam .NET assembly, bersama dengan metadata dan informasi lain yang dibutuhkan runtime. Jadi, ketika sebuah project C# berhasil di-build, hasilnya bukan sekadar kumpulan machine code.

Salah satu bentuk hasil build yang umum adalah:

MyApplication.dll

File tersebut merupakan sebuah .NET assembly yang di dalamnya terdapat IL dan metadata.

Mengapa Disebut Intermediate Language?

Kata intermediate berarti "perantara".

IL disebut demikian karena posisinya berada di antara source code dan native machine code.

Source Language
      │
      │ C# Compiler
      ▼
Intermediate Language
      │
      │ JIT
      ▼
Native Machine Code

C# berada pada tingkat yang dekat dengan cara berpikir manusia.

IL berada pada tingkat yang lebih rendah dan lebih terstruktur, tetapi masih dirancang untuk lingkungan eksekusi .NET. Machine code berada pada tingkat yang jauh lebih dekat dengan hardware.

Dengan demikian, terdapat tiga bentuk kode yang perlu dibedakan:

C#
│
│ Bahasa pemrograman
│
▼
IL / CIL
│
│ Instruksi perantara .NET
│
▼
Machine Code
│
│ Instruksi native CPU
│
▼
CPU

Ketiga istilah tersebut memiliki fungsi yang berbeda.

C# adalah Source Language

C# merupakan source language, yaitu bahasa yang digunakan untuk menulis source code.

Contohnya:

class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

Kode tersebut dibuat agar dapat dibaca dan ditulis dengan relatif mudah oleh manusia.

C# memiliki berbagai fitur tingkat tinggi seperti:

• class

• object

• method

• property

• interface

• generic

• exception

• async/await

• LINQ

• pattern matching

• lambda expression

CPU tidak memahami konsep-konsep tersebut secara langsung.

Compiler C# bertugas menerjemahkan konsep-konsep tersebut ke bentuk yang dapat direpresentasikan dalam IL dan metadata .NET.

IL adalah Intermediate Representation

IL berada satu tingkat di bawah source code.

Misalnya sebuah method C#:

public int Add(int a, int b)
{
    return a + b;
}

Compiler perlu mengubah method tersebut menjadi serangkaian instruksi IL yang merepresentasikan operasi yang diperlukan.

Secara konseptual, instruksinya dapat dibayangkan seperti:

ambil nilai a
ambil nilai b
jumlahkan
kembalikan hasil

IL memiliki instruction set sendiri. Instruksi tersebut bukan instruksi x86-64 atau ARM64.

Dengan kata lain:

IL instruction
    ≠
x86-64 instruction
    ≠
ARM64 instruction

Ketiganya berada pada level yang berbeda.

Machine Code adalah Instruksi CPU

Machine code adalah instruksi native yang sesuai dengan instruction set architecture CPU. Dua CPU dengan arsitektur berbeda dapat memiliki machine code yang berbeda.

Sebagai contoh, program yang sama dapat akhirnya menghasilkan machine code untuk:

x86-64

atau:

ARM64

IL tidak secara langsung menentukan salah satunya.

Itulah salah satu karakteristik penting IL.

Gambaran sederhananya:

                 ┌──► x86-64 Machine Code
                 │
C# ──► IL ──► JIT
                 │
                 └──► ARM64 Machine Code

Runtime yang berjalan pada environment tertentu dapat menghasilkan native code yang sesuai dengan environment tersebut.

IL Tidak Dijalankan Langsung oleh CPU

Ini adalah bagian yang sangat penting. CPU tidak membaca IL lalu mengeksekusinya seperti machine code.

Misalnya terdapat IL seperti:

ldarg.0
ldarg.1
add
ret

Instruksi tersebut merupakan instruksi pada instruction set IL.

CPU tidak memiliki instruksi bernama ldarg.0 atau ret dalam pengertian IL. CPU membutuhkan native machine instructions.

Karena itu, masih diperlukan proses lain:

IL
 ↓
JIT
 ↓
Machine Code
 ↓
CPU

JIT (Just-In-Time compiler) merupakan salah satu komponen .NET runtime yang dapat menerjemahkan IL menjadi native machine code ketika method perlu dijalankan.

Dengan demikian, alur lengkapnya menjadi:

C# Source Code
      ↓
C# Compiler
      ↓
.NET Assembly
      ↓
IL
      ↓
.NET Runtime
      ↓
JIT
      ↓
Native Machine Code
      ↓
CPU

Apa Hubungan IL dengan CIL?

Dalam dokumentasi dan pembahasan .NET, terdapat beberapa istilah yang mungkin terlihat berbeda:

• IL

• CIL

• MSIL

Ketiganya sering digunakan untuk merujuk pada konsep yang sangat berkaitan.

CIL merupakan singkatan dari Common Intermediate Language.

Spesifikasi CLI mendefinisikan CIL sebagai instruction set untuk intermediate language yang digunakan dalam lingkungan Common Language Infrastructure.

Dalam percakapan sehari-hari di dunia .NET, istilah IL jauh lebih umum digunakan.

Karena itu, kode hasil compilation C# sering disebut sebagai:

IL

meskipun secara lebih spesifik dapat disebut:

CIL

Istilah MSIL (Microsoft Intermediate Language) juga sering ditemukan pada dokumentasi atau materi lama. Nama tersebut berasal dari istilah yang digunakan Microsoft pada masa sebelumnya. Untuk pembahasan modern mengenai .NET, istilah IL atau CIL sudah cukup.

IL Memiliki Instruction Set Sendiri

IL bukan sekadar teks yang menjelaskan apa yang harus dilakukan program. IL memiliki instruction set yang dapat direpresentasikan dalam bentuk opcode.

Contoh instruksi IL yang sering ditemukan antara lain:

ldarg
ldloc
stloc
ldstr
call
callvirt
newobj
add
sub
br
brtrue
brfalse
ret

Setiap instruksi memiliki fungsi tertentu.

Misalnya:

ldstr

digunakan untuk memuat string.

add

digunakan untuk melakukan operasi penjumlahan.

newobj

digunakan untuk membuat object.

call

digunakan untuk melakukan pemanggilan method tertentu.

ret

digunakan untuk mengembalikan kontrol dari method.

Instruksi-instruksi tersebut kemudian dapat diproses oleh runtime dan JIT.

Contoh Sederhana

Pertimbangkan kode C# berikut:

public static int Add(int a, int b)
{
    return a + b;
}

Secara konseptual, compiler perlu menghasilkan instruksi yang memiliki arti seperti:

ambil argument pertama
ambil argument kedua
jumlahkan
kembalikan hasil

Jika IL dari method tersebut dilihat menggunakan tool seperti ILSpy atau ildasm, bentuknya akan menyerupai:

ldarg.0
ldarg.1
add
ret

Tidak perlu menghafalkan instruksi tersebut.

Yang penting adalah memahami perjalanan abstraksinya:

C#:

return a + b;

        ↓

IL:

ldarg.0
ldarg.1
add
ret

        ↓

Native Machine Code:

instruksi yang sesuai
dengan CPU tertentu

Instruksi IL masih bersifat independen terhadap CPU tertentu.

IL Tidak Hanya Berisi Operasi Sederhana

IL juga mampu merepresentasikan berbagai konstruksi program yang lebih kompleks.

Misalnya object creation:

var person = new Person();

Compiler dapat menghasilkan IL yang menggunakan instruksi seperti:

newobj

Pemanggilan method:

person.GetName();

dapat direpresentasikan menggunakan instruksi pemanggilan seperti:

call

atau:

callvirt

String literal:

"Hello World"

dapat direpresentasikan menggunakan:

ldstr

Percabangan:

if (age >= 18)
{
    ...
}

pada level IL dapat direpresentasikan menggunakan berbagai instruksi branch dan comparison. Dengan demikian, compiler melakukan lebih dari sekadar mengganti kata-kata C# dengan kata-kata IL. Compiler melakukan transformasi dari struktur program tingkat tinggi menjadi representasi instruksi yang dapat dimengerti oleh runtime .NET.

IL dan Metadata

Ada satu hal penting yang perlu diperhatikan: assembly .NET tidak hanya berisi IL. Assembly juga memiliki metadata.

Metadata berisi informasi mengenai struktur program, misalnya:

Type
Method
Field
Property
Parameter
Assembly Reference

Misalnya terdapat class:

public class Person
{
    public string Name { get; set; }

    public void SayHello()
    {
        Console.WriteLine(Name);
    }
}

Runtime tidak hanya membutuhkan instruksi untuk method SayHello.

Runtime juga perlu mengetahui bahwa:

Person
 ├── Property: Name
 └── Method: SayHello

Informasi struktural tersebut merupakan bagian dari metadata.

Karena itu, gambaran assembly menjadi:

.NET Assembly
│
├── IL
│
├── Metadata
│
├── Type Information
│
└── References

IL dan metadata bekerja bersama untuk membentuk informasi yang dibutuhkan runtime.

Runtime Optimization

IL memungkinkan runtime melakukan compilation menuju native code pada environment tempat program benar-benar dijalankan.

JIT dapat mengetahui target environment dan menghasilkan machine code yang sesuai.

Pemisahan Tanggung Jawab

Compiler dan runtime dapat memiliki tanggung jawab yang berbeda.

Compiler:

C# → IL

Runtime/JIT:

IL → Machine Code

Pemisahan ini membuat arsitektur .NET menjadi lebih fleksibel.

IL Tidak Berarti Aplikasi Selalu Portable Tanpa Batas

Penting untuk tidak menarik kesimpulan terlalu jauh. Adanya IL tidak berarti semua aplikasi .NET otomatis dapat dijalankan di semua sistem operasi tanpa perubahan. Aplikasi dapat memiliki dependency yang spesifik terhadap platform tertentu. Contohnya, sebuah aplikasi dapat menggunakan API native Windows tertentu. Dalam kasus tersebut, IL memang bersifat portable, tetapi dependency aplikasi belum tentu portable.

Selain itu, aplikasi .NET juga dapat bergantung pada runtime version, native library, operating system API, atau konfigurasi tertentu. Jadi, IL memberikan fondasi portability, bukan jaminan bahwa seluruh aplikasi selalu portable.

Bagian 6: Common Type System (CTS)

Pada bagian sebelumnya telah dijelaskan bahwa C#, Visual Basic, dan F# dapat menghasilkan IL yang berjalan di atas .NET. Hal ini menimbulkan sebuah pertanyaan penting:

Jika setiap bahasa memiliki syntax dan aturan masing-masing, bagaimana tipe data dari bahasa yang berbeda dapat tetap dipahami secara konsisten oleh .NET?

Misalnya, C# memiliki syntax:

int age = 26;

Sementara bahasa lain dapat menggunakan syntax yang berbeda untuk menyatakan konsep yang sama. Jika setiap bahasa memiliki definisi tipe yang sepenuhnya berbeda, runtime akan kesulitan memahami hubungan antara tipe-tipe tersebut.

.NET menyelesaikan persoalan ini melalui sebuah fondasi yang disebut Common Type System, atau CTS.

Apa Itu Common Type System?

Common Type System (CTS) adalah seperangkat aturan yang mendefinisikan bagaimana tipe didefinisikan, direpresentasikan, dan digunakan di dalam lingkungan .NET. CTS menyediakan fondasi type system yang digunakan oleh berbagai bahasa yang berjalan di atas .NET.

Dengan adanya CTS, sebuah tipe tidak hanya memiliki arti berdasarkan syntax bahasa sumbernya. Tipe tersebut juga memiliki representasi dan aturan yang dipahami oleh ekosistem .NET.

Secara sederhana:

C# ─────────┐
            │
VB.NET ─────┼──► CTS
            │
F# ─────────┘

Masing-masing bahasa tetap memiliki syntax dan fitur sendiri, tetapi tipe-tipe yang dihasilkan dapat dipetakan ke konsep yang didefinisikan oleh CTS.

Mengapa CTS Dibutuhkan?

Tanpa type system bersama, setiap bahasa dapat memiliki cara sendiri dalam mendefinisikan tipe.

Misalnya secara konseptual:

Bahasa A
 └── Integer versi A

Bahasa B
 └── Integer versi B

Bahasa C
 └── Integer versi C

Jika ketiganya benar-benar berbeda pada level runtime, sebuah method yang menerima integer dari Bahasa A belum tentu dapat menerima integer dari Bahasa B.

.NET menginginkan model yang lebih terintegrasi.

Dengan CTS, berbagai bahasa dapat memiliki konsep tipe yang dipetakan ke fondasi yang sama:

C# Integer ─────┐
                │
VB Integer ─────┼──► CTS Type System
                │
F# Integer ─────┘

Dengan demikian, runtime memiliki aturan yang konsisten untuk memahami tipe tersebut.

CTS Tidak Mengatur Syntax Bahasa

CTS tidak menentukan bagaimana syntax C# harus ditulis.

Sebagai contoh, CTS tidak mengatakan bahwa sebuah integer harus ditulis seperti:

int age = 26;

Itu merupakan aturan bahasa C#.

Bahasa lain dapat menggunakan syntax berbeda.

Perbedaannya dapat digambarkan seperti ini:

C# Syntax
    │
    ▼
Compiler C#
    │
    ▼
CTS-compatible type

dan:

VB.NET Syntax
    │
    ▼
VB Compiler
    │
    ▼
CTS-compatible type

Jadi, CTS berada di level yang lebih fundamental daripada syntax bahasa.

Bahasa menentukan cara programmer menulis kode, sedangkan CTS menentukan fondasi bagaimana tipe tersebut dipahami dalam ekosistem .NET.

Contoh: Integer

Salah satu contoh paling mudah adalah integer.

Dalam C# dapat ditulis:

int number = 10;

int merupakan keyword C# yang digunakan untuk menyatakan tipe integer 32-bit bertanda.

Di balik syntax tersebut, C# memetakan int ke tipe .NET:

System.Int32

Jadi:

int

dan:

System.Int32

merujuk pada tipe yang sama.

Contoh:

int number = 10;
System.Int32 anotherNumber = 20;

Keduanya menggunakan System.Int32.

Hal ini menunjukkan bahwa keyword bahasa seperti int tidak selalu merupakan nama fundamental dari tipe pada level .NET.

int adalah alias yang disediakan C# untuk System.Int32.

Contoh Tipe Lain

Hal yang sama berlaku pada banyak tipe dasar lainnya.

Beberapa contoh umum:

Contohnya:

string name = "Haekal";

secara fundamental menggunakan:

System.String

Sedangkan:

object value = 10;

menggunakan:

System.Object

Jadi keyword yang terlihat di source code C# merupakan bagian dari bahasa C#, sedangkan tipe yang mendasarinya merupakan bagian dari type system .NET.

CTS Mendefinisikan Berbagai Kategori Tipe

CTS tidak hanya mendefinisikan tipe seperti integer dan string. CTS juga mendefinisikan konsep yang lebih luas tentang berbagai jenis tipe yang dapat ada di lingkungan .NET.

Beberapa konsep penting di antaranya adalah:

• value type

• reference type

• class

• interface

• struct

• enum

• delegate

• array

• built-in type

Konsep-konsep tersebut menjadi bagian dari fondasi type system .NET.

Misalnya C# memiliki:

struct Point
{
    public int X;
    public int Y;
}

dan:

class Person
{
    public string Name { get; set; }
}

Keduanya menggunakan konsep type yang berbeda. Point merupakan value type, sedangkan Person merupakan reference type. CTS mendefinisikan aturan fundamental mengenai perbedaan tersebut.

Value Type dan Reference Type

Salah satu konsep penting dalam CTS adalah pembagian tipe menjadi value type dan reference type.

Secara sederhana:

CTS
│
├── Value Type
│
└── Reference Type

Value Type

Value type secara konseptual menyimpan nilainya secara langsung.

Contohnya:

int age = 26;

int merupakan value type.

Struct juga merupakan value type:

struct Point
{
    public int X;
    public int Y;
}

Begitu pula enum:

enum Status
{
    Pending,
    Completed
}

CTS menentukan karakteristik fundamental value type tersebut.

Reference Type

Reference type digunakan untuk tipe yang merepresentasikan object dan reference terhadap object tersebut.

Contohnya:

class Person
{
    public string Name { get; set; }
}

Person merupakan reference type.

Beberapa tipe reference type lainnya meliputi:

class
interface
delegate
array
string
object

Pembagian value type dan reference type merupakan bagian penting dari bagaimana .NET memahami object dan nilai.

Semua Tipe Memiliki Fondasi yang Sama

Salah satu konsep penting dalam CTS adalah adanya hierarki type system.

Pada tingkat paling dasar terdapat:

System.Object

Banyak reference type pada .NET pada akhirnya memiliki hubungan dengan System.Object.

Misalnya:

class Person
{
}

secara konsep memiliki hubungan dengan:

System.Object
    ↑
  Person

Hal ini memungkinkan konsep seperti polymorphism dan casting bekerja secara konsisten.

Contohnya:

object value = "Hello";

string merupakan reference type dan dapat diperlakukan sebagai object.

Kemudian:

object value = 123;

juga dapat dilakukan.

Dalam kasus integer, terjadi proses boxing, karena int merupakan value type yang ditempatkan dalam bentuk object. Konsep tersebut merupakan bagian dari type system .NET dan bukan sekadar fitur syntax C#.

CTS dan Class

CTS juga mendefinisikan konsep class sebagai salah satu bentuk reference type.

Dalam C#:

class Person
{
    public string Name { get; set; }
}

class tersebut memiliki:

• nama type;

• property;

• method;

• field;

• dan anggota lainnya.

Bahasa lain yang berjalan di atas .NET dapat memiliki cara berbeda untuk mendefinisikan sebuah class, tetapi hasil akhirnya harus mengikuti aturan type system yang dapat dipahami oleh runtime.

Dengan demikian, konsep class tidak hanya milik syntax C#.

C# memiliki keyword:

class

tetapi konsep class pada level .NET merupakan bagian dari CTS.

CTS dan Interface

CTS juga mendukung konsep interface.

Dalam C#:

interface IAnimal
{
    void Speak();
}

Interface mendefinisikan kontrak yang dapat diimplementasikan oleh class.

Contohnya:

class Dog : IAnimal
{
    public void Speak()
    {
        Console.WriteLine("Bark");
    }
}

Konsep interface tersebut tidak hanya penting bagi C#, tetapi merupakan bagian dari model type system yang dapat dipahami oleh .NET.

Karena itu, bahasa lain yang mendukung konsep interface dapat menghasilkan type yang tetap dapat digunakan dalam ekosistem .NET.

CTS dan Struct

Struct merupakan bentuk value type.

Dalam C#:

struct Point
{
    public int X;
    public int Y;
}

Berbeda dengan class:

class Point
{
    public int X;
    public int Y;
}

keduanya memiliki syntax yang mirip, tetapi karakteristik type-nya berbeda.

CTS mendefinisikan bahwa struct merupakan value type, sedangkan class merupakan reference type. Ini merupakan contoh bagaimana CTS menyediakan aturan yang lebih fundamental daripada syntax bahasa.

CTS dan Enum

Enum juga merupakan bagian dari type system .NET.

Contoh:

enum OrderStatus
{
    Pending,
    Paid,
    Shipped
}

Enum memungkinkan sekumpulan nilai bernama direpresentasikan sebagai sebuah type.

CTS menentukan karakteristik enum tersebut sehingga runtime dan bahasa .NET lainnya dapat memahami bahwa type tersebut merupakan enum, bukan sekadar kumpulan constant biasa.

CTS dan Delegate

Delegate merupakan konsep lain yang didukung oleh CTS.

Dalam C#:

delegate void MessageHandler(string message);

Delegate dapat digunakan untuk merepresentasikan reference terhadap method dengan signature tertentu.

Contohnya:

void PrintMessage(string message)
{
    Console.WriteLine(message);
}

Kemudian method tersebut dapat digunakan melalui delegate yang sesuai.

Konsep delegate menjadi bagian dari type system .NET sehingga dapat direpresentasikan dalam metadata dan digunakan oleh runtime.

CTS Tidak Membuat Semua Bahasa Menjadi Sama

Penting untuk memahami batasan CTS.

CTS tidak berarti C#, VB.NET, dan F# memiliki syntax yang sama.

Setiap bahasa tetap memiliki karakteristik sendiri. Misalnya C# memiliki fitur dan aturan syntax tertentu yang tidak harus tersedia dalam bahasa lain.

Gambaran yang lebih tepat adalah:

             C#
              │
              │
             CTS
              │
              │
       .NET Type System
              │
        ┌─────┴─────┐
        │           │
     Runtime      Libraries

Bahasa tetap berbeda pada level syntax dan fitur bahasa.

Namun ketika type tersebut masuk ke ekosistem .NET, terdapat fondasi bersama yang memungkinkan runtime memahami type tersebut.

CTS sebagai Kontrak Type System

CTS dapat dipandang sebagai sebuah kontrak bersama mengenai tipe.

Misalnya terdapat sebuah type:

Person

Runtime perlu memiliki cara yang konsisten untuk mengetahui:

Nama type
Base type
Method
Property
Field
Interface
Accessibility
Parameter
Return type

CTS menyediakan aturan mengenai bagaimana informasi tersebut direpresentasikan dalam type system .NET. Dengan begitu, runtime tidak perlu memahami setiap bahasa secara terpisah.

Runtime tidak perlu memiliki aturan seperti:

Jika kode berasal dari C#, lakukan X.

Jika kode berasal dari VB.NET, lakukan Y.

Jika kode berasal dari F#, lakukan Z.

Sebaliknya, setelah compiler masing-masing bahasa menghasilkan representasi yang sesuai dengan aturan .NET, runtime dapat bekerja berdasarkan type system yang sama.

Hubungan CTS dengan Compiler

Setiap bahasa memiliki compiler sendiri.

Secara konseptual:

C# Source
    ↓
C# Compiler
    ↓
CTS-compatible .NET Types
    ↓
IL + Metadata

Bahasa lain:

VB.NET Source
    ↓
VB Compiler
    ↓
CTS-compatible .NET Types
    ↓
IL + Metadata

Dan:

F# Source
    ↓
F# Compiler
    ↓
CTS-compatible .NET Types
    ↓
IL + Metadata

Compiler bertanggung jawab menerjemahkan syntax bahasa masing-masing ke bentuk yang sesuai dengan type system dan runtime .NET. Inilah yang memungkinkan satu runtime menangani program yang berasal dari berbagai bahasa.

CTS Bukan CLR

Dua istilah ini sering muncul berdekatan, tetapi memiliki peran yang berbeda. CTS adalah aturan mengenai type system. CLR adalah runtime yang menjalankan managed code dan menyediakan berbagai layanan runtime.

Secara sederhana:

CTS
│
│ mendefinisikan aturan tipe
▼
.NET Type System


CLR
│
│ menjalankan managed code
▼
.NET Runtime

CTS menjelaskan bagaimana tipe didefinisikan dan berperilaku dalam ekosistem .NET. CLR bertugas menjalankan program yang menggunakan tipe-tipe tersebut. Keduanya saling berkaitan, tetapi bukan komponen yang sama.

CTS Bukan C# Type System

C# memiliki aturan type system yang lebih spesifik sebagai sebuah bahasa.

Sebagai contoh, C# memiliki fitur seperti:

var
dynamic
nullable reference types
pattern matching

Tidak semua detail tersebut merupakan bagian dari CTS dengan cara yang sama.

CTS berada pada level fondasi yang lebih umum.

Hubungannya dapat digambarkan:

C# Type System
       │
       ▼
Common Type System
       │
       ▼
.NET Runtime

C# dapat menyediakan fitur tambahan di atas fondasi tersebut selama compiler dapat menerjemahkan dan merepresentasikannya dengan cara yang sesuai dengan runtime dan metadata .NET.

Batasan Interoperability

CTS memang memungkinkan bahasa-bahasa .NET berbagi fondasi type system, tetapi bukan berarti semua fitur setiap bahasa dapat digunakan tanpa batas di bahasa lain. Misalnya sebuah bahasa dapat memiliki fitur yang tidak memiliki representasi langsung atau nyaman untuk bahasa lain.

Karena itu, terdapat perbedaan antara:

dapat direpresentasikan oleh .NET

dan:

dapat digunakan dengan nyaman oleh semua bahasa .NET.

CTS menyelesaikan masalah fondasi type system, tetapi interoperability juga dipengaruhi oleh compiler, metadata, aturan bahasa, dan fitur khusus masing-masing bahasa.

Gambaran Besar

Setelah memahami CTS, hubungan antara beberapa komponen .NET menjadi lebih jelas:

C# ──────────┐
             │
VB.NET ──────┼──► Compiler
             │       │
F# ──────────┘       ▼
                    IL
                     +
                  Metadata
                     │
                     ▼
                    CTS
                     │
                     ▼
               .NET Runtime

CTS menjadi fondasi yang memastikan bahwa konsep tipe dalam ekosistem .NET memiliki aturan bersama.

C# boleh menggunakan keyword:

int

VB.NET dapat memiliki syntax berbeda untuk integer.

F# juga memiliki syntax sendiri.

Namun pada level .NET, tipe tersebut dapat dipetakan ke fondasi type system yang sama, seperti:

System.Int32

Begitu pula dengan konsep:

class
interface
struct
enum
delegate
array
object
string

Konsep-konsep tersebut memiliki representasi dan aturan yang dapat dipahami oleh ekosistem .NET.

Bagian 7: Interoperability Antar Bahasa

Manfaat dari CTS dan CLS akan lebih terasa lewat contoh konkret. Misalnya ada sebuah library bernama MyLibrary.dll yang dibuat menggunakan C#.

Selama API dan dependensinya mengikuti aturan kompatibilitas yang sudah dibahas sebelumnya, library tersebut bisa dipakai oleh aplikasi yang ditulis dalam bahasa .NET lain, bukan hanya oleh aplikasi C#.

C# Library
     ↓
MyLibrary.dll
     ↓
┌──────────┬──────────┐
│          │          │
C#       VB.NET       F#

Hal yang sama berlaku sebaliknya. Sebuah library yang ditulis dalam F# juga bisa dipakai oleh aplikasi C#, selama kondisinya memenuhi aturan kompatibilitas tadi.

Kemampuan seperti inilah yang membuat ekosistem .NET tidak terpecah menjadi runtime yang berbeda-beda untuk setiap bahasa. Semua bahasa berbagi fondasi tipe dan aturan kompatibilitas yang sama, sehingga library bisa saling dipakai lintas bahasa tanpa hambatan berarti.

Sampai titik ini, pembahasan baru sampai pada IL sebagai hasil compilation. Namun IL sendiri tidak pernah berdiri sendirian begitu saja. Ia selalu dibungkus dalam sesuatu yang lebih besar, dan itulah yang akan dibahas berikutnya.

Bagian 7: Apa Itu Assembly?

Setelah proses compilation selesai, yang terlihat di folder project bukan file bernama IL. Hasil build biasanya berupa file dengan ekstensi yang sudah familiar, seperti:

MyApp.dll

atau:

MyApp.exe

Lalu muncul pertanyaan:

Apa sebenarnya isi dari file-file tersebut?

Jawabannya adalah assembly.

Assembly merupakan salah satu unit penting dalam .NET. Assembly menjadi wadah hasil compilation sekaligus membawa berbagai informasi yang dibutuhkan oleh .NET runtime untuk memahami, memuat, dan menjalankan kode.

Secara sederhana:

C# Source Code
      │
      │ Compiler
      ▼
.NET Assembly
      │
      ├── IL
      ├── Metadata
      ├── Manifest
      ├── Type Information
      ├── References
      └── Resources

Assembly dapat dikatakan sebagai bentuk hasil compilation yang siap digunakan oleh ekosistem .NET.

Assembly Bukan Sekadar DLL

Ada perbedaan penting antara file fisik dan konsep assembly. DLL dan EXE adalah bentuk file yang terlihat di file system. Sedangkan assembly adalah konsep .NET yang menggambarkan unit deployment dan identitas yang berisi IL, metadata, manifest, serta resource yang berkaitan.

Dengan kata lain:

.dll ──► dapat menjadi sebuah .NET Assembly
.exe ──► dapat menjadi sebuah .NET Assembly

Jadi, istilah DLL dan assembly tidak sepenuhnya sinonim. DLL adalah format file. Assembly adalah unit logis dalam .NET. Sebuah assembly dapat dikemas dalam file .dll maupun .exe.

Apa Perbedaan DLL dan EXE?

Dalam konteks .NET modern, baik .dll maupun .exe dapat berisi IL dan metadata. Perbedaan utamanya adalah cara file tersebut dimaksudkan untuk digunakan.

DLL

DLL merupakan singkatan dari Dynamic Link Library. Dalam aplikasi .NET, file .dll umumnya digunakan sebagai library, yaitu kumpulan kode yang digunakan oleh aplikasi lain atau oleh komponen .NET lainnya.

Contohnya sebuah project library:

MyLibrary
   │
   ▼
MyLibrary.dll

Assembly tersebut dapat berisi:

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

Aplikasi lain kemudian dapat mereferensikan assembly tersebut:

MyApp
 │
 ├── MyApp.dll
 │
 └── MyLibrary.dll

MyApp dapat menggunakan type yang tersedia di MyLibrary.dll. Jadi, fungsi utama DLL dalam konteks ini adalah menyediakan kode atau komponen yang dapat digunakan oleh aplikasi lain.

Namun, ada satu hal penting:

DLL .NET tidak berarti file tersebut tidak dapat dijalankan sama sekali.

Sebuah DLL dapat berisi entry point dalam kondisi tertentu, misalnya hasil build aplikasi .NET yang menghasilkan assembly .dll sebagai bentuk utama aplikasi. Assembly tersebut dapat dijalankan menggunakan dotnet, selama memang merupakan executable assembly yang memiliki entry point dan runtime configuration yang sesuai. Jadi, istilah "DLL = tidak bisa dijalankan" terlalu sederhana untuk .NET modern.

EXE

EXE merupakan singkatan dari executable. File .exe secara umum digunakan untuk sesuatu yang dimaksudkan sebagai executable application.

Misalnya:

MyApp.exe

File tersebut dapat menjadi entry point aplikasi yang dijalankan pada Windows. Dalam model .NET tertentu, executable .NET dapat berupa PE file yang berisi IL dan metadata, bukan berarti seluruh isinya sudah berupa native machine code.

Dengan demikian:

MyApp.exe
   │
   ├── IL
   ├── Metadata
   ├── Manifest
   └── Entry Poin

Ketika aplikasi dijalankan, .NET runtime dapat memuat assembly tersebut dan kemudian menjalankan entry point-nya.

DLL dan EXE Sama-Sama Dapat Menjadi Assembly

Perbedaan ini menjadi lebih jelas jika dilihat seperti berikut:

                 .NET Assembly
                      │
             ┌────────┴────────┐
             │                 │
           .dll               .exe
             │                 │
        Library /          Executable
        Component          Application

Keduanya dapat memiliki:

IL
Metadata
Manifest
Type Information
References
Resources

Yang membedakan terutama adalah peran dan cara assembly tersebut digunakan. DLL biasanya digunakan sebagai library atau dependency. EXE biasanya digunakan sebagai executable application.

Contoh Struktur Aplikasi

Misalnya terdapat aplikasi sederhana:

MyApp/
│
├── MyApp.dll
├── MyApp.exe
├── MyApp.deps.json
├── MyApp.runtimeconfig.json
└── MyApp.pdb

Pada aplikasi .NET modern, file-file tersebut memiliki fungsi yang berbeda.

MyApp.dll

Berisi assembly utama aplikasi, termasuk IL dan metadata.

MyApp.exe

Pada target tertentu, menjadi executable launcher atau executable entry point yang digunakan untuk menjalankan aplikasi.

MyApp.deps.json

Menyimpan informasi dependency aplikasi, termasuk dependency library yang dibutuhkan.

MyApp.runtimeconfig.json

Menyimpan informasi mengenai runtime .NET yang dibutuhkan aplikasi.

MyApp.pdb

Berisi debugging symbols yang membantu debugger menghubungkan hasil compilation dengan source code.

Tidak semua jenis project menghasilkan kombinasi file yang persis sama. Bentuk output bergantung pada target framework, runtime, jenis aplikasi, dan konfigurasi publish.

DLL .NET Tidak Sama dengan DLL Native

Istilah DLL sudah digunakan jauh sebelum .NET. Pada Windows, DLL native biasanya berisi machine code yang ditujukan untuk arsitektur tertentu. Misalnya sebuah native DLL x64 dapat berisi instruksi machine code x86-64.

.NET DLL memiliki karakteristik berbeda.

Sebuah .NET DLL biasanya berisi:

.NET DLL
│
├── IL
├── Metadata
├── Manifest
└── Resources

Bukan berarti tidak ada native code sama sekali dalam ekosistem .NET. .NET juga dapat berinteraksi dengan native libraries dan dapat menghasilkan native executable melalui teknologi seperti Native AOT.

Namun untuk model managed .NET yang umum:

.dll
   │
   └── IL + Metadata
             │
             ▼
        .NET Runtime
             │
             ▼
            JIT
             │
             ▼
       Machine Code

Karena itu, sebuah .dll hasil build aplikasi .NET tidak boleh langsung diasumsikan sebagai native machine code.

Assembly Memiliki Identitas

Assembly bukan hanya kumpulan IL. Assembly juga memiliki identitas.

Secara umum, identitas assembly mencakup informasi seperti:

Assembly Name
Version
Culture
Public Key / Strong Name Information

Informasi tersebut digunakan .NET untuk membedakan dan mengidentifikasi assembly.

Misalnya terdapat:

MyLibrary
Version 1.0.0.0

dan:

MyLibrary
Version 2.0.0.0

Keduanya dapat merupakan assembly dengan nama yang sama tetapi versi berbeda. Informasi mengenai assembly tersebut menjadi bagian dari metadata dan manifest.

Manifest

Salah satu bagian penting dari assembly adalah manifest. Manifest berisi informasi yang menggambarkan assembly itu sendiri.

Secara sederhana:

Assembly
│
├── Manifest
│    ├── Assembly Name
│    ├── Version
│    ├── Culture
│    ├── References
│    └── Other Assembly Metadata
│
├── IL
├── Type Metadata
└── Resources

Manifest membantu runtime mengetahui identitas assembly dan dependency yang terkait dengannya.

Misalnya sebuah assembly menggunakan assembly lain:

MyApp.dll
   │
   ├── menggunakan MyLibrary.dll
   └── menggunakan System.Text.Json

Informasi mengenai reference tersebut dapat direpresentasikan dalam metadata assembly.

References

Sebuah assembly hampir tidak pernah berdiri sendirian. Sebuah aplikasi biasanya menggunakan berbagai library.

Contohnya:

MyApp.dll
   │
   ├── MyLibrary.dll
   ├── System.Text.Json
   └── Other Dependency

Assembly menyimpan informasi mengenai dependency atau reference yang digunakannya. Runtime kemudian dapat menggunakan informasi tersebut ketika memuat aplikasi dan dependency yang diperlukan.

Resources

Assembly juga dapat membawa resources. Resources dapat berupa data yang bukan merupakan IL secara langsung, misalnya:

Images
Strings
Localization Resources
Embedded Files

Contohnya aplikasi dapat memiliki resource untuk beberapa bahasa:

Resources
├── English
├── Indonesian
└── Japanese

Resource tersebut dapat dikemas bersama assembly sehingga aplikasi dapat mengaksesnya saat runtime.

Assembly sebagai Unit Deployment

Assembly juga penting karena menjadi salah satu unit deployment dalam .NET. Misalnya sebuah aplikasi terdiri dari:

MyApp.dll
MyLibrary.dll
Logging.dll
Database.dll

Setiap file dapat menjadi assembly yang berbeda.

Hubungannya:

Application
│
├── MyApp.dll
│
├── MyLibrary.dll
│
├── Logging.dll
│
└── Database.dll

Runtime dapat memuat assembly-assembly tersebut sesuai kebutuhan aplikasi. Dengan model ini, sebuah aplikasi tidak harus memiliki seluruh kode dalam satu file. Kode dapat dipisahkan menjadi beberapa library dengan tanggung jawab yang berbeda. Hal ini juga mendukung struktur aplikasi yang lebih modular.

DLL sebagai Library, EXE sebagai Application

Perbedaan paling praktis dapat diringkas sebagai berikut:

Kolom terakhir perlu dipahami sebagai penggunaan umum, bukan aturan mutlak. Yang paling penting adalah membedakan bentuk file dari peran assembly.

Bagaimana dengan dotnet run?

Pada aplikasi .NET modern, perintah:

dotnet run

tidak berarti compiler C# menghasilkan sebuah file executable native lalu CPU langsung menjalankannya.

Secara konseptual, prosesnya lebih dekat dengan:

Source Code
     ↓
Build
     ↓
.NET Assembly
     ↓
.NET Runtime
     ↓
Execution

Untuk aplikasi tertentu, hasil build utama dapat berupa:

MyApp.dll

Kemudian aplikasi dijalankan melalui host dotnet:

dotnet MyApp.dll

Di sini dotnet bertindak sebagai host yang memulai .NET runtime dan meminta runtime menjalankan assembly tersebut.

Pada konfigurasi lain, terutama deployment tertentu di Windows, dapat tersedia:

MyApp.exe

yang dapat digunakan sebagai executable aplikasi.

Jadi, .dll dan .exe tidak sebaiknya dipahami hanya sebagai:

.dll = library
.exe = program

Dalam .NET modern, hubungan keduanya lebih fleksibel.

Native Executable dan Managed Executable

Perbedaan ini juga penting untuk memahami apa yang sebenarnya terjadi saat aplikasi dijalankan. Sebuah executable native yang dikompilasi menggunakan compiler native dapat berisi machine code yang siap dijalankan CPU.

Sementara executable .NET dalam model managed code dapat berisi IL dan membutuhkan .NET runtime untuk menjalankan managed code tersebut.

Secara sederhana:

Native Application
      │
      ▼
Machine Code
      │
      ▼
CPU

Sedangkan:

.NET Application
      │
      ▼
IL + Metadata
      │
      ▼
.NET Runtime
      │
      ▼
Native Machine Code
      │
      ▼
CPU

Model ini kembali menghubungkan pembahasan assembly dengan IL yang telah dijelaskan sebelumnya.

Bagian 8: Metadata

Salah satu alasan metadata menjadi bagian penting dalam assembly adalah karena metadata tersebut dapat dibaca kembali ketika aplikasi sedang berjalan.

.NET menyediakan mekanisme bernama Reflection yang memungkinkan program membaca informasi mengenai assembly dan type secara dinamis. Dengan Reflection, program dapat mengetahui informasi seperti nama class, property, method, field, constructor, interface, hingga attribute yang terdapat pada sebuah assembly.

Sebagai contoh, ketika terdapat class:

public class Person
{
    public string Name { get; set; }

    public void SayHello()
    {
        Console.WriteLine(Name);
    }
}

informasi mengenai Person, Name, dan SayHello() tidak hanya digunakan oleh compiler. Informasi tersebut juga direpresentasikan dalam metadata assembly sehingga dapat dibaca kembali oleh runtime melalui Reflection.

Secara sederhana:

Source Code
     ↓
Compiler
     ↓
Assembly
 ┌───────────────┐
 │ IL            │
 │ Metadata      │
 │ Type Info     │
 │ Attributes    │
 └───────┬───────┘
         │
         ▼
     Reflection
         │
         ▼
Membaca struktur
program saat runtime

Dengan Reflection, sebuah program bahkan dapat memeriksa assembly yang tidak diketahui ketika source code ditulis. Misalnya, aplikasi plugin dapat memuat sebuah .dll, kemudian mencari class tertentu, memeriksa interface yang diimplementasikan, menemukan method, dan membuat instance secara dinamis.

Pembahasan lebih lengkap mengenai cara kerja dan penggunaan Reflection tersedia dalam artikel:

Memahami Reflection di C#: Cara Kerja, Penggunaan, dan Contoh Implementasi

Assembly dan Attribute

Metadata juga berkaitan dengan Attribute.

Attribute memungkinkan informasi tambahan ditempelkan pada class, method, property, parameter, assembly, dan berbagai elemen kode lainnya.

Contohnya:

[Obsolete("Gunakan method baru")]
public void OldMethod()
{
}

Obsolete bukan sekadar komentar. Attribute tersebut menjadi bagian dari informasi yang dapat diketahui oleh compiler dan juga dapat direpresentasikan dalam metadata assembly.

Karena itu, secara konseptual:

[Obsolete]
    │
    ▼
Compiler
    │
    ▼
Assembly Metadata
    │
    ▼
Reflection
    │
    ▼
Attribute dapat dibaca
saat runtime

Hubungan antara Attribute dan Reflection sangat erat. Attribute dapat digunakan untuk memberikan informasi deklaratif pada kode, sedangkan Reflection dapat digunakan untuk membaca informasi tersebut ketika aplikasi berjalan.

Misalnya sebuah framework dapat mencari semua class yang memiliki attribute tertentu, kemudian menggunakan informasi tersebut untuk menentukan bagaimana class tersebut harus diproses.

Pembahasan mengenai Attribute dan bagaimana konsep tersebut digunakan dalam C# dapat dilanjutkan melalui artikel terkait:

Memahami Attribute di C#: Metadata yang Membuat Kode Lebih Fleksibel dan Powerful

Dengan demikian, metadata bukan sekadar informasi tambahan yang tersimpan di dalam assembly. Metadata menjadi salah satu fondasi yang memungkinkan berbagai kemampuan .NET bekerja secara dinamis, termasuk Reflection, Attribute, tooling, serialization, dependency injection, dan berbagai framework lainnya.

Hubungan sederhananya dapat dirangkum sebagai:

C# Source Code
      ↓
    Compiler
      ↓
.NET Assembly
      │
      ├── IL
      │
      └── Metadata
             │
             ├── Type Information
             ├── Method Information
             ├── Property Information
             └── Attribute Information
                     │
                     ▼
                 Reflection

Inilah alasan pembahasan assembly tidak berhenti pada IL. IL menjelaskan instruksi program, sedangkan metadata menjelaskan struktur program. Keduanya berada di dalam assembly dan bersama-sama memberikan informasi yang dibutuhkan oleh ekosistem .NET.

Bagian 9: Apa Itu .NET Runtime?

Pada bagian sebelumnya, proses compilation menghasilkan sebuah file assembly seperti MyApp.dll. File tersebut sudah berisi IL (Intermediate Language) dan metadata yang menjelaskan berbagai informasi tentang program, seperti tipe, method, field, dan referensi terhadap assembly lain.

Namun, MyApp.dll belum menjadi program yang dapat langsung dijalankan oleh CPU. IL bukanlah instruksi mesin yang secara langsung dipahami oleh prosesor. Assembly masih membutuhkan sebuah environment yang bertugas memuatnya, menyediakan berbagai layanan runtime, menerjemahkan IL menjadi instruksi mesin, mengelola memory, menangani exception, dan melakukan berbagai pekerjaan lain selama program berjalan. Environment tersebut disebut .NET Runtime.

Secara konseptual, posisi .NET Runtime berada setelah assembly:

Source Code
    ↓
C# Compiler
    ↓
Assembly (.dll / .exe)
    ↓
.NET Runtime
    ↓
Execution

.NET Runtime dapat dipandang sebagai lingkungan eksekusi yang menyediakan berbagai layanan agar kode .NET dapat benar-benar berjalan.

Assembly Bukan Program yang Langsung Dieksekusi CPU

Hal penting yang perlu dipahami adalah bahwa file seperti:

MyApp.dll

bukan sekadar kumpulan instruksi CPU.

Di dalamnya terdapat IL dan metadata. Sebagai contoh, kode C# sederhana:

int Add(int a, int b)
{
    return a + b;
}

tidak langsung berubah menjadi instruksi khusus untuk prosesor Intel atau ARM ketika dikompilasi menjadi assembly. Compiler menghasilkan IL yang bersifat relatif independen terhadap arsitektur CPU.

Secara sederhana, alurnya dapat digambarkan seperti ini:

C# Source Code
      ↓
   Compiler
      ↓
      IL
      ↓
   MyApp.dll
      ↓
 .NET Runtime
      ↓
 Machine Code
      ↓
     CPU

Pendekatan ini merupakan salah satu alasan mengapa aplikasi .NET dapat berjalan pada berbagai sistem operasi dan arsitektur CPU. Assembly yang sama secara konsep dapat dieksekusi pada environment yang berbeda selama tersedia runtime yang sesuai.

Namun, .NET Runtime tidak hanya bertugas mengubah IL menjadi machine code. Selama aplikasi berjalan, terdapat banyak pekerjaan lain yang harus dilakukan.

Apa Saja yang Dilakukan .NET Runtime?

.NET Runtime menyediakan berbagai layanan yang dibutuhkan aplikasi selama execution. Beberapa layanan penting tersebut antara lain:

.NET Runtime
│
├── Assembly Loading
├── Type System
├── JIT Compilation
├── Memory Management
├── Garbage Collection
├── Exception Handling
├── Threading
├── Interoperability
└── Runtime Services lainnya

Setiap bagian memiliki tanggung jawab yang berbeda.

1. Assembly Loading

Sebelum kode dalam sebuah assembly dapat digunakan, assembly tersebut perlu dimuat ke dalam proses.

Misalnya, MyApp.dll memiliki dependency terhadap assembly lain:

MyApp.dll
   │
   ├── LibraryA.dll
   ├── LibraryB.dll
   └── LibraryC.dll

Runtime bertanggung jawab dalam proses loading assembly yang diperlukan oleh aplikasi.

Hal ini juga menjelaskan mengapa aplikasi .NET dapat menggunakan library eksternal. Ketika sebuah program menggunakan type dari library lain, runtime perlu menemukan dan memuat assembly yang menyediakan type tersebut. Jadi, MyApp.dll tidak selalu berdiri sendiri. Sebuah aplikasi biasanya terdiri dari beberapa assembly yang saling bergantung.

2. Type System

.NET memiliki sistem tipe yang disebut Common Type System (CTS).

CTS mendefinisikan bagaimana type direpresentasikan dan bagaimana type tersebut berperilaku di dalam environment .NET.

Sebagai contoh:

int number = 10;
string name = "Heykal";

int dan string bukan sekadar konsep yang hanya dipahami oleh compiler C#. Keduanya merupakan bagian dari type system .NET.

Hal ini menjadi penting karena .NET tidak hanya mendukung C#.

.NET juga mendukung bahasa lain seperti:

C#
VB.NET
F#

Bahasa-bahasa tersebut dapat menghasilkan IL dan metadata yang mengikuti aturan type system .NET. Dengan demikian, runtime tidak perlu dibuat khusus hanya untuk C#. Runtime bekerja terhadap konsep yang lebih umum, yaitu IL, metadata, dan type system .NET.

3. JIT Compilation

CPU tidak menjalankan IL secara langsung. IL perlu diterjemahkan menjadi machine code yang sesuai dengan arsitektur CPU. Pekerjaan tersebut dapat dilakukan oleh JIT (Just-In-Time) Compiler.

Secara sederhana:

IL
 ↓
JIT Compiler
 ↓
Machine Code
 ↓
CPU

Misalnya terdapat method:

int Add(int a, int b)
{
    return a + b;
}

Compiler C# menghasilkan IL untuk method tersebut. Ketika method perlu dijalankan, runtime dapat menggunakan JIT untuk menghasilkan machine code yang sesuai dengan environment tempat aplikasi berjalan.

Karena proses compilation menuju machine code dilakukan saat runtime, mekanisme ini disebut Just-In-Time compilation. Pembahasan mengenai JIT akan menjadi bagian penting tersendiri karena JIT memiliki banyak optimasi dan tidak selalu sesederhana "seluruh DLL dikompilasi menjadi machine code sekaligus".

4. Memory Management

Program membutuhkan memory untuk menyimpan berbagai data selama execution.

Misalnya:

var user = new User();
var products = new List<Product>();

Pembuatan object seperti new User() membutuhkan memory.

Runtime menyediakan mekanisme untuk mengelola memory tersebut sehingga programmer tidak harus secara manual mengalokasikan dan membebaskan seluruh memory seperti pada beberapa bahasa pemrograman lain. Salah satu bagian terpenting dari mekanisme tersebut adalah Garbage Collector.

5. Garbage Collection

Dalam aplikasi .NET, object yang sudah tidak lagi digunakan pada umumnya dapat dibersihkan secara otomatis oleh Garbage Collector (GC).

Contohnya:

void Process()
{
    var data = new LargeObject();
}

Setelah object tidak lagi memiliki reference yang dapat digunakan, object tersebut pada akhirnya dapat dianggap sebagai garbage.

Garbage Collector bertugas menemukan object yang sudah tidak dapat digunakan dan mengambil kembali memory yang ditempatinya.

Secara sederhana:

new Object()
    ↓
Object berada di memory
    ↓
Tidak lagi digunakan
    ↓
Garbage
    ↓
Garbage Collector
    ↓
Memory dapat digunakan kembali

GC merupakan salah satu alasan penting mengapa aplikasi .NET tidak biasanya mengharuskan programmer memanggil operasi seperti free() untuk setiap object yang dibuat.

Namun, Garbage Collection bukan berarti memory management menjadi tidak penting. Programmer tetap perlu memahami lifetime object, allocation, reference, dan pola penggunaan memory karena allocation yang berlebihan tetap dapat menyebabkan masalah performa.

6. Exception Handling

Runtime juga menyediakan mekanisme untuk menangani exception.

Misalnya:

try
{
    var result = 10 / 0;
}
catch (Exception ex)
{
    Console.WriteLine(ex.Message);
}

Ketika terjadi exception, runtime terlibat dalam proses pencarian handler yang sesuai.

Runtime harus mengetahui:

• exception apa yang terjadi,

• stack frame mana yang sedang aktif,

• apakah terdapat catch yang cocok,

• bagaimana melakukan unwinding terhadap call stack,

• dan bagaimana melanjutkan atau menghentikan execution.

Dengan demikian, try, catch, dan finally bukan hanya fitur syntax C#. Semuanya berhubungan dengan mekanisme exception handling yang disediakan oleh runtime.

7. Threading

Aplikasi modern sering menjalankan banyak pekerjaan secara bersamaan atau menggunakan asynchronous programming.

Contohnya:

await GetDataAsync();

atau:

Task.Run(() => ProcessData());

.NET menyediakan berbagai abstraction untuk concurrency dan asynchronous execution, seperti:

Thread
Task
ThreadPool
Synchronization primitives
async / await

Runtime dan library .NET bekerja bersama untuk menyediakan mekanisme tersebut.

Karena itu, ketika aplikasi menjalankan banyak pekerjaan secara concurrent, terdapat runtime services yang membantu mengelola thread dan execution context yang diperlukan.

8. Interoperability

Aplikasi .NET terkadang perlu berkomunikasi dengan kode atau sistem di luar managed environment .NET.

Misalnya:

.NET Application
      ↓
Native Library
      ↓
Operating System

.NET menyediakan mekanisme interoperability agar managed code dapat berinteraksi dengan native code dan resource tertentu dari operating system. Salah satu contohnya adalah P/Invoke, yang memungkinkan kode .NET memanggil fungsi dari native library. Hal ini penting karena tidak semua kemampuan sistem operasi tersedia sebagai managed API murni di dalam .NET.

Runtime Bukan Sekadar JIT

Sering muncul pemahaman bahwa:

Pemahaman tersebut kurang tepat.

JIT memang merupakan salah satu komponen penting dalam runtime, tetapi runtime memiliki tanggung jawab yang jauh lebih luas.

Secara konseptual:

.NET Runtime
│
├── Assembly Loading
├── Type System Support
├── JIT
├── Garbage Collection
├── Exception Handling
├── Threading
├── Interoperability
└── Runtime Infrastructure

JIT hanya menangani salah satu bagian dari keseluruhan proses, yaitu menghasilkan machine code dari IL. Runtime secara keseluruhan menyediakan environment tempat managed code dapat berjalan.

Lalu Apa yang Menjadi "Jantung" dari Runtime?

Semua layanan tersebut tidak berdiri sendiri-sendiri. Di dalam implementasi .NET terdapat komponen runtime yang menangani berbagai tanggung jawab inti tersebut. Dalam konteks .NET modern, implementasi runtime yang paling umum adalah CoreCLR.

CoreCLR merupakan runtime yang digunakan oleh .NET untuk menjalankan managed code dan menyediakan berbagai kemampuan penting seperti:

CoreCLR
│
├── Execution Engine
├── Garbage Collector
├── JIT Compiler
├── Exception Handling
├── Threading Support
├── Type System Support
└── Runtime Services

Istilah CLR (Common Language Runtime) sering digunakan sebagai istilah konseptual untuk runtime .NET, sedangkan CoreCLR merupakan salah satu implementasi runtime yang digunakan oleh .NET modern. Perbedaan istilah ini penting agar tidak tercampur antara konsep dan implementasi.

Secara sederhana:

CLR
│
│  Konsep runtime .NET
│
└── CoreCLR
       │
       ├── JIT
       ├── GC
       ├── Execution Engine
       └── Runtime Services

Managed Code dan Unmanaged Code

Keberadaan .NET Runtime juga menjelaskan istilah managed code. Kode yang berjalan di bawah pengelolaan .NET Runtime sering disebut managed code.

Contohnya:

var customer = new Customer();

Runtime ikut mengelola berbagai aspek execution kode tersebut, termasuk memory management, type information, exception handling, dan layanan runtime lainnya.

Sebaliknya, native code yang berjalan secara langsung menggunakan fasilitas operating system dan CPU biasanya disebut unmanaged code.

Gambaran sederhananya:

Managed Code
     ↓
.NET Runtime
     ↓
Operating System
     ↓
CPU

sedangkan:

Native / Unmanaged Code
     ↓
Operating System
     ↓
CPU

Istilah "managed" tidak berarti runtime mengontrol setiap instruksi CPU satu per satu. Maksudnya adalah execution environment menyediakan dan mengelola berbagai layanan untuk managed code.

Mengapa .NET Membutuhkan Runtime?

Pertanyaan berikutnya adalah: mengapa C# tidak langsung menghasilkan machine code saja? Sebenarnya compiler dapat menghasilkan native machine code. Namun, pendekatan .NET memberikan lapisan abstraction yang memiliki banyak keuntungan.

Compiler dapat menghasilkan IL yang relatif independen terhadap CPU:

C# Compiler
     ↓
    IL
     ↓
Assembly

Kemudian runtime pada environment tertentu menangani execution:

Assembly
     ↓
Runtime
     ↓
JIT
     ↓
Machine Code
     ↓
CPU

Dengan model tersebut, compiler C# tidak harus menghasilkan machine code terpisah untuk setiap kombinasi environment.

Sebagai contoh, satu aplikasi dapat ditujukan untuk environment seperti:

Windows + x64
Linux   + x64
Linux   + ARM64
macOS   + ARM64

Runtime yang sesuai dengan environment tersebut dapat menangani bagian execution yang spesifik terhadap operating system dan CPU.

Runtime Tidak Sama dengan Operating System

.NET Runtime juga bukan operating system. Operating system seperti Windows atau Linux bertanggung jawab terhadap hal-hal seperti:

Process
Virtual Memory
File System
Network
Device
CPU Scheduling
Security

.NET Runtime berjalan di atas operating system dan menyediakan abstraction khusus untuk aplikasi .NET.

Gambaran sederhananya:

Application
     ↓
.NET Libraries
     ↓
.NET Runtime
     ↓
Operating System
     ↓
Hardware

Dalam praktiknya hubungan antara komponen-komponen tersebut lebih kompleks, tetapi model tersebut cukup untuk memahami posisi runtime.

Runtime dan .NET Libraries

Ada satu hal penting lainnya: .NET Runtime dan .NET Libraries bukan hal yang sama. Misalnya kode berikut:

Console.WriteLine("Hello");

Console.WriteLine() berasal dari library .NET, bukan merupakan instruksi yang secara langsung menjadi bagian dari CLR.

Secara konseptual terdapat perbedaan:

.NET Runtime
    ↓
Menjalankan managed code

.NET Libraries
    ↓
Menyediakan API yang digunakan aplikasi

Contoh library menyediakan berbagai API untuk:

Collections
File I/O
Networking
JSON
LINQ
HTTP
Reflection
Threading
Database access
dan banyak lagi

Runtime menyediakan execution environment, sedangkan library menyediakan berbagai functionality yang dapat digunakan oleh aplikasi. Keduanya bekerja bersama.

Bagian 10: CLR

Apa Itu CLR?

Pada bagian sebelumnya, .NET Runtime diperkenalkan sebagai environment yang menyediakan berbagai layanan agar sebuah assembly dapat benar-benar dijalankan. Di dalam pembahasan tersebut muncul istilah CLR, singkatan dari Common Language Runtime.

CLR merupakan execution environment yang menjadi bagian penting dari ekosistem .NET. CLR bertanggung jawab menyediakan berbagai layanan yang dibutuhkan oleh managed code selama program berjalan.

Secara sederhana:

Assembly
   ↓
CLR
   ↓
Runtime Services
   ↓
Execution

Assembly seperti MyApp.dll berisi IL dan metadata. Assembly tersebut belum berupa instruksi native yang langsung dapat dijalankan CPU. CLR menyediakan environment yang memungkinkan isi assembly tersebut dimuat, dipahami, dan dijalankan.

Namun, CLR bukan berarti sebuah program tunggal yang melakukan seluruh pekerjaan tersebut sendirian. Di dalam runtime terdapat berbagai komponen yang bekerja bersama untuk menyediakan layanan execution.

Gambaran yang lebih lengkap:

                    .NET Runtime
                         │
                        CLR
                         │
       ┌─────────────────┼──────────────────┐
       ↓                 ↓                  ↓
 Assembly Loading       JIT                GC
       ↓                 ↓                  ↓
 Type System       Native Code       Memory Management
       │
       ├── Exception Handling
       ├── Threading
       ├── Interoperability
       └── Runtime Services

Karena itu, CLR lebih tepat dipahami sebagai lingkungan execution dan kumpulan mekanisme inti yang memungkinkan managed code berjalan, bukan sekadar sebuah compiler atau satu proses sederhana.

Mengapa Disebut "Common Language Runtime"?

Nama Common Language Runtime terdiri dari tiga konsep penting.

Common

"Common" menunjukkan bahwa runtime dirancang untuk digunakan oleh berbagai bahasa pemrograman yang mengikuti ekosistem .NET.

Contohnya:

C#
VB.NET
F#

Ketiga bahasa tersebut memiliki syntax dan karakteristik bahasa yang berbeda, tetapi dapat dikompilasi menuju IL dan metadata yang dipahami oleh runtime .NET.

Secara sederhana:

C# ────────┐
           │
VB.NET ────┼──→ IL + Metadata ──→ CLR
           │
F# ────────┘

Inilah salah satu konsep penting dalam desain .NET.

CLR tidak perlu memahami syntax C# secara langsung ketika program sudah berada pada tahap execution. Syntax seperti:

if
for
class
interface
async
await

merupakan bagian dari bahasa dan compiler masing-masing.

Setelah compilation selesai, runtime bekerja terhadap hasil compilation seperti IL, metadata, type information, dan runtime structures.

Language

"Language" merujuk pada berbagai bahasa pemrograman yang dapat berjalan di atas .NET. Misalnya, C# bukan satu-satunya bahasa yang dapat menghasilkan assembly .NET. Selama sebuah bahasa memiliki compiler yang dapat menghasilkan output yang sesuai dengan aturan .NET, bahasa tersebut dapat memanfaatkan runtime yang sama. Hal ini memungkinkan adanya konsep language interoperability.

Sebagai contoh konseptual:

C# Code
   ↓
C# Compiler
   ↓
   IL
   ↓
   CLR

dan:

F# Code
   ↓
F# Compiler
   ↓
   IL
   ↓
   CLR

Runtime yang digunakan pada tahap execution tetap dapat sama.

Runtime

"Runtime" berarti environment yang bekerja ketika program sedang dijalankan. Ini berbeda dengan compile time.

Pada compile time:

Source Code
    ↓
 Compiler
    ↓
Assembly

Pada runtime:

Assembly
    ↓
Runtime
    ↓
Execution

Jadi, CLR berada pada tahap runtime, bukan tahap compilation.

CLR Bukan Compiler

Sampai titik ini terdapat tiga istilah yang sering muncul secara berdekatan:

Compiler
CLR
JIT

Ketiganya memang berhubungan dengan execution program .NET, tetapi memiliki tanggung jawab yang berbeda.

Secara sederhana:

Jika digambarkan sebagai alur:

Source Code
     │
     ↓
  Compiler
     │
     ↓
IL + Metadata
     │
     ↓
  CLR
     │
     ↓
   JIT
     │
     ↓
Native Machine Code
     │
     ↓
    CPU

Pembagian tanggung jawab tersebut sangat penting. Compiler tidak bertugas menjalankan program. CLR bukan compiler source code. JIT bukan compiler C#. Ketiganya berada pada tahap yang berbeda.

Apa yang Dilakukan Compiler?

Compiler bekerja ketika source code sedang dikompilasi.

Misalnya terdapat kode:

int Add(int a, int b)
{
    return a + b;
}

Compiler C# membaca syntax tersebut dan melakukan berbagai pekerjaan seperti:

Source Code
    ↓
Lexing / Parsing
    ↓
Semantic Analysis
    ↓
Type Checking
    ↓
IL Generation
    ↓
Metadata Generation
    ↓
Assembly

Hasil akhirnya adalah assembly yang berisi IL dan metadata.

Secara sederhana:

Add()
   ↓
C# Compiler
   ↓
IL

Compiler tidak perlu mengetahui CPU tempat aplikasi nantinya dijalankan untuk menghasilkan IL dalam model compilation normal .NET.

Apa yang Dilakukan CLR?

Setelah assembly tersedia, CLR menyediakan environment agar assembly tersebut dapat dijalankan.

Tugas CLR mencakup berbagai hal, seperti:

Assembly Loading
Type System
JIT Compilation
Garbage Collection
Exception Handling
Threading
Interop
Runtime Services

Dengan kata lain, CLR menyediakan banyak fasilitas yang dibutuhkan managed application selama execution.

Misalnya sebuah aplikasi membuat object:

var customer = new Customer();

Ada banyak hal yang harus terjadi di balik satu baris sederhana tersebut.

Runtime perlu mengetahui type Customer, mengalokasikan memory yang diperlukan, membuat object, mengatur metadata yang terkait dengan type tersebut, dan memastikan object dapat digunakan oleh managed code.

Programmer cukup melihat:

var customer = new Customer();

Tetapi execution environment melakukan lebih banyak pekerjaan di belakang layar.

Apa yang Dilakukan JIT?

JIT memiliki tugas yang lebih spesifik. IL bukan native machine code. CPU tidak secara langsung memahami IL. JIT mengambil IL dan menghasilkan native code yang dapat dijalankan oleh CPU.

Secara sederhana:

IL
 ↓
JIT Compiler
 ↓
Native Machine Code
 ↓
CPU

Misalnya CPU yang digunakan adalah x64. JIT dapat menghasilkan instruksi machine code yang sesuai dengan arsitektur tersebut.

Jika environment menggunakan ARM64, JIT dapat menghasilkan machine code yang sesuai dengan ARM64.

Dengan demikian, terdapat pemisahan tanggung jawab:

Compiler
    ↓
Menghasilkan IL yang relatif portable

JIT
    ↓
Menghasilkan native code sesuai environment

CPU
    ↓
Menjalankan native code

Detail mengenai proses tersebut akan dibahas pada bagian khusus tentang JIT.

CLR Tidak Berarti "IL Langsung Dijalankan"

Salah satu miskonsepsi yang sering muncul adalah:

Kalimat tersebut terlalu sederhana dan dapat menyebabkan kesalahpahaman.

CLR menyediakan environment execution, tetapi CPU tetap membutuhkan instruksi yang sesuai dengan arsitekturnya.

Dalam execution model yang melibatkan JIT, salah satu jalur utamanya adalah:

Assembly
   ↓
CLR
   ↓
IL
   ↓
JIT
   ↓
Native Code
   ↓
CPU

Jadi, CLR tidak membuat CPU tiba-tiba memahami IL.

CLR mengatur berbagai mekanisme yang memungkinkan IL pada akhirnya diterjemahkan dan dieksekusi.

CLR dan Managed Code

CLR juga berkaitan erat dengan istilah managed code. Managed code adalah kode yang execution-nya berada di bawah pengelolaan .NET runtime.

Contohnya:

class Customer
{
    public string Name { get; set; }
}

Ketika object dibuat:

var customer = new Customer();

object tersebut berada dalam memory yang dikelola oleh runtime.

Runtime dapat menyediakan layanan seperti:

Memory Management
Garbage Collection
Type Safety
Exception Handling
Threading

Karena itulah istilah "managed" digunakan.

Sebaliknya, native code yang tidak berada di bawah pengelolaan runtime .NET disebut unmanaged code.

Namun, managed code tetap dapat berinteraksi dengan unmanaged code melalui mekanisme interoperability.

Contohnya:

Managed Code
     ↓
.NET Runtime
     ↓
Interop
     ↓
Native Code

Hal ini memungkinkan aplikasi .NET berkomunikasi dengan native library atau API operating system tertentu.

CLR dan Type System

CLR juga memiliki hubungan erat dengan type system .NET.

Misalnya:

int age = 26;
string name = "Heykal";

Type seperti int dan string memiliki representasi dan aturan yang dipahami oleh environment .NET.

Hal ini menjadi penting karena bahasa-bahasa .NET yang berbeda harus memiliki pemahaman yang konsisten terhadap type.

Misalnya:

C#
 │
 ├── int
 ├── string
 └── class

dan:

F#
 │
 ├── int
 ├── string
 └── type

Compiler dari masing-masing bahasa dapat menghasilkan IL dan metadata yang mengikuti aturan type system .NET. CLR kemudian dapat menggunakan informasi tersebut ketika program dijalankan.

CLR dan Garbage Collector

CLR juga berhubungan dengan Garbage Collector (GC).

Ketika program membuat object:

var customer = new Customer();

memory diperlukan untuk menyimpan object tersebut.

Runtime menyediakan mekanisme memory management dan GC untuk mengelola object-object managed tersebut.

Secara konseptual:

Application
    ↓
Create Object
    ↓
Managed Memory
    ↓
Object Tidak Lagi Digunakan
    ↓
Garbage Collector
    ↓
Memory Dapat Digunakan Kembali

GC bukan fitur yang berada di luar runtime. Garbage Collection merupakan salah satu layanan inti yang mendukung managed execution.

CLR dan Exception

Ketika terjadi exception:

throw new InvalidOperationException();

runtime perlu menangani exception tersebut.

Misalnya terdapat:

try
{
    Process();
}
catch (Exception ex)
{
    Log(ex);
}

Runtime harus mencari handler yang sesuai dengan exception yang terjadi dan mengatur proses unwinding terhadap call stack.

Secara konseptual:

Method A
   ↓
Method B
   ↓
Method C
   ↓
Exception
   ↓
Stack Unwinding
   ↓
Catch Handler

Proses tersebut merupakan bagian dari runtime execution.

CLR Bukan Satu File DLL Saja

Istilah CLR terkadang dibayangkan sebagai satu file atau satu executable tertentu. Dalam kenyataannya, runtime .NET terdiri dari berbagai komponen yang bekerja bersama. Pada .NET modern, salah satu implementasi runtime utamanya adalah CoreCLR.

CoreCLR menyediakan berbagai komponen inti seperti:

CoreCLR
│
├── Execution Engine
├── Garbage Collector
├── JIT Compiler
├── Exception Handling
├── Threading
├── Type System
└── Runtime Infrastructure

Karena itu, ketika membahas CLR, penting untuk membedakan antara konsep CLR dan implementasi runtime tertentu.

Secara historis, istilah CLR sangat erat dengan .NET Framework. Pada .NET modern, runtime yang digunakan adalah CoreCLR sebagai salah satu implementasi utama dari execution environment .NET.

CLR, CoreCLR, dan .NET Runtime

Ketiga istilah berikut sering digunakan dalam pembahasan .NET:

CLR
CoreCLR
.NET Runtime

Ketiganya berhubungan, tetapi tidak selalu memiliki arti yang persis sama.

Secara sederhana:

.NET Runtime

Istilah umum untuk environment yang memungkinkan aplikasi .NET berjalan.

CLR

Istilah konseptual dan historis untuk Common Language Runtime, yaitu runtime environment yang menyediakan layanan execution untuk managed code.

CoreCLR

Implementasi runtime modern yang menjadi bagian inti dari .NET dan menyediakan execution engine, GC, JIT, serta berbagai runtime services.

Gambaran sederhananya:

.NET
 │
 ├── Runtime
 │    │
 │    └── CoreCLR
 │          ├── Execution Engine
 │          ├── JIT
 │          ├── GC
 │          └── Runtime Services
 │
 └── Libraries
      ├── System.*
      ├── Collections
      ├── Networking
      └── ...

Diagram tersebut merupakan penyederhanaan konseptual. Struktur internal .NET sebenarnya lebih kompleks, tetapi cukup untuk memahami hubungan antaristilah.

Mengapa CLR Penting?

Tanpa runtime, assembly yang berisi IL dan metadata belum memiliki environment untuk melakukan managed execution. CLR menjadi lapisan yang menghubungkan assembly dengan execution environment.

Assembly
   │
   │ IL + Metadata
   ↓
 CLR / Runtime
   │
   ├── Load Assembly
   ├── Understand Types
   ├── Manage Memory
   ├── Handle Exceptions
   ├── Manage Execution
   └── Invoke JIT
   │
   ↓
Native Code
   ↓
CPU

Dari sudut pandang ini, CLR dapat dipandang sebagai jembatan antara dunia assembly .NET dan dunia execution. Assembly menjelaskan apa yang harus dijalankan. Runtime menyediakan environment untuk menjalankannya. JIT membantu menghasilkan native code. CPU akhirnya menjalankan instruksi tersebut.

Bagian 11: JIT Compiler

IL Masih Belum Bisa Dijalankan CPU

Jika seluruh perjalanan program .NET dari bagian-bagian sebelumnya dirangkai kembali, alurnya menjadi:

C#
 ↓
Compiler
 ↓
IL + Metadata
 ↓
Assembly
 ↓
.NET Runtime / CLR

Pada titik ini, program memang sudah berada di dalam runtime, tetapi masih terdapat satu masalah penting: CPU belum menerima native machine instructions.

Assembly seperti:

MyApp.dll

masih berisi IL (Intermediate Language), bukan instruksi machine code yang secara langsung dipahami oleh CPU.

CPU memiliki instruction set sendiri. Sebagai contoh, CPU x64 memiliki instruksi machine code untuk arsitektur x86-64, sedangkan ARM64 memiliki instruction set yang berbeda. IL dirancang sebagai instruction set untuk environment .NET, bukan sebagai instruction set untuk CPU tertentu.

Karena itu, masih diperlukan sebuah proses untuk mengubah:

IL
 ↓
Native Machine Code

Komponen yang bertanggung jawab atas proses tersebut adalah JIT Compiler, atau Just-In-Time Compiler.

Secara sederhana:

IL
 ↓
JIT Compiler
 ↓
Native Machine Code
 ↓
CPU

Inilah bagian yang menjawab pertanyaan yang sebelumnya masih menggantung:

Jawabannya: IL perlu dikompilasi menjadi native code, dan salah satu mekanisme utama untuk melakukan hal tersebut adalah JIT.

Apa Itu JIT Compiler?

JIT adalah singkatan dari Just-In-Time Compiler. JIT merupakan compiler yang bekerja pada saat runtime untuk menghasilkan native machine code dari IL. Perbedaannya dengan compiler C# dapat dilihat dari input dan output-nya.

C# Compiler:

C# Source Code
      ↓
C# Compiler
      ↓
IL + Metadata
      ↓
Assembly

Sedangkan JIT:

IL
 ↓
JIT Compiler
 ↓
Native Machine Code

Dengan demikian, terdapat dua tahap compilation yang penting dalam model execution .NET:

         Compile Time
C# ─────────────────────→ IL
                           │
                           │
                           ↓
                       Runtime
                           │
                           ↓
IL ─────────────────────→ Native Code

Tahap pertama dilakukan oleh compiler bahasa seperti C# compiler. Tahap kedua dilakukan oleh JIT pada runtime. Karena itu, istilah "compiled language" dan "JIT" tidak saling bertentangan. Aplikasi .NET dapat mengalami compilation pada lebih dari satu tahap.

Mengapa Disebut "Just-In-Time"?

Nama Just-In-Time menggambarkan kapan compilation menuju native code dilakukan. Compilation tersebut tidak harus dilakukan terhadap seluruh aplikasi ketika aplikasi pertama kali dibangun. Sebaliknya, runtime dapat melakukan compilation ketika method diperlukan untuk execution.

Model sederhananya:

Application Starts
       ↓
Runtime Loads Assembly
       ↓
Method Dipanggil
       ↓
JIT
       ↓
Native Code
       ↓
CPU

Misalnya terdapat method:

int Add(int a, int b)
{
    return a + b;
}

Ketika program pertama kali membutuhkan method tersebut, runtime dapat melakukan proses yang secara konseptual seperti:

Add()
 ↓
IL
 ↓
JIT
 ↓
Native Code
 ↓
CPU

Setelah native code tersedia, execution dapat menggunakan hasil compilation tersebut. Hal ini membuat JIT berbeda dari pendekatan yang melakukan seluruh native compilation sebelum program dijalankan.

JIT Tidak Mengompilasi Seluruh DLL Sekaligus

Salah satu kesalahpahaman yang sering muncul adalah bahwa ketika aplikasi dijalankan:

MyApp.dll
   ↓
JIT
   ↓
Seluruh DLL menjadi native code

Model tersebut terlalu sederhana dan tidak menggambarkan cara kerja JIT modern.

Pada dasarnya, JIT bekerja pada level method.

Misalnya sebuah assembly memiliki:

void MethodA() { }

void MethodB() { }

void MethodC() { }

void MethodD() { }

Tidak berarti seluruh method tersebut harus langsung dikompilasi menjadi native code ketika aplikasi mulai berjalan.

Secara konseptual:

MyApp.dll
│
├── MethodA
├── MethodB
├── MethodC
└── MethodD

Ketika hanya MethodA() yang diperlukan:

MethodA
   ↓
JIT
   ↓
Native MethodA

Method lain mungkin belum perlu dikompilasi pada saat tersebut. Hal ini merupakan salah satu alasan istilah Just-In-Time digunakan. Runtime dapat menunda pekerjaan compilation sampai memang diperlukan.

Contoh Sederhana

Misalnya terdapat program:

class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }

    public int Multiply(int a, int b)
    {
        return a * b;
    }
}