{"id":"bf172aca-09ee-471b-b5e0-bfd4772f736c","arxiv_id":"2504.16251","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"With four optimizations (pre-allocation, batched page mapping, contiguous demand allocation, and lazy free), EDMM in Gramine loses most of its runtime overhead and keeps most of its startup-time savings.","lead":"This paper measures why dynamically growing an Intel SGX enclave's memory (SGX2 EDMM) can slow programs by up to 58 percent, and it shows that batching, prefetching, and lazy freeing of pages make dynamic memory management about as fast as static allocation while retaining faster startup. The work gives SGX2 users and library OS developers concrete tuning strategies and exposes a missing kernel interface.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"EDMM overhead-elimination claim is tuned in-sample: optimal prealloc, demand window, and lazy threshold are selected on the same three benchmarks, with no held-out validation or memory-pressure test; external validity is the load-bearing weakness.","rationale":"The paper is a competent empirical systems study. The mechanism (extra enclave crossings on mapping changes) is supported by the event counts in Figs. 5(d)-10(d), and the measured comparisons among configurations are internally consistent. I do not see an internal inconsistency in the benchmark results, and the performance story on the three tested workloads is believable. The load-bearing weakness is external validity: the headline configuration is not derived from a parameter-free or predictive rule; it is chosen after observing the same benchmarks. The paper's own data show pre-allocation sensitivity, and §4.1 explicitly defers memory-pressure evaluation. Because the central claim is stated broadly (\"effectively eliminate the overheads ... retaining space efficiency\"), this is a genuine gap. It is addressable by held-out evaluation and memory-footprint measurements, so it warrants a conditional acceptance rather than rejection. I also note that the +batch and +demand<N> optimizations depend on a non-upstream madvise driver patch, which reinforces the need for artifact availability, but the central scientific concern remains parameter portability. The reader's weakest_assumption points to the same issue, and I would keep the CONDITIONAL verdict.","tokens_in":18283,"tokens_out":9775,"duration_ms":99817,"concrete_test":"Take two held-out workloads that were not used in Sections 4.1-4.4 (e.g., an alloc/free-heavy server and a sparse-access workload). Run each under static and under the paper's recommended configurations, +pre(64M)+batch+lazy(15%) and +pre(64M)+demand(8)+lazy(15%), on the same machine, 10 runs each. Measure end-to-end time and peak EPC consumption. If the median time is more than 10% worse than static, or peak EPC exceeds the static baseline, the overhead-elimination and space-efficiency claims do not generalize beyond the tuned workloads; if both held-out workloads stay within 10% and below static footprint, the in-sample concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The weakest point is external validity of the parameter settings behind the headline results. The paper shows that the best pre-allocation size is workload-dependent (Fig. 6: RBench approaches static only at 512M, GCBench at 128M, Redis at 256M), then selects 64M for all later experiments \"based on diminishing returns\" (§4.2) and fixes demand windows (8/64 pages) and lazy thresholds (5%/15%) after inspecting the same three workloads (§4.3, §4.4). No model or rule is provided for choosing these values on a new workload, and the paper explicitly leaves memory-pressure experiments to future work (§4.1). Since +demand<N> maps ahead and +lf caches freed pages, the space-efficiency claim is precisely what is untested under pressure. Unless the optimized configurations are insensitive to these parameters across workloads, or a principled way to set them exists, the central claim that EDMM overheads are \"effectively eliminated\" rests on in-sample tuning.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper studies Enclave Dynamic Memory Management (EDMM) in SGX2 using Gramine as a representative library OS. It first quantifies the performance of two straightforward EDMM adoption strategies (immediate mapping and demand allocation), showing enclave loading time reductions of 28--93% but runtime slowdowns of up to 58% on GCBench. It then proposes and evaluates four optimizations: pre-allocation (+pre), batched allocation via a custom madvise ioctl (+batch), contiguous demand allocation (+demand<N>), and lazy free (+lf). The optimized configurations are reported to bring EDMM performance to parity with or above static allocation on GCBench, RBench, and Redis, while retaining much of the startup benefit. The paper concludes that the overheads of EDMM can be effectively eliminated while preserving its flexibility and space-efficiency advantages.","tokens_in":18545,"tokens_out":5350,"duration_ms":49515,"significance":"If the results hold beyond the tested configurations, the paper makes a useful contribution: it provides the first systematic implementation and evaluation of EDMM in a mainstream library OS, quantifies the hardware context-switch costs that make dynamic mapping expensive, and evaluates design ideas that were previously proposed but not implemented, such as batched EAUG and contiguous demand allocation. The strengths include the use of standard application benchmarks, 10 repetitions with 95% confidence intervals, the decomposition of overheads into page faults, AEXs, EEXITs, and EENTERs, and the candid statement of limitations such as the absence of memory-pressure experiments. The main weakness is that the headline configurations are selected from the same benchmark results used to demonstrate the improvement, and no held-out validation or memory-pressure evaluation is provided, so the external validity of the central 'overheads eliminated' claim is not yet established.","major_comments":[{"comment":"The headline optimized configurations are chosen from the same benchmark results that are used to demonstrate the improvement. Section 4.2 selects 64M pre-allocation 'based on diminishing returns' after inspecting Fig. 6; §4.3 fixes the demand window to 8 or 64 pages after testing those values on the same three workloads; §4.4 fixes the lazy-free thresholds to 5% and 15% in the same way. No held-out workload or independent validation is reported. Because these parameters directly control the space/time trade-off, the central claim that EDMM overheads are 'effectively eliminated' is not yet supported for workloads beyond the three tested. Please provide a sensitivity analysis or a principled, workload-independent rule for setting the parameters, or temper the generality of the claim.","section":"§4.2–§4.4, Figs. 7–10"},{"comment":"The choice of 64M as the pre-allocation size is not supported by the data presented. Section 4.1 reports that RBench approaches static performance only at 512M, GCBench at 128M, and Redis at 256M, yet §4.2 selects 64M 'based on the diminishing returns of increasing this size.' Neither the 64M data points nor an analysis of diminishing returns is shown in Fig. 6. This parameter is part of every optimized configuration in the paper, so the selection needs to be justified or revised.","section":"§4.1–§4.2, Fig. 6"},{"comment":"The space-efficiency benefit of EDMM is not evaluated under memory pressure. +pre retains mapped pages, +demand<N> maps ahead, and +lf deliberately keeps freed pages cached; all three trade memory footprint for execution time. The paper explicitly leaves memory-pressure experiments to future work (§4.1), yet the conclusion claims that the optimizations retain EDMM's 'space efficiency gains.' Please add a measurement of peak or steady-state enclave memory footprint for each configuration, ideally under EPC or system memory pressure, or narrow the claim to the no-memory-pressure regime.","section":"§4.1, §4.3, §4.4"}],"minor_comments":[{"comment":"The caption lists +pre(64M) as a plotted configuration, but the panels only show 128M, 256M, and 512M; please clarify whether the 64M data are missing or the caption is stale.","section":"Fig. 6"},{"comment":"The title uses 'Adaptive,' but the proposed mechanisms are static configuration options selected offline rather than runtime adaptation; consider rewording the title or adding a discussion of how the parameters would be chosen adaptively in practice.","section":"Title and §4"},{"comment":"The text describes a '144-core 2.40 GHz Intel(R) Xeon(R) Platinum 8360Y'; public specifications for that model list 36 cores and 72 threads, so the core count appears to be a typo (possibly a four-socket system).","section":"§3.2"},{"comment":"The sentence 'all other binaries are in writable inside the enclave' should read 'are mapped writable inside the enclave.'","section":"§3.3"},{"comment":"No artifact or availability statement is provided for the Gramine extensions and the patched SGX driver; making these available would materially aid reproducibility.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The in-sample configuration selection is the main risk to the paper's central claim. If the authors add even one independent workload plus a parameter-sensitivity analysis, or clearly reframe the conclusions as applying to the tested configurations, the paper would likely be acceptable. The internal measurements appear consistent and the engineering contribution is solid."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Hi [Colleague],\n\nQuick take: this is a useful and unusually candid systems paper. The measurements are internally consistent, the optimizations do recover most of the EDMM runtime overhead on the three workloads tested, and the authors openly flag their main limitations. The one thing that should give you pause is that the headline configurations—64M pre-allocation, 8/64-page demand windows, 5%/15% lazy-free thresholds—were selected by inspecting results on the same benchmarks they are then used to demonstrate. So the strong claim 'effectively eliminate overheads' is 'effectively eliminate overheads on the workloads used to tune the parameters.'\n\nWhat is actually new: the paper is, to its knowledge, the first to implement and evaluate Xing et al.'s demand-allocation design in a real library OS, and lazy free is a genuinely new trick in this setting. The analysis of why EDMM is expensive is concrete and useful: three context switches to add a mapping, nine to remove one, and a measured ~30μs per page mapping versus ~8μs for a normal process. The system-flow figures are clear. The evaluation is standard practice: 10 runs, 95% confidence intervals, three real workloads. Credit is also due for the honesty: the paper explicitly says memory-pressure experiments are future work and notes that lazy free is not strictly POSIX-compliant.\n\nSoft spots, in proportion:\n\nThe in-sample tuning is the load-bearing weakness. Section 4.2 picks 64M as 'the smallest pre-allocation size... based on diminishing returns' after seeing the curves; Section 4.3 tries 1/8/64-page windows and takes the larger ones; Section 4.4 tries 5%/15% thresholds. No held-out workload, no sensitivity analysis, no model for how to set these on a new application. This limits external validity, but it doesn't undermine the internal measurements.\n\nThe missing memory-pressure test is a real gap, not just a formality. The claimed space efficiency of demand allocation and lazy free is precisely what would be tested under pressure; without it, we only know these schemes are fast when memory is plentiful.\n\nReproducibility: the custom madvise driver patch and code are not released, so independent verification is not currently possible. Addressable, but worth flagging.\n\nWho this is for: anyone working on SGX2/EDMM, Gramine, or library OSes for enclaves. It will probably also be cited as the reference for 'EDMM is slow unless you batch and pre-allocate.' It deserves a serious referee. My recommendation: send to peer review, and in revision require sensitivity analysis or an honest narrowing of the claim, plus a memory-pressure experiment if feasible.\n\nBest,\n[You]","headline":"Solid, honest SGX2/EDMM evaluation: the overhead analysis and optimizations hold up on the tested workloads, but the headline 'effectively eliminated' rests on parameters picked using those same benchmarks.","tokens_in":19023,"tokens_out":3763,"would_cite":true,"duration_ms":34527,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"SGX2 can cut enclave launch time by 28–93%, but naive dynamic memory use slows execution by up to 58%; four optimizations eliminate the slowdown.","keywords":["EDMM","Intel SGX","SGX2","enclave memory management","Gramine","library OS","trusted execution environment","performance optimization"],"falsifier":"Run an SGX2 workload with an allocation pattern unlike the three tested ones—many small temporary mappings or heavy munmap churn, or memory pressure that forces EPC reclamation—using the paper's default settings (64 MB pre-allocation, demand windows of 8 or 64 pages, lazy threshold 5 or 15%); if end-to-end time regresses relative to static allocation by the 28–58% seen for naive EDMM, the claim of eliminated overheads fails for that setting.","tokens_in":18127,"feed_emoji":"🔐","tokens_out":10940,"duration_ms":94523,"temperature":0.7,"pith_summary":"Intel's SGX2 hardware lets an enclave grow and shrink its memory while running, instead of fixing every page before launch. The paper argues this is worth having because it cuts enclave loading time by 28–93%, but shows that the obvious ways to use it—mapping pages when the application asks, or on first access—can slow execution by up to 58%, because the enclave and the untrusted OS must handshake over every mapping change. The central result is that four optimizations (pre-allocating a modest initial heap, batching page additions across a contiguous range, faulting in several neighboring pages at once, and lazily caching freed pages) remove the runtime penalty, making EDMM comparable to or better than SGX1 static allocation on the tested workloads. If this holds, dynamic enclave memory becomes practical for library OSes and language runtimes without forcing a choice between slow startup and a fixed memory footprint.","feed_headline":"Naive SGX2 memory management slows apps by 58%; fixes erase the loss","feed_subtitle":"Batching, pre-allocation, and lazy frees make dynamic enclave memory run as fast as static allocation.","key_machinery":"The load-bearing mechanism is the hardware-enforced mutual-distrust protocol for changing an enclave's virtual memory: the untrusted OS proposes a mapping change through system-tier instructions (EAUG, EMODT, EMODPR) and the enclave must approve it with EACCEPT before the change is usable. This handshake forces at least three enclave crossings to add a mapping, five under demand paging, and nine to remove one, and a demand fault costs roughly 30 microseconds versus 8 microseconds in a normal process. The paper's four optimizations are all aimed at this mechanism: +pre allocates an initial heap at launch when mapping is cheap; +batch makes the kernel issue many EAUGs for one round trip through a new madvise path; +demand<N> maps up to N neighboring pages on the first fault; and +lf caches freed pages instead of unmapping them.","core_discovery":"The paper's central claim is that the runtime overhead of EDMM is not an inherent cost of dynamic enclave memory, but an artifact of doing mapping changes one page at a time. Naive EDMM, whether it maps on mmap or on first access, slows GCBench by 41% and 58% and RBench by 5% and 10% relative to SGX1 static allocation, even though it cuts enclave loading time by 28–93%. The paper shows that combining 64 MB pre-allocation with batched page additions and 8- or 64-page contiguous demand allocation, plus lazy frees at a 5–15% threshold, turns the GCBench overhead into a 1.8–2.8% speedup over static and lets RBench beat static at the 15% lazy threshold, while keeping much of the startup gain. The stated conclusion is that EDMM's dynamic memory benefits can be retained without a performance penalty, provided the mapping protocol is amortized across regions and frees are deferred.","pith_inferences":["Beyond the paper: the same OS-proposes/enclave-accepts handshake appears in VM-style TEEs like Intel TDX and AMD SEV-SNP, so region-batched mapping and lazy free should transfer to guest-OS memory managers there, though the paper does not evaluate them.","Beyond the paper: because the optimization parameters are tuned on the same benchmarks that are used to report the gains, a held-out workload with a different allocation pattern could require retuning 64 MB, the 8/64-page windows, and the 5/15% thresholds; the headline results are an upper bound until that is tested.","Beyond the paper: lazy free deliberately breaks strict POSIX semantics by not faulting on an access to a freed page; a compatible variant could keep a guard mapping and lazily re-fault only on real access, a testable extension the paper does not explore.","Beyond the paper: the AEX-Notify hardware feature cited in the paper could remove some of the remaining context switches in the demand-allocation flow, potentially making even single-page demand faults cheap enough that region batching becomes unnecessary."],"forward_implications":["Enclaves can be launched small and expanded on demand, so applications with input-dependent memory use no longer over-provision heap pages up front; the optimized configurations keep most of the 28–93% loading-time improvement.","Runtimes can enable EDMM without sacrificing runtime speed: on GCBench the overhead drops from 28% (with batch) or 36% (with demand-8) to small gains over static, and RBench beats static at a 15% lazy threshold.","Demand paging in an enclave should be region-based rather than page-based: mapping 8 or 64 neighboring pages per fault is what makes demand allocation competitive with eager mapping.","Unmapping is the most expensive enclave operation, so caching freed pages instead of returning them to the kernel is the decisive optimization for allocator-heavy workloads like garbage-collected applications.","The batch-allocation optimization requires a new madvise interface in the Linux SGX driver that the authors plan to upstream; until it lands, applications can only get the full benefit of +batch with a patched driver."],"supporting_citations":[{"why":"Defines the SGX2 EDMM leaf instructions and the hardware protocol requiring enclave acceptance of OS-proposed mapping changes, which the paper optimizes.","marker":"[25]"},{"why":"Introduces the original Intel SGX enclave model and the SGX1 limitation of statically fixed virtual memory, the baseline compared against.","marker":"[26]"},{"why":"Graphene-SGX, the Gramine library OS on SGX that the paper extends with EDMM support and evaluates as a representative enclave runtime.","marker":"[41]"},{"why":"Xing et al.'s proposal of demand allocation and batching for SGX dynamic memory, which the paper adapts, implements, evaluates, and finds insufficient without further optimizations.","marker":"[46]"},{"why":"GCBench, the garbage-collection benchmark whose 41% and 58% EDMM slowdowns drive the main performance analysis.","marker":"[32]"},{"why":"RBench, the scientific-computing benchmark that shows EDMM's execution-time overhead and the gains from lazy frees.","marker":"[43]"},{"why":"Redis, the in-memory key-value store whose YCSB throughput is the third main benchmark used in the evaluation.","marker":"[36]"},{"why":"YCSB, the workload generator used to measure Redis throughput across static, EDMM, and optimized configurations.","marker":"[48]"}],"fun_headline_variants":["SGX2 optimizations flip 58% slowdown to 3% speedup","Batched maps and lazy frees erase SGX2 memory overhead","How to make SGX2 memory management fast: batch and defer","EDMM overhead erased by batching, preallocation, lazy frees"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the configuration parameters tested here—64 MB of pre-allocation, demand windows of 8 or 64 pages, and lazy-free thresholds of 5 or 15%—are representative or predictable enough for other SGX2 workloads, since the paper picks them by inspecting results on the same benchmarks and leaves memory-pressure experiments to future work.","fun_headline_variants_meta":{"raw":{"variants":["SGX2 optimizations flip 58% slowdown to 3% speedup","Batched maps and lazy frees erase SGX2 memory overhead","How to make SGX2 memory management fast: batch and defer","EDMM overhead erased by batching, preallocation, lazy frees"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001646,"raw_usage":{"total_tokens":6525,"prompt_tokens":916,"completion_tokens":5609,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":532,"completion_tokens_details":{"reasoning_tokens":5529}},"tokens_in":532,"tokens_out":5609,"duration_ms":37453,"temperature":1.0,"reasoning_tokens":5529,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T11:08:02.826241+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run an SGX2 workload with an allocation pattern unlike the three tested ones—many small temporary mappings or heavy munmap churn, or memory pressure that forces EPC reclamation—using the paper's default settings (64 MB pre-allocation, demand windows of 8 or 64 pages, lazy threshold 5 or 15%); if end-to-end time regresses relative to static allocation by the 28–58% seen for naive EDMM, the claim of eliminated overheads fails for that setting.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the SGX2 EDMM leaf instructions and the hardware protocol requiring enclave acceptance of OS-proposed mapping changes, which the paper optimizes."},{"cited_title":"Porter, and Mona Vij","cited_arxiv_id":null,"evidence_quote":"Graphene-SGX, the Gramine library OS on SGX that the paper extends with EDMM support and evaluates as a representative enclave runtime."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Xing et al.'s proposal of demand allocation and batching for SGX dynamic memory, which the paper adapts, implements, evaluates, and finds insufficient without further optimizations."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"GCBench, the garbage-collection benchmark whose 41% and 58% EDMM slowdowns drive the main performance analysis."},{"cited_title":"InProceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS ’18)","cited_arxiv_id":null,"evidence_quote":"RBench, the scientific-computing benchmark that shows EDMM's execution-time overhead and the gains from lazy frees."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Redis, the in-memory key-value store whose YCSB throughput is the third main benchmark used in the evaluation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"YCSB, the workload generator used to measure Redis throughput across static, EDMM, and optimized configurations."}],"review_version":1}