All toolsInteractive example · illustrative values

Java Runtime Evaluation

CloudPilot AI observes Heap, GC, Non-Heap, and heap-wave behavior together. It coordinates Xms, Xmx, and the container memory baseline, then validates the result through a controlled rollout.

Run one Java workload through the recommendation model

Each option contains 300 Heap points and 300 aligned GC-pressure points across one hour.

Regular Heap reclamation with sparse, low GC pulses.

Heap Used · high-density series

The selected workload's working-set shape and GC reclamation cycles.

Observed series

GC pressure · aligned series

Pause-time ratio aligned point-for-point with the Heap timeline.

Observed series

Dataset selection and RP configuration are independent: switching data never rewrites the policy values below.

RecommendationPolicy configuration

Only RP-exposed fields are adjustable. The 10–60m demo window range matches the visible one-hour source.

Memory history · spec.historyWindowDuration.memory60m

Memory percentile · spec.strategyPercentile.memoryP95

Heap percentile · spec.jvm.heapUsedPercentileP20

Recent Non-Heap window · spec.jvm.recentNonHeapWindow60m

Minimum Xms ratio · spec.jvm.minHeapXmsRatioOfMemory25%

Heap buffer · spec.jvm.heapBuffer20%

Heap Xms

3.67 GiB

Heap Xmx

4.41 GiB

Container memory baseline

5.25 GiB

GC coefficient

1.12

Stable Heap wave · choose the larger branch

Recommendation result

GC branch:2.67 GiB ·Heap-wave branch:3.67 GiB

Non-Heap guard:0.84 GiB

Minimum Xms ratio:25% · Δ0.00 GiB

Current Request:8.00 GiB ·34.4% modeled capacity release

Interpretation

This is a recommendation example. Request change is not actual memory reduction and must not be translated directly into bill savings.

Read JVM internals before changing the outer container

The pipeline scopes time windows from RecommendationPolicy, normalizes duration-weighted runtime series, solves two independent Heap candidates, protects Non-Heap with dual windows, enforces JVM constraints, and only then hands the memory baseline to the outer resource-policy envelope.

Resolve RP context

W_hist, P_memory, P_heap, W_recent ← RecommendationPolicy

The evaluation is reproducible from explicit policy fields and scoped metric windows.

Normalize observations

S̄ = Σ(valueᵢ × durationᵢ) / Σdurationᵢ

Invalid-duration series are removed before workload-level aggregation.

Interpolate GC pressure

k(GC) = piecewise-linear(GC pause ratio)

Three coefficient bands grow from 1.00 to a capped 2.85 safety multiplier.

Build two Heap candidates

Heap_gc = Q(P_heap) × k(GC) · Heap_wave = Q(P_memory) × 1.25

The branches model collection pressure and stable working-set demand independently.

Classify Heap dynamics

wave = Q90 / max(Q10, ε)

Stable wave selects max(Heap_gc, Heap_wave); variable wave isolates the GC branch.

Protect Non-Heap

NH = max(Qhist(P_memory), Qrecent(P_memory))

The recent window prevents stale history from understating short-lived native demand.

Solve JVM constraints

Xmx = Xms + heapBuffer · Xms / Memory ≥ minRatio

If the minimum ratio binds, Xms, Xmx, and Memory are raised atomically by the same delta.

Apply the policy envelope

JVM baseline → RP buffer → requestMin / requestMax → readiness gates

Container bounds and data-readiness checks remain outside the internal Heap solver.

The algorithm recommends; the test decides whether to expand

Compare outcomes inside matched-load windows. Value metrics and stability gates must pass together before broader rollout.

Choose representative services

Use Java services with complete metrics, stable traffic, and no concurrent major release.

Build a baseline window

Capture matched-load Memory Usage, Request, GC, OOM, startup, and service metrics.

Enable runtime optimization on a canary

Apply Xms and Xmx through newly created or recreated Pods, with rollback ready.

Observe an equivalent business cycle

Match traffic buckets and time ranges so lower traffic is not counted as algorithmic value.

Review jointly

Expand only after architecture and efficiency owners approve both value and stability.

No OOM regression

Container OOM, Java Heap OOM, and abnormal restarts do not exceed baseline.

No GC regression

GC Pause Ratio, long pauses, and throughput remain inside agreed thresholds.

Service metrics hold

Latency, error rate, QPS, and critical business metrics do not regress materially.

Startup remains reliable

Startup time, Ready time, and deployment success stay inside agreed thresholds.

Evaluation formulas and pass gates

Suggested target: actual Memory Usage reduction ≥ 20% · pending validation

Primary value metric
Usage reduction = 1 − after matched-load P95 Usage ÷ baseline matched-load P95 Usage

Scheduling capacity metric
Request reduction = 1 − after Memory Request ÷ baseline Memory Request

Be explicit about what this baseline can and cannot prove

Create a new Java baseline

The previous phase treated Java as a generic workload, so earlier capacity changes are not runtime-optimization results.

Twenty percent is a target

The outcome depends on current Heap configuration, GC behavior, Non-Heap, traffic, and stability gates.

Business metrics are validation guardrails

Customer service metrics participate in test acceptance and rollout protection.

Roll out with rollback

Xms and Xmx changes normally take effect through Pod creation or recreation, not direct mutation of an existing JVM.

Measurement scope

Runtime optimization validates actual memory and stability first, Request convergence and schedulable capacity second, and node-hours and bills last. Capacity, bills, and ROI are different result layers.