탭 문서를 줄여도 읽어 둔 설명을 계속 쌓으면 다른 곳에서 메모리가 늘 수 있다. 북극성의 자동 읽기 준비에는 네 항목이라는 개수만 두지 않고 총바이트·한 항목 크기·미사용 시간을 함께 제한했다. 기존 글에서 다룬 ref 수명에 이어, 이번에는 캐시가 얼마나 남는지를 본다.
네 탭이라는 제한만으로는 크기를 알 수 없다
기본 PagePreparation 한도는 네 항목, 총 4MiB, 한 항목 1MiB, 미사용 5분이다. 글자가 많은 문서 한 개가 작은 문서 여러 개보다 클 수 있어 개수만으로는 충분하지 않다. 실제 view를 JSON으로 직렬화한 UTF-8 바이트를 센다. 글자 수와 바이트 수를 같은 단위로 보지 않는다.
이 숫자는 캐시에 보관한 표현의 크기이지 Electron 전체 메모리나 모든 내부 객체의 사용량은 아니다. 브라우저 프로세스와 renderer, 드라이버의 다른 자료는 별도다. 통계에서 몇 바이트를 제거했다고 RAM이 똑같이 줄었다고 설명하면 계층이 섞인다. 나는 캐시의 한도와 프로세스 측정을 서로 다른 근거로 남겼다.
최근에 읽은 항목은 수명을 갱신한다
prune은 touched가 오래된 항목을 만료시키고 개수나 총량이 넘으면 오래 안 쓴 것부터 제거한다. 정상 peek과 바뀌지 않은 준비 결과의 재사용은 touched를 갱신한다. 생성 시각만으로 일정 시간이 지나면 무조건 지우는 정책과 다르다. 읽기 캐시의 목적에 맞춰 미사용 시간을 보는 것이다.
단위시험은 a와 b를 넣고 a를 다시 읽은 뒤 c를 넣어 b가 제거되는지 본다. 이어 미래 시각으로 prune해 모두 만료되는 조건을 확인한다. 시간을 기다렸다는 설명만 남기기보다 어느 항목이 왜 살아남는지 비교할 수 있다. 새 합성 모듈도 이 관계를 수동 시각과 실제 함수 기록으로 보여 준다.
큰 페이지는 계속 자동 보관하려고 반복하지 않는다
view가 한 항목 한도나 전체 한도보다 크면 보관하지 않고 기존 항목을 evict한다. 상태에는 큰 페이지이므로 요청할 때 필요한 부분을 읽는다고 안내하고 자동 재시도 유예를 둔다. 크게 읽은 결과를 매 주기 다시 만들어 캐시에 넣으려는 반복을 줄이는 선택이다.
이것이 큰 페이지를 아예 읽을 수 없다는 뜻은 아니다. 자동 준비와 명시적인 읽기 요청의 정책을 나눈다. ensure의 explicit은 자동 eligibility와 재시도 대기를 다르게 취급하지만 휴면·로딩 같은 기본 상태까지 무시하지 않는다. 크기 제한을 읽기 권한 확대나 실제 페이지 새로고침으로 우회하는 기능도 아니다.
늦은 관찰이 새 문서의 캐시가 되지 않게 한다
prepare는 시작의 URL·documentEpoch·generation을 기억하고 비동기 검증과 관찰 뒤에도 current인지 본다. 관찰한 revision과 현재 revision도 대조한다. 준비를 기다리는 동안 문서가 바뀌면 앞의 결과를 새 문서에 저장하지 않는다. pending은 같은 탭의 동시 준비를 합치는 역할도 한다.
evict나 remove에서는 읽기 드라이버의 관련 문맥 해제 콜백을 사용한다. 반면 모든 entries.delete가 동일한 해제 경로라고 확대하면 실제 코드와 다르다. 캐시 항목 제거와 비동기 세대 차단, 부속 문맥 정리는 서로 연결되지만 각각 확인해야 할 책임이다. 기존 ref 제거 글의 권한 경계와도 같은 질문은 아니다.
공유 캐시는 더 작은 동기식 실험이다
합성 모듈은 title·text만 받아 LRU와 바이트·TTL·범위 변경을 시험한다. 같은 탭에 너무 큰 새 자료가 들어오면 옛 자료도 남기지 않고 miss로 돌리는 상황을 포함했다. 실제 원본의 구조화 view나 비동기 읽기, 프레임 map 정리를 완전히 복제하지는 않았다.
이번에는 현재 함수와 한도 관련 원본 시험을 읽고 합성 코드와 추출 ZIP을 별도로 시험했다. 운영 페이지를 새로 크롤링하거나 사용자 탭을 새로고침하지 않았다. 읽기 편의 자료도 보관할 이유와 버릴 기준이 있어야 한다는 판단을, 독자가 한도를 바꿔 직접 확인할 수 있는 형태로 남겼다.