Implicit List / First-Fit으로 구현했을 경우 결과

테스트케이스 분석이 필요한 이유?

<aside> ❗

**malloc**을 만들어가는 과정에서, 요구 사항의 정의가 명확해야겠다는 판단

• 왜 Segregated List가 효율적일까?
• Implicit List와 Explicit List에서는 정말 효율을 내지 못하는 것일까? </aside>

공통 형태

19656100   ← suggested heap size (제안 힙 크기, 드라이버가 사실상 무시)
7200       ← ID 개수(num_ids): ptr_<id> 슬롯의 최대 개수
14400      ← 작업 개수(num_ops): 아래에 이어질 총 요청 라인 수
1          ← weight (가중치, 사실상 무시)

a X  4095  ← #X alloc 4095Bytes
f X        ← #X free → 인접 자유블록(아직 #2는 alloc)
f X        ← #X realloc → 이제 #1·#2가 서로 인접한 자유블록 → 병합되어야 함

Case 4. coalescing-bal.rep

• 형태
  • 총 연산 14,400회 = alloc(7,200회) + free(7,200회)
  • 요청 크기 : 4095Bytes, 8190Bytes
  • 패턴 : a 4095, a 4095, f, f, a 8190 를 반복
• Test Case의 목적
  • **즉시 병합(immediate coalescing)**이 제대로 되는지 확인.
    • 인접한 두 free 블록(4095, 4095)을 바로 하나로 합쳐서 다음의 8190 요청을 “추가 확장 없이” 만족
  • 경계 태그(footer) / 이웃 탐색이 정확한지, free-list 재배치가 올바른지 검증

Case 7. binary-bal.rep

• 형태
  • 총 연산 12,000회 = alloc (6,000회) + free (6,000회)
  • 요청 크기 : 64Bytes, 448Bytes, 512Bytes
  • 패턴
    • 64, 448 번갈아 쭉 할당
    • 448들부터 대량 free → 여러 개의 중간 홀(64는 아직 점유)
    • 512를 2,000회 연속 할당
    • 이후 64들도 다양하게 free
• Test Case의 목적
  • 두 작은 클래스(64, 448)와 그 합(≈512) 간의 **Free Block**의 균형 / 재사용성 테스트

    • Splinter 발생 및 재사용성 / **배치 정책(첫/넥스트/베스트)**의 적합성 판단

      Splinter : 할당을 위해 큰 가용 블록을 쪼갤 때 남는, 너무 작아서 제대로 쓰기 힘든 조각

  • 512 수요가 생겼을 때, coalesce(64+448)가 가능한 타이밍에 정확히 512의 free 블록을 생성

Case 8. binary2-bal.rep

• 형태
  • 총 연산 24,000회 = alloc (12,000회) + free (12,000회)
  • 요청 크기 : 16Bytes, 112Bytes, 128Bytes
  • 패턴
    • Case 7. binary-bal.rep과 동일