JOTL: increase container memory to 2048m

[polykrate]

SBCL needs a larger heap for 128 live states (fork support) and bounded GC pauses. The startup script auto-sizes the heap to 75% of the container limit.

Made with Cursor

Summary by CodeRabbit

• Chores
  • Enhanced performance testing infrastructure by allocating additional memory resources to the Docker environment, enabling more stable and efficient test execution.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: cab37ef6-1a8e-401d-89f9-79cb85cc6353

📥 Commits

Reviewing files that changed from the base of the PR and between 8086412 and b00c898.

📒 Files selected for processing (1)

• .github/workflows/jotl-performance.yml

---

📝 Walkthrough

Walkthrough

This pull request increases Docker container memory allocation for the reusable-picofuzz workflow in the GitHub Actions performance testing pipeline by adding a docker_memory: '2048m' parameter to the workflow invocation.

Changes

Cohort / File(s)	Summary
Workflow Configuration .github/workflows/jotl-performance.yml	Added docker_memory: '2048m' input parameter to the reusable-picofuzz workflow invocation to allocate 2GB of memory to the Docker container.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• Add JOTL (JAM On The Lisp) to conformance & performance testing #2 — Introduces the reusable-picofuzz workflow invocation that this PR now configures with the docker_memory parameter.

Poem

🐰 A memory boost hops into view,
Two gigs of RAM for fuzzing through,
The Docker container grows more strong,
Performance tests won't take as long! 💨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly describes the main change: increasing container memory allocation to 2048m in the JOTL workflow configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[tomusdrw]

Just out of curiosity: did you notice any failures, or do you intend to see better perf numbers because of this?

[polykrate]

Hello !
No failures, I'm trying to understand why it is so slow, could be ram, or unoptimized garbage collector on the lisp side.

[tomusdrw]

Make sure to take a good look at the test data. AFAICT:

1. Storage & Storage_tiny should be dominated by PVM execution time / storage host calls.
2. Safrole is probably dominated by ticket verification
3. Fallback is probably dominated by signature verification.

Good luck with optimizing!