Research

Pomysły badawcze

26 min. czytania

Pomysły badawcze

Ostatnia aktualizacja: 2026-05-25

🔥 Wysokie priorytety

[#JE-1] Pierwsza rygorystyczna analiza energetyczna Node.js vs Deno vs Bun w środowiskach serverless

Status: new Priorytet: high Dodano: 2026-05-25 Bazuje na: Smirnov 2024, Pereira 2017, De Macedo 2022

Gap badawczy:

  • Smirnov et al. (2024): porównuje Node.js/Deno/Bun pod kątem czasu — bez wymiaru energetycznego
  • Laakso (2025) — szara literatura (praca licencjacka): benchmark wydajnościowy Node.js/Deno/Bun — bez energii; Bun 103k req/s vs Node.js 73k vs Deno 73k (native API) na Apple M2
  • Pereira et al. (2017, 2021): rankuje języki energetycznie, ale JavaScript traktuje monolitycznie (jeden runtime = Node.js)
  • De Macedo et al. (2022): Wasm vs JS energia, ale nie-serverless i tylko Node.js
  • Nikt nie zmierzył różnic energetycznych między runtimeami JS w serverless workloadach

Hipotezy:

  • H1: Bun zużywa mniej energii niż Node.js dla synchronicznych zadań CPU-bound (JavaScriptCore < V8 dla JS synchronous execution) — wsparte: Laakso 2025 pokazuje Bun 34% szybszy CPU-bound, sugeruje mniejsze zużycie energii
  • H2: Deno jest bardziej efektywny energetycznie niż Node.js dla asynchronicznych operacji I/O (Tokio async runtime w Rust)
  • H3: Różnice energetyczne między runtimeami są większe niż różnice czasowe (JIT warm-up energetyczny)
  • H4: Dla cold start scenariuszy Bun ma najniższy energetyczny koszt inicjalizacji — Laakso: Bun ~3× szybszy startup
  • H5: Różnice energetyczne zależą od workloadu — brak “zawsze najlepszego” runtimes dla wszystkich typów zadań — częściowo potwierdzono: Laakso: Deno > Node.js w JSON, Bun > wszyscy w HTTP; ale brak energii

Proponowane badanie:

  1. Runtimes: Node.js 24 (LTS), Deno 2.x, Bun 1.x
  2. Workloady (6 kategorii):
    • CPU-bound: sortowanie, hashing SHA256, przetwarzanie JSON (parse/stringify)
    • I/O-bound: file read/write, HTTP fetch, database queries (SQLite)
    • SSR: renderowanie template (Handlebars, EJS)
    • Cold start: czas + energia od spawnu do pierwszego response
    • Memory-intensive: large array/object operations
    • Mixed: typowy REST API handler (JSON in → compute → JSON out)
  3. Pomiar: Intel RAPL przez PowerJoular + wall clock time + RSS memory
  4. Środowisko kontrolowane: bare-metal Intel server (eliminacja hypervisor noise), Ubuntu 24.04
  5. Protokół: 30 powtórzeń, median + IQR, Mann-Whitney U (p<0.05), warmup 5 iteracji odrzucane
  6. Analiza: energia × czas × pamięć — 3D ranking jak Pereira 2017

Wkład badawczy:

  • Pierwsza praca energetycznie porównująca Node.js/Deno/Bun w serverless workloadach
  • Publiczny benchmark suite (GitHub, CI/CD ready)
  • Praktyczne rekomendacje: kiedy zmiana runtimes daje oszczędności energetyczne

Metodologia wzorowana na: Pereira 2017/2021 (RAPL + standaryzowane benchmarki) + Albonico 2025 (wielozmiennowy design eksperymentu)

[#JE-2] Model decyzyjny wyboru runtime JS dla architektur serverless i edge: optymalizacja energia–latencja–koszt

Status: new Priorytet: high Dodano: 2026-05-25 Bazuje na: Pereira 2021, Lumos 2025, [JE-1]

Gap badawczy:

  • Lumos (2025): model wydajnościowy dla Wasm — brak JS runtimeów, brak energii
  • Pereira (2021): narzędzie multi-criteria dla języków — brak kontekstu serverless/edge
  • Brak modelu decyzyjnego łączącego energię, latencję, koszt dla wyboru runtime w serverless

Hipotezy:

  • H1: Optymalna konfiguracja runtime zależy od co najmniej 3 zmiennych: typ workloadu (CPU/IO), środowisko (serverless/edge), wymagania SLO (latency target)
  • H2: Model TOPSIS z wagami energia:latencja:koszt = 0.5:0.3:0.2 jest wystarczającym przybliżeniem dla typowych zastosowań
  • H3: Istnieje “sweet spot” konfiguracji runtime+platforma dla każdej kategorii workloadu — model może to przewidzieć z ≥80% trafnością
  • H4: Modele decyzyjne uwzględniające energię wybierają inny runtime niż modele oparte wyłącznie na latencji (co najmniej 30% przypadków)

Proponowane badanie:

  1. Przestrzeń decyzyjna: {Node.js, Deno, Bun, Wasm} × {AWS Lambda, Cloudflare Workers, bare OpenWhisk} × {cold, warm} × {CPU/IO/memory-bound}
  2. Metryki: energia/request [J], latencja p50/p99 [ms], cold start time [ms], koszty chmury [$/mln req], carbon footprint [gCO₂/req]
  3. Model:
    • Zbieranie danych (#JE-1 + dodatkowe pomiary)
    • TOPSIS (Technique for Order of Preference by Similarity to Ideal Solution)
    • Analiza wrażliwości: jak zmiana wag wpływa na decyzję?
  4. Walidacja: 5 case studies z rzeczywistymi aplikacjami (Next.js SSR, REST API, edge middleware, background job, streaming)

Wkład:

  • Pierwszy praktyczny decision framework uwzględniający energię dla JS serverless
  • Open-source narzędzie (web app lub CLI) dla architektów
  • Baza danych benchmark wyników (runtime × workload × platforma)

[#JE-3] Rygorystyczna metodologia pomiaru energii JS runtimeów: standaryzacja i reprodukowalność

Status: new Priorytet: high Dodano: 2026-05-25 Bazuje na: PowerJoular 2022, Pereira 2017, Cunha 2024

Gap badawczy:

  • RAPL działa na bare-metal Intel — w chmurze jest niedostępny lub niedokładny
  • JIT compilation (V8, JavaScriptCore) powoduje non-stationarity energetyczną: pierwsze wywołania ≠ późniejsze
  • GC pauses (Garbage Collection) tworzą nieregularne skoki zużycia energii
  • Brak standaryzowanej metodologii specyficznej dla JS runtimeów i środowisk serverless

Hipotezy:

  • H1: JIT warm-up w Node.js/Deno (V8) wymaga co najmniej 10-15 iteracji “warm-up” przed stabilizacją zużycia energii
  • H2: GC-driven energy spikes w JS runtimeach mają istotny wpływ na medianę energii (>5%) — wymagają specjalnego protokołu
  • H3: PowerJoular (RAPL-based) i hardware power meter korelują z R²>0.95 dla Node.js procesów przy CPU-bound workloadach
  • H4: Szacunki energetyczne z cloud billing metrics (CPU seconds × TDP) mają błąd >20% wobec RAPL na bare-metal
  • H5: Bun (JavaScriptCore) ma krótszy JIT warm-up niż Node.js (V8) — szybciej osiąga stabilne zużycie energii

Proponowane badanie:

  1. Porównanie metod pomiarowych:
    • Intel RAPL (via perf stat --event=power/energy-pkg/)
    • PowerJoular (process-level attribution)
    • Hardware: Yokogawa WT310 power meter
    • Cloud: CPU-seconds × TDP estimate (szacowanie)
  2. Identyfikacja confounders: JIT warm-up (jak wiele iteracji?), GC pauses (jak odfiltrować?), OS scheduler variance
  3. Protokół eksperymentalny:
    • Minimalna liczba powtórzeń (power analysis: δ=10%, α=0.05, β=0.2)
    • Procedura warm-up: N iteracji odrzucanych (jak dobrać N?)
    • Test na stacjonarność zużycia energii (Ljung-Box test)
  4. Walidacja: cross-validation między metodami pomiaru
  5. Framework open-source: CLI tool automatyzujący poprawne pomiary JS runtimeów

Wkład:

  • Standaryzowana metodologia pomiaru energii JS runtimeów (wzorzec dla przyszłych badań)
  • Analiza confounders specyficznych dla JS (JIT, GC, event loop)
  • Open-source benchmarking framework z wbudowanym pomiarem energii

📌 Średnie priorytety

[#JE-4] WebAssembly jako runtime JS w edge computing: analiza energetyczna vs Node.js/Deno/Bun

Status: new Priorytet: medium Dodano: 2026-05-25 Bazuje na: De Macedo 2022, Lumos 2025, Besozzi 2025

Gap: De Macedo (2022) porównuje Wasm vs JS energetycznie, ale tylko w środowisku nie-serverless. Lumos (2025) bada Wasm w edge-cloud ale bez pomiaru energii.

Hipotezy:

  • H1: Wasm AoT ma niższy energetyczny koszt cold start niż Node.js (mniejszy image = mniej I/O przy starcie)
  • H2: Dla warm workloadów Bun (JavaScriptCore JIT) jest energetycznie porównywalny z Wasm AoT dla CPU-bound zadań
  • H3: Wasm interpretowany jest energetycznie droższy niż Node.js dla wszystkich kategorii workloadów (Lumos: 30-55× wolniejszy warm)
  • H4: Na resource-constrained edge (RPi 5, Jetson Nano) różnice energetyczne między runtimeami są proporcjonalnie większe niż na server-grade hardware

Proponowane badanie: Wasm (Wasmtime, WasmEdge) vs JS runtimes (Node.js, Deno, Bun) na edge hardware:

  • Raspberry Pi 5 (ARM, 8GB) — typowy edge node
  • Jetson Nano (ARM + GPU, embedded) — IoT edge
  • Pomiar: RAPL (Intel) lub perf energy (ARM) + PowerJoular

Wkład: Pierwsza analiza energetyczna Wasm vs JS na edge hardware, rekomendacje IoT/edge deployment

[#JE-5] Carbon footprint JavaScript ecosystem: npm, bundling, runtime — lifecycle analysis

Status: new Priorytet: medium Dodano: 2026-05-25 Bazuje na: GreenCourier 2023

Gap: GreenCourier optymalizuje scheduling serverless pod kątem carbon intensity regionów. Ale sam JavaScript ecosystem (npm install, bundle, cold start, idle) generuje carbon footprint — nikt tego nie zmierzył.

Hipotezy:

  • H1: Faza CI/CD build (npm install + bundle) stanowi >10% całkowitego carbon footprint typowej aplikacji JS serverless
  • H2: Bun + pnpm mają o >30% mniejszy carbon footprint fazy install niż npm + Node.js (szybszy install = mniej czasu CPU)
  • H3: Next.js (SSR) ma wyższy runtime carbon footprint/request niż Astro (SSG+edge) dla statycznych treści

Proponowane badanie: Lifecycle Carbon Analysis (LCA) JS aplikacji:

  • Fazy: development (npm install) + CI/CD build + cold start + warm execution + idle (keep-warm)
  • Frameworki: Next.js vs Remix vs Astro vs bare Node.js
  • Narzędzie: CodeCarbon lub własny pomiar RAPL × czas

[#JE-6] Cold start energy overhead: energetyczny koszt inicjalizacji JS runtimeów

Status: new Priorytet: medium Dodano: 2026-05-25 Bazuje na: Golec 2024, [JE-1], [JE-3]

Gap: Golec (2024) systematyzuje techniki redukcji cold start latency bez pomiaru kosztu energetycznego. Czy mniejsza latencja cold start = mniejsze zużycie energii? Niekoniecznie — keep-warm pochłania energię idle.

Hipotezy:

  • H1: Energetyczny koszt cold start (energia od wywołania do gotowości) jest proporcjonalny do czasu cold start dla danego runtimes
  • H2: Keep-warm strategy (periodyczne wywołania) jest energetycznie tańsza niż cold start tylko gdy częstotliwość wywołań >1/5min
  • H3: Bun ma najniższy energetyczny koszt cold start (najmniejszy runtime, szybsza inicjalizacja)
  • H4: WebAssembly AoT ma 2× niższy energetyczny koszt cold start niż Node.js (Lumos: 16% niższy cold start latency → zakładamy proporcjonalność)

Proponowane badanie:

  • Pomiar: energia od spawn procesu do pierwszego zhandlowanego requestu (integracja mocy × czas)
  • Runtimes: Node.js, Deno, Bun, Wasm (Wasmtime)
  • Porównanie strategii: cold vs keep-warm vs pre-warming — total energy over 24h simulation

💡 Niskie priorytety / Backlog

[#JE-7] Serverless function scheduling z runtime awareness: rozszerzenie GreenWhisk/GreenCourier

Status: new Priorytet: low Dodano: 2026-05-25 Zaktualizowano: 2026-05-28 Bazuje na: serenari-greenwhisk-emission-serverless-2024, GreenCourier 2023

GreenWhisk (2024) optymalizuje gdzie i kiedy uruchomić funkcję (carbon intensity regionów i okna czasowe), ale zakłada stałą energię per invocation dla danego typu funkcji. Fundamentalna luka: jeśli node A ma Node.js, a node B ma Bun, ta sama funkcja może mieć 20-30% niższe zużycie energii na B — GreenWhisk tego nie uwzględnia.

Rozszerzenie: Runtime-aware Carbon Scheduling — load balancer uwzględnia zarówno grid carbon intensity (jak GreenWhisk) jak i per-runtime energy efficiency (z wyników JE-1). Dla CPU-bound workloadów: preferuj Bun-node; dla I/O-bound: preferencja zależy od wyników JE-1.

Hipoteza: Runtime-aware + carbon-aware scheduling redukuje carbon footprint o >15% wobec samego GreenWhisk dla heterogenicznego klastra runtimeów JS.

[#JE-8] Benchmarking suite dla serverless JS: standaryzowany zestaw zadań FaaS

Status: new Priorytet: low Dodano: 2026-05-25

Stworzenie otwartego benchmark suite specyficznego dla serverless JS — analogia do Computer Language Benchmarks Game (CLBG), ale skoncentrowana na typowych FaaS workloadach: API gateway, auth middleware, image processing, SSR, background job. Open-source, CI/CD-ready, z pomiarem energii.

[#JE-9] Wielowarstwowa analiza energetyczna JS runtimeów: izolacja energii runtime od overhead platformy serverless

Status: new Priorytet: medium Dodano: 2026-05-28 Bazuje na: werner-experimentation-framework-energy-2025, [JE-1], [JE-3]

Gap w Werner 2025:

  • CLUE definiuje kluczową metrykę W_R (energia per request, tylko warstwa runtime + aplikacja) vs RO (overhead platformy: Kubernetes, KNative) — ale testuje wyłącznie Java/TeaStore, zero JS runtimeów
  • Główny wynik: wariant GraalVM RT (zmiana JVM) dał najlepszy wynik energetyczny ze wszystkich taktyk — bezpośrednia analogia: Node.js V8 vs Deno V8 vs Bun JavaScriptCore = zmiana runtime, identyczna taktyka
  • Wariant KNative serverless był energetycznie gorszy niż baseline microservices: platform RO dominował nad scale-to-zero gains — dla JS: czy wrapping Node.js/Bun w OpenFaaS/KNative amplifikuje lub redukuje tę dysproporcję?
  • Istniejące badania JS (Pereira 2017, De Macedo 2022) mierzą całkowitą energię systemu — nie rozróżniają W_R od RO; niemożliwa odpowiedź: “czy Bun jest efektywniejszy ze względu na runtime, czy ze względu na mniejszy overhead kontenera?”

Proponowane badanie:

  1. Adaptacja metryk CLUE do JS: pomiar W_R i RO oddzielnie dla Node.js/Deno/Bun w środowisku containerized serverless (Docker + OpenFaaS/KNative)
  2. Narzędzia: Kepler (pod-level energy attribution) + Scaphandre (host-level) + external power meter — cross-validation jak Werner
  3. Workloady (wzorowane na CLUE showcase): fixed (N requestów), pausing (sparse), stress (peak load)
  4. Warianty porównania (analogia do CLUE 5 taktyk):
    • Bare Node.js (baseline, bez kontenera)
    • Node.js w Docker
    • Node.js w OpenFaaS (serverless orchestration overhead)
    • Bun w Docker vs OpenFaaS (czy szybszy runtime redukuje RO%)
    • Deno w Docker vs OpenFaaS
  5. Kluczowe pytanie badawcze: Czy lepsza energetyczność Bun vs Node.js manifestuje się w W_R (runtime efficiency), RO (mniejszy overhead platformy dzięki szybszemu startup), czy obu?

Wkład badawczy:

  • Pierwsze zastosowanie metodologii CLUE (WR/RO/RU/RE) do porównania JS runtimeów
  • Odpowiedź na pytanie: gdzie “kryje się” różnica energetyczna między runtimeami JS — w logice biznesowej czy w overhead platformy?
  • Praktyczna implikacja: czy zmiana JS runtime zmienia optymalny wybór architektury deployment (bare vs serverless)?

Hipotezy:

  • H9a: Bun ma niższe W_R niż Node.js dla CPU/IO workloadów (potwierdza JE-1 H1) i jednocześnie niższe RO (szybszy cold start → mniejszy overhead przy sparse workloads)
  • H9b: Dysproporcja RO/W_R jest proporcjonalnie WIĘKSZA dla Bun w OpenFaaS (mały runtime → platforma stanowi większy % całości) — paradoks efektywnego runtime
  • H9c: Wyniki CLUE (KNative serverless gorszy energetycznie) replikują się dla JS: Node.js w KNative ma wyższe RO niż Node.js w plain Docker, ale Bun w KNative zbliża się energetycznie do Node.js w Docker

Zbiory danych: własne pomiary eksperymentalne; TeaStore-equivalent w JS jako SUT (Express.js lub Fastify REST API z podobną strukturą usług)

[#JE-10] Marginal energy jako metodologiczny standard porównania JS runtimeów w środowiskach wielofunkcyjnych

Status: new Priorytet: high Dodano: 2026-05-28 Bazuje na: rehman-faasmeter-energy-2024, [JE-1], [JE-3]

Gap w FaasMeter 2024:

  • FaasMeter pokazuje, że pomiar energii “w izolacji” dla funkcji FaaS daje błędne wyniki: ten sam workload zmienia zużycie energii >10× w zależności od obciążenia serwera (Fig. 3 w papierze)
  • Właściwe ground truth to marginal energy: M_f = (J(T(S)) − J(T(S−f))) / invocations — eliminuje wpływ idle power i stanów CPU frequency
  • Scaphandre (RAPL-only) ma 100–130% błąd dla funkcji I/O-bound (dd) — żadne istniejące badanie energetyczne JS runtimeów nie weryfikowało tej implikacji
  • Istniejące benchmarki JS energetyczne (Pereira 2017, De Macedo 2022, Albonico 2025) używają izolowanych pomiarów — ich wyniki mogą być nieważne w środowiskach wielofunkcyjnych
  • Kluczowe pytanie: Czy hierarchia energetyczna Node.js > Deno > Bun (mierzona w izolacji w JE-1) utrzymuje się pod realnym obciążeniem serverless?

Proponowane badanie:

  1. Replicate + challenge: Uruchom te same benchmarki JS co JE-1 (CPU-bound, I/O-bound, JSON) w dwóch trybach:
    • Isolated (jedna funkcja na raz) — baseline jak dotychczasowa literatura
    • Concurrent (30-50 współbieżnych funkcji) — realistic serverless load per Azure Function Trace
  2. Pomiar marginal energy: dwa identyczne workloady T(S) i T(S−f), różnica = marginal energy per invocation dla każdego runtime
  3. Narzędzia: zaadaptuj statystyczną disagregację FaasMeter do środowiska JS lub użyj Ilúvatar jako control plane z FaasMeter integration
  4. Pytania: (a) Czy ranking runtimeów zmienia się z isolated na concurrent? (b) Jak duży jest błąd isolated benchmarks dla JS?
  5. Statystyczna disagregacja: C (czasy wykonania) × X (per-runtime power) = W (system power) — liniowa regresja z δ=1s

Wkład badawczy:

  • Walidacja lub falsyfikacja istniejących wyników (#JE-1) w środowisku concurrent — jeśli ranking się zmienia, unieważnia poprzednią literaturę
  • Standaryzacja metodologii: marginal energy jako obowiązkowy element benchmarków energetycznych JS runtimeów
  • Identyfikacja: które typy workloadów JS (CPU/I/O/GC-heavy) najbardziej różnią się między isolated i marginal pomiarami

Hipotezy:

  • H10a: Hierarchia energetyczna JS runtimeów (zmierzona isolated) zmienia się pod obciążeniem concurrent dla I/O-bound workloadów (ponieważ RAPL nie widzi I/O energy — analogia do dd/Scaphandre błędu z FaasMeter)
  • H10b: Marginal energy pomiary pokazują mniejsze różnice między runtimeami niż isolated pomiary (idle power amortization expression)
  • H10c: Bun jako najlżejszy runtime ma najniższy marginal energy footprint pod concurrent load (mniejsza presja na shared CPU frequency states)

Zbiory danych: Azure Function Trace 2020 (do generowania workloadów concurrent), FunctionBench jako wzorzec workload suite

[#JE-11] Runtime-aware keep-alive optimization: pomiar E_cold i λ_idle dla JS runtimeów jako rozszerzenie modelu LACE-RL

Status: new Priorytet: medium Dodano: 2026-05-28 Bazuje na: sun-green-or-fast-serverless-2026, [JE-1], [JE-6]

Gap w LACE-RL 2026:

  • LACE-RL modeluje cold-start LATENCY per runtime (lookup table z Huawei Trace: Python, Custom, etc.) — to jest wyjątkowe w literaturze
  • Ale model energetyczny E_cold(f) = P_cold(f)·T_cold(f) zakłada P_cold jednorodne (niezależne od typu runtime) — tylko T_cold różnicuje runtimes
  • λ_idle (idle/active power ratio) zmierzono na 0.21–0.83 w FunctionBench (Python) — dla JS runtimeów jest nieznane; Bun (JavaScriptCore) vs Node.js (V8) mogą mieć różne idle power patterns po warm-up JIT
  • Kluczowe pytanie: Czy zmiana runtime JS (Node.js → Bun) zmienia optymalny czas keep-alive przewidziany przez LACE-RL poprzez zmianę E_cold i/lub λ_idle?

Proponowane badanie:

  1. Pomiar E_cold per runtime: profil energii cold-start dla Node.js/Deno/Bun na FunctionBench-equivalentach JS (analogicznie do Table II w LACE-RL, ale dla JS)
    • Faza cold start: inicjalizacja procesu + JIT compilation warm-up + first request
    • Narzędzia: Kepler (w Kubernetes jak LACE-RL) + PowerJoular (na bare metal)
  2. Pomiar λ_idle per runtime: idle/active power ratio dla ciepłych podów Node.js/Deno/Bun
    • H11a: Bun ma niższe λ_idle niż Node.js (mniejszy runtime, mniejszy idle heap)
    • H11b: λ_idle zależy od workload type: dla memory-intensive JS (large JSON) może być wyższe niż dla CPU-bound
  3. Symulacja wpływu na LACE-RL decyzje: podstaw zmierzone E_cold(runtime) i λ_idle(runtime) do modelu LACE-RL; sprawdź czy optymalny keep-alive timeout zmienia się per runtime
    • H11c: Runtimes z niższym E_cold preferują krótsze keep-alive (cold start jest “tańszy”)
    • H11d: Runtimes z niższym λ_idle preferują dłuższe keep-alive (trzymanie ciepłego poda jest “tańsze”)
  4. Walidacja na Huawei Trace: Trace zawiera Runtime Metadata (Python/Custom/etc.) — analiza czy “Custom” runtimes (potencjalnie JS/Node.js) mają inny profil cold-start niż Python

Wkład badawczy:

  • Pierwsze zmierzenie E_cold i λ_idle dla JS runtimeów (Node.js/Deno/Bun) w środowisku Kubernetes
  • Rozszerzenie modelu LACE-RL o runtime-aware energy parameters — runtime-conditioned keep-alive optimization
  • Empiryczna walidacja: czy wybór runtime JS ma znaczący wpływ na optymalną politykę keep-alive

Hipotezy:

  • H11a: Bun ma niższe E_cold niż Node.js (krótszy cold start → proporcjonalnie mniejsza energia; H6-H3 analogia)
  • H11b: λ_idle(Bun) < λ_idle(Node.js) — mniejszy idle heap i mniejsza aktywność GC idle
  • H11c: Runtime z niższym E_cold preferuje krótsze keep-alive w modelu LACE-RL (cold start jest “tańszy” → mniej warte utrzymywanie ciepłego poda)
  • H11d: Runtime-aware LACE-RL redukuje carbon footprint o >10% względem runtime-agnostic LACE-RL dla heterogenicznego klastra JS

Zbiory danych: FunctionBench (kalibracja, wzorzec), Huawei Public Cloud Trace (runtime metadata validation), własne pomiary JS runtimeów

[#JE-12] DVFS-aware JS runtime selection: różnicowanie krzywych energy×frequency dla Node.js/Deno/Bun

Status: new Priorytet: medium Dodano: 2026-05-28 Bazuje na: tsenos-energy-scheduling-serverless-2024, [JE-1]

Gap w EES 2024:

  • EES (Tsenos 2024) zakłada podobne CPU utilization → podobna energia jako fundamentalne założenie profile-matching
  • Kluczowy wynik EES: 4.0→3.6 GHz = 10% wolniej ale 22.5% mniej energii — ale ta krzywa jest mierzona dla Go/Python functions
  • Brak analizy jak DVFS wpływa na różne JS runtimes: V8 (Node.js/Deno) z intensywnym JIT compilation może inaczej reagować na zmiany częstotliwości niż Bun/JavaScriptCore (szybszy startup, lżejszy JIT)
  • Hipoteza: przy niskiej częstotliwości CPU, V8 JIT compilation staje się relatywnie droższy (kompilator działa wolniej) → energy savings z DVFS są mniejsze dla Node.js niż dla Bun

Proponowane badanie:

  1. Pomiar krzywych energy×frequency per runtime: Node.js/Deno/Bun × {2.0, 2.4, 2.8, 3.2, 3.6, 4.0 GHz} × {CPU-bound, I/O-bound, cold start}
  2. Pytania badawcze:
    • Czy krzywa energy×frequency różni się między runtimeami przy tym samym workloadzie?
    • Przy jakiej częstotliwości Bun “przekracza” Node.js energetycznie (crossover point)?
    • Czy cold start energy jest bardziej wrażliwy na DVFS niż warm execution energy?
  3. Metryki: energia per request [J/req], czas per request [ms], EDP (Energy-Delay Product) per frequency
  4. Hardware: Intel i7/i9 z kontrolą DVFS przez cpupower (analogia do PMSU w EES)

Wkład badawczy:

  • Empiryczna charakteryzacja krzywych energy×frequency dla JS runtimeów — wkład do EES-style schedulerów
  • Odpowiedź: czy DVFS-aware scheduling powinien różnicować JS runtimes (różne optymalne GHz per runtime+workload)?
  • Praktyczna rekomendacja: optymalny punkt pracy (GHz) dla Node.js vs Bun vs Deno w środowisku energy-constrained

Hipotezy:

  • H12a: Krzywa energy×frequency dla Bun jest “płaszcza” (mniej stroma) niż dla Node.js — DVFS daje mniejszy procentowy zysk dla Bun
  • H12b: Optymalny GHz dla Node.js (minimalizacja EDP) jest wyższy niż dla Bun (V8 JIT zyska więcej z wyższej freq)
  • H12c: Dla cold start workloadów różnica między runtimeami w energy×frequency jest większa niż dla warm workloadów

Zbiory danych: własne pomiary eksperymentalne; wzorzec workloadu z FunctionBench (Sha256 ≈ Sha256/AES, Linpack, analog PDF)

[#JE-14] Energetyczny koszt izolacji: empiryczne porównanie V8 Isolates, MicroVMs, kontenerów i WASM sandbox dla JS workloadów

Status: new Priorytet: high Dodano: 2026-05-28 Bazuje na: agache-firecracker-serverless-2020, shillaker-faasm-serverless-2020, boucher-sledge-wasm-edge-2020, jangda-wasm-performance-2019, [JE-1]

Gap badawczy:

  • Agache et al. (2020, Firecracker): MicroVM ma 125ms cold start i 5MB overhead — bez pomiaru energii
  • Shillaker & Pietzuch (2020, Faasm): WASM isolation 10× szybszy cold start niż Docker — bez pomiaru energii
  • Boucher et al. (2020, Sledge): WASM edge runtime — bez pomiaru energii
  • Jangda et al. (2019): WASM 1.55× wolniejszy niż native — ale nie wiadomo ile to % energii
  • Kluczowa luka: żaden mechanizm izolacji nie ma zmierzonego kosztu energetycznego per JS request
  • Intuicja: V8 Isolates (< 1ms cold start, < 128KB overhead) powinny być najtańsze energetycznie — ale shared heap = ryzyko contention pod obciążeniem

Modele izolacji do porównania (od najcięższego do najlżejszego):

ModelImplementacjaCold startMem overhead
MicroVMFirecracker + Node.js~125ms~5MB + ~30MB runtime
Kontener OCIDocker + Node.js~50ms~20MB
WASM sandboxWasmtime (via Faasm model)~5ms~2MB
V8 IsolateDeno Deploy model (multiple isolates/process)<2ms~128KB
Bare processNode.js fork/exec~250ms~30MB
V8 Isolate + WASMBun model z WASM workloadem~2ms~300KB

Hipotezy:

  • H14a: V8 Isolates mają najniższy energetyczny koszt cold start ze wszystkich modeli (krótszy czas × niższy peak power)
  • H14b: MicroVM (Firecracker + Node.js) ma wyższy koszt energetyczny per request niż V8 Isolate o co najmniej 40% dla warm workloadów (overhead hypervisora)
  • H14c: WASM sandbox (Faasm/Wasmtime) ma niższy energetyczny koszt izolacji niż MicroVM ale wyższy niż V8 Isolate dla JS workloadów (WASM overhead kompensuje oszczędność na hypervisor)
  • H14d: Pod concurrent load (100+ concurrent requests), V8 Isolates degradują energetycznie szybciej niż MicroVMs (GC pressure na shared heap) — “paradoks lekkości”: przy dużej skali V8 Isolates mogą przegrać
  • H14e: Energetyczny koszt izolacji to ≥20% całkowitego zużycia energii dla short-lived JS funkcji (<50ms)

Proponowane badanie:

  1. Środowisko: bare-metal Intel server, Ubuntu 24.04; wszystkie modele uruchomione na tym samym sprzęcie
  2. Workloady: identyczny kod JS (Fibonacci CPU, HTTP echo, JSON parse) uruchomiony przez każdy mechanizm izolacji
  3. Pomiar:
    • PowerJoular per-process (gdzie możliwe)
    • Intel RAPL system-level
    • Manualny pomiar: energia(z izolacją) − energia(bez izolacji) = koszt izolacji
  4. Skale obciążenia: 1 concurrent, 10 concurrent, 100 concurrent
  5. Metryki: energia cold start [J], energia warm request [J/req], overhead energetyczny [%]

Wkład badawczy:

  • Pierwsze empiryczne porównanie energetyczne mechanizmów izolacji dla JS workloadów
  • Charakteryzacja “paradoksu lekkości” — kiedy V8 Isolates przestają być najtańsze
  • Rekomendacja: który model izolacji używać dla jakich workloadów JS z perspektywy energii
  • Dane wejściowe dla projektu nowego runtime (#JE-15)

[#JE-15] Projekt nowego środowiska uruchomieniowego JS dla serverless: energy-first architektura z adaptacyjnym JIT tiering i WinterCG compliance

Status: new Priorytet: high Dodano: 2026-05-28 Bazuje na: [JE-1], [JE-3], [JE-6], [JE-9], [JE-14], agache-firecracker-serverless-2020, shillaker-faasm-serverless-2020, jangda-wasm-performance-2019

Motywacja i Gap:

  • Istniejące runtimes (Node.js, Deno, Bun) projektowano pod kątem czasu odpowiedzi i zgodności — nie energii
  • V8 i JavaScriptCore mają trójpoziomowy JIT (interpreter → baseline → optimizing) zoptymalizowany pod kątem throughput, nie EDP (Energy-Delay Product)
  • Firecracker minimalizuje overhead izolacji dla latencji — nie bierze pod uwagę energii JIT compilation
  • Cloudflare Workers (V8 Isolates) minimalizuje cold start ale bez energy-awareness w tiering
  • Żaden istniejący JS runtime nie ma formalnego modelu energetycznego wbudowanego w decyzje JIT

Proponowana architektura: EcoRuntime (robocza nazwa)

Warstwa 1: WinterCG-compliant API surface
  - Fetch, Streams, SubtleCrypto, URL, TextEncoder, Timers
  - WASI 0.2 (WebAssembly System Interface) dla portability
  - navigator.energyEstimate(): Promise<EnergyEstimate>  [propozycja WinterCG]

Warstwa 2: Energy-aware JIT Tier Selector
  - Input: invocation_freq, energy_budget, latency_SLO
  - Output: JIT tier (0=interpret / 1=baseline / 2=optimizing)
  - Model: minimalizuj EDP = E × T przy zachowaniu latency_SLO
  - Tier upgrades tylko gdy: (koszt recompilacji) < (zysk energetyczny × przewidywane wywołania)

Warstwa 3: Izolowany kontekst wykonania
  - V8 Isolates model (shared heap, isolated contexts) — minimalizacja cold start
  - Opcjonalnie: WASM sandbox dla untrusted code (Faasm/Sledge-inspired)
  - Per-isolate energy counter: software + RAPL hardware

Warstwa 4: Energy Attribution + Carbon-aware Scheduler
  - Per-function energy metering (hardware RAPL + software interpolation)
  - Carbon intensity feed (WattTime API / Electricity Maps)
  - Scheduling policy: defer non-critical functions → low-carbon windows
  - Keep-alive policy: LACE-RL model z JS-runtime-specific E_cold i λ_idle (z #JE-11)

Kluczowe innowacje:

  1. Energy-aware JIT tier selection — formalny model:

    • Przy invocation_freq < threshold: zostań na Tier 0 (interpreter) — oszczędność JIT compilation energy
    • Przy invocation_freq > threshold1: upgrade do Tier 1 (baseline JIT)
    • Przy invocation_freq > threshold2 I energy_budget wystarczający: Tier 2 (optimizing JIT)
    • threshold1, threshold2 wyznaczane z: E_jit_compilation / E_savings_per_call
    • Hipoteza: dla typowych serverless (short-lived, rzadkie wywołania) Tier 0-1 jest optymalny energetycznie

  2. Per-isolate energy attribution API:

    // Propozycja WinterCG extension
const estimate = await navigator.energyEstimate();
// { joules: 0.0023, confidence: 'high', method: 'rapl' }
    • Ekspozycja zużycia energii na poziomie funkcji JS
    • Umożliwia self-throttling: funkcja redukuje obliczenia gdy energy budget wyczerpany

  3. Runtime-specific E_cold i λ_idle (z JE-11):

    • EcoRuntime projektowany aby minimalizować E_cold (krótszy cold start, mniejszy snapshot)
    • Niskie λ_idle przez agresywne zwalnianie heap między wywołaniami (GC trigger przy idle)

Proponowane badanie (fazy):

Faza 1 — Proof of Concept (~6 miesięcy):

  • Modyfikacja Deno (open-source, Rust + V8) — dodanie energy-aware JIT tier selector
  • Instrumentacja RAPL per-isolate przez perf_events + eBPF
  • Implementacja navigator.energyEstimate() jako Deno extension
  • Benchmarki: czy energy-aware tiering redukuje EDP dla cold functions?

Faza 2 — Ewaluacja (~3 miesiące):

  • Porównanie EcoRuntime vs Node.js/Deno/Bun na standardowych benchmarkach (#JE-1 workloady)
  • Pomiar: EDP reduction %, latency penalty %, cold start energy
  • Analiza: przy jakich workload charakterystykach EcoRuntime wygrywa/przegrywa?

Faza 3 — Carbon-aware scheduler (~3 miesiące):

  • Integracja z WattTime API
  • Symulacja: 24h trace Azure Function Trace × carbon intensity × EcoRuntime vs Node.js
  • Metryka: gCO₂/milion requestów

Hipotezy:

  • H15a: Energy-aware JIT tiering redukuje EDP o ≥15% dla funkcji z invocation_freq < 1/s względem standardowego Deno
  • H15b: EcoRuntime ma wyższy latency penalty (<10%) przy niskiej częstotliwości wywołań vs Node.js — akceptowalny dla batch/background functions
  • H15c: EcoRuntime zachowuje WinterCG compliance i jest kompatybilny z istniejącymi Deno programami bez modyfikacji kodu
  • H15d: Carbon-aware scheduler z EcoRuntime redukuje gCO₂/milion requestów o ≥20% vs Node.js bez carbon-awareness

Wkład badawczy:

  • Pierwsza formalna specyfikacja energy-first JS runtime dla serverless
  • Implementacja prototypu (Deno fork) — open-source, weryfikowalny
  • Formalny model JIT tier selection oparty na EDP
  • Propozycja navigator.energyEstimate() jako rozszerzenie WinterCG
  • Empiryczna odpowiedź: jaki tradeoff EDP vs latency jest akceptowalny w serverless?

Zbiory danych: własne benchmarki z JE-1, Azure Function Trace 2020, Huawei Trace (z JE-11), FunctionBench

[#JE-16] navigator.energyEstimate(): propozycja standardu WinterCG dla energetycznie świadomych funkcji JS

Status: new Priorytet: medium Dodano: 2026-05-28 Bazuje na: [JE-15], [JE-3], noureddine-powerjoular-2022

Gap badawczy:

  • WinterCG definiuje Fetch, Streams, Crypto, URL — brak prymitywów energetycznych
  • Nie istnieje standardowy sposób dla kodu JS aby zapytać: “ile energii zużywam?”
  • Funkcje serverless nie mogą adaptować się do energy budget — decyzje te są podejmowane tylko na poziomie schedulera (GreenCourier, CASA) — poza kontrolą kodu aplikacji
  • Analogia: performance.now() dało JS precyzyjny timing → navigator.energyEstimate() może dać JS energy feedback

Proponowany standard:

// Propozycja WinterCG API (do standardizacji)
interface EnergyEstimate {
  joules: number;           // szacowane zużycie energii od start do teraz
  confidence: 'high'|'medium'|'low';  // jakość pomiaru
  method: 'rapl'|'model'|'billing';   // źródło danych
  timestamp: DOMHighResTimeStamp;
}
 
interface Navigator {
  energyEstimate?(): Promise<EnergyEstimate>;
}
 
// Użycie w kodzie funkcji:
addEventListener('fetch', async (event) => {
  const startEnergy = await navigator.energyEstimate?.();
  
  // ... heavy computation ...
  
  const endEnergy = await navigator.energyEstimate?.();
  const used = (endEnergy?.joules ?? 0) - (startEnergy?.joules ?? 0);
  
  if (used > energyBudget) {
    // Przełącz na tańszą obliczeniowo ścieżkę
    return Response.json({ result: approximateResult, quality: 'reduced' });
  }
  return Response.json({ result: fullResult, quality: 'full' });
});

Proponowane badanie:

  1. Specyfikacja API: analiza istniejących platform, wymagania use-case, model prywatności (Timing Attack?)
  2. Proof of Concept: implementacja w Deno jako extension (--unstable-energy)
  3. Przypadki użycia: self-throttling ML inference, adaptive image processing, streaming compression
  4. Ewaluacja: overhead energyEstimate() call vs dokładność szacowania
  5. Propozycja do WinterCG Community Group

Hipotezy:

  • H16a: Overhead wywołania navigator.energyEstimate() < 1μs dla software model, < 100μs dla RAPL — akceptowalny dla serverless
  • H16b: Funkcje JS z self-throttling (na podstawie energyEstimate) mogą redukować zużycie energii o ≥10% przy ≤5% degradacji jakości wyników
  • H16c: Model RAPL-based energy attribution ma błąd < 15% względem hardware power meter dla typowych JS workloadów

Wkład:

  • Formalna specyfikacja navigator.energyEstimate() API z analizą bezpieczeństwa
  • Prototyp w Deno + przypadki użycia
  • Podstawa dla propozycji W3C WinterCG extension

[#JE-13] JS runtime selection jako czwarty wymiar triple-sustainability FaaS: wpływ na carbon, wastewater i SLO jednocześnie

Status: new Priorytet: low Dodano: 2026-05-28 Bazuje na: qi-slo-carbon-wastewater-faas-2024, [JE-1], [JE-7]

Gap w SFCM 2024:

  • SFCM co-optymalizuje trzy cele (SLO, carbon, wastewater) przez scheduling decisions — nie przez wybór runtime
  • Energy usage → cooling water evaporation → wastewater: bardziej efektywny runtime JS bezpośrednio redukuje wastewater przez zmniejszenie ciepła generowanego per request
  • SFCM i CASA traktują każdą funkcję jako “runtime-agnostic” — ta sama funkcja uruchomiona w Bun vs Node.js ma ten sam model energetyczny w ich frameworku

Proponowane badanie:

  • Rozszerz SFCM o runtime selection jako zmienną decyzyjną: dla każdego function ID wybierz: <scheduling, autoscaling, runtime>
  • Pokaż, że runtime selection zmienia kształt Pareto front (SLO, carbon, wastewater)
  • Zmierz bezpośrednio: energia per request w Bun vs Node.js → przelicz na carbon + cooling wastewater reduction

Wkład: Rozszerzenie SFCM/CASA framework o runtime-aware triple-sustainability optymalizację. Praktyczna rekomendacja: deployment Bun zamiast Node.js = jednoczesna redukcja carbon + wastewater + potencjalna poprawa SLO (szybszy startup).

Hipotezy:

  • H13a: Wybór Bun zamiast Node.js dla CPU-bound funkcji redukuje energy per request o >15%, co bezpośrednio przekłada się na mniejszy cooling wastewater
  • H13b: Runtime-aware SFCM domuje runtime-agnostic SFCM w przestrzeni Pareto (SLO, carbon, water)

Zbiory danych: Azure Function Trace 2020 (workloady jak w SFCM), własne pomiary energii JS runtimeów (#JE-1)

🔬 Hipotezy — zestawienie zbiorcze

IDHipotezaTestowana wSpodziewany wynik
H1aBun < Node.js energetycznie dla CPU-boundJE-1Potwierdzenie (JavaScriptCore efektywniejszy)
H1bDeno < Node.js energetycznie dla async I/OJE-1Możliwe potwierdzenie (Tokio async)
H1cBrak “zawsze najlepszego” runtimesJE-1Potwierdzenie (zależność od workloadu)
H2aTOPSIS energy:latency:cost wystarczającyJE-2Do walidacji
H2bModel decyduje inaczej niż latency-only w >30%JE-2Do walidacji
H3aV8 wymaga 10-15 warm-up iteracjiJE-3Do pomiaru
H3bGC spikes >5% wpływ na medianę energiiJE-3Prawdopodobne
H3cRAPL vs hardware: R²>0.95JE-3Potwierdzenie (literatura)
H4aWasm AoT < Node.js cold start energiaJE-4Możliwe potwierdzenie (Lumos)
H4bEdge hardware amplifikuje różnice runtimeJE-4Do zbadania
H6aKeep-warm opłacalne energetycznie przy >1/5minJE-6Do obliczenia
H10aHierarchia runtimeów zmienia się dla I/O-bound pod concurrent loadJE-10Prawdopodobne (RAPL nie widzi I/O)
H10bMarginal energy < isolated energy measurements — mniejsze różnice między runtimeamiJE-10Do zbadania
H10cBun najniższy marginal energy footprint pod concurrent loadJE-10Do zbadania
H11aBun ma niższe E_cold niż Node.js (krótszy cold start = mniej energii init)JE-11Prawdopodobne (Bun szybszy startup)
H11bλ_idle(Bun) < λ_idle(Node.js) — mniejszy idle heap, mniejsza aktywność GC idleJE-11Do zbadania
H11cRuntime z niższym E_cold preferuje krótsze keep-alive w LACE-RLJE-11Logiczne (implikacja modelu)
H11dRuntime-aware LACE-RL redukuje carbon >10% vs runtime-agnostic dla hetero. klastra JSJE-11Do walidacji
H12aKrzywa energy×frequency Bun jest płasza niż Node.js (DVFS daje mniejszy zysk)JE-12Do zbadania
H12bOptymalny GHz (min EDP) dla Node.js jest wyższy niż dla BunJE-12Prawdopodobne (V8 JIT freq-hungry)
H12cCold start energy×frequency bardziej zróżnicowane per runtime niż warm executionJE-12Prawdopodobne
H13aBun zamiast Node.js redukuje energy per request >15% → bezpośrednia redukcja cooling wastewaterJE-13Wymaga JE-1
H13bRuntime-aware SFCM domuje runtime-agnostic SFCM w przestrzeni Pareto (SLO, carbon, water)JE-13Logiczne
H14aV8 Isolates mają najniższy energetyczny koszt cold start ze wszystkich modeli izolacjiJE-14Prawdopodobne (krótszy czas × niższy peak power)
H14bMicroVM (Firecracker+Node.js) ma ≥40% wyższy koszt energetyczny per request niż V8 Isolate (warm)JE-14Do zbadania
H14cWASM sandbox: niższy koszt izolacji niż MicroVM, wyższy niż V8 Isolate dla JS workloadówJE-14Prawdopodobne
H14dPrzy ≥100 concurrent, V8 Isolates degradują energetycznie szybciej niż MicroVMs (GC pressure)JE-14Do zbadania — paradoks lekkości
H14eKoszt izolacji ≥20% całkowitej energii dla short-lived JS funkcji (<50ms)JE-14Do pomiaru
H15aEnergy-aware JIT tiering redukuje EDP o ≥15% dla invocation_freq < 1/s vs standardowy DenoJE-15Do walidacji
H15bEcoRuntime: latency penalty <10% vs Node.js dla cold/rzadkich funkcji (akceptowalny tradeoff)JE-15Do walidacji
H15cEcoRuntime zachowuje pełną WinterCG compliance bez modyfikacji istniejącego kodu DenoJE-15Prawdopodobne (Deno jako baza)
H15dCarbon-aware scheduler z EcoRuntime: ≥20% mniej gCO₂/milion requestów vs Node.jsJE-15Wymaga JE-11
H16aOverhead navigator.energyEstimate() call: <1μs (model) / <100μs (RAPL)JE-16Prawdopodobne (analogia do performance.now)
H16bSelf-throttling JS funkcje redukują zużycie energii o ≥10% przy ≤5% degradacji jakościJE-16Do walidacji

📚 Kluczowe luki badawcze (Research Gaps)

  1. Główna luka (#JE-1): Brak jakichkolwiek pomiarów energetycznych Node.js/Deno/Bun — Smirnov (2024) mierzy tylko czas
  2. Metodologiczna luka (#JE-3): Brak standaryzowanego protokołu uwzględniającego JIT warm-up i GC dla JS
  3. Kontekst luka (#JE-4): Lumos (2025) pomija pomiar energii, De Macedo (2022) pomija serverless i nowe runtimes
  4. Model decyzyjny (#JE-2): Brak wielokryterialnego modelu energia×latencja×koszt dla JS runtime selection
  5. Cold start energia (#JE-6): Golec (2024) obszerny przegląd cold start — bez wymiaru energetycznego

📊 Statystyki projektu

  • Łącznie: 16 pomysłów
  • High: 6 (#JE-1, JE-2, JE-3, JE-10, JE-14, JE-15)
  • Medium: 7 (#JE-4, JE-5, JE-6, JE-9, JE-11, JE-12, JE-16)
  • Low: 3 (#JE-7, JE-8, JE-13)
  • Hipotez: 38 konkretnych hipotez testowych
  • Nowe publikacje bazowe (2026-05-28): Firecracker/Agache 2020 (MicroVM baseline), Faasm/Shillaker 2020 (WASM isolation), Sledge/Boucher 2020 (edge WASM runtime), Not So Fast/Jangda 2019 (WASM overhead)
  • Ostatnia aktualizacja: 2026-05-28

Graf

Odnośniki zwrotne