Good catch! JAVA_TOOL_OPTIONS is indeed set based on GITPOD_MEMORY.
This 1.88 GB value is the current memory request (a Kubernetes concept), i.e. how much memory we expect Gitpod workspaces to typically use.
However, all Gitpod workspaces are allowed to use up to 12.88 GB (the current memory limit) before any safeguard mechanism kicks in. (If your workspace uses more than 12.88 GB, the Linux OOM-killer will start killing your top-RAM-consuming processes until your workspace goes below 12.88 GB again.)
Yes, I think that should be possible. But since JAVA_TOOL_OPTIONS is being set in your /home/gitpod/.bashrc, you may want to unset (or modify) it there too, e.g. by appending to /home/gitpod/.bashrc from your .gitpod.yml tasks.
Prebuilds indeed have the same memory limit, so the OOM-killer will also kick in at around 12.88 GB RAM usage.
However, Prebuilds have a higher memory request (about 4.83 GB, which also translates to GITPOD_MEMORY and JAVA_TOOL_OPTIONS there) in order to pack them more sparsely on Gitpod’s headless nodes.
Haha, funny you should ask, because I’m currently implementing such a feature: Incremental Prebuilds.
But currently in production, when you click on Don't Wait for Prebuild, it will give you a totally unbuilt workspace (i.e. any before / prebuild / init tasks will only start running live in your fresh workspace).
The CPU limit is 6 vCPUs per workspace. (However, please note that there is also a fair-use policy that kicks in and temporarily throttles your CPU if you use 100% of all CPU for several minutes – unless you have the Unleashed paid plan that is.)
The disk space limit is currently 30 GB (but I think that doesn’t make sense and we should raise it to 50 GB).