Not quite - there is only one JVM in play per Scheduler node. The actual executions are sandboxed within that JVM. That hasn’t changed. Think of it like this:
User A & B both have a community SmartApp. The code for the SmartApp is the exact same, meaning that the code gets compiled into the same Class. Previously we would create 2 Classes (One for each user) - each taking up its own memory. Now when user B executes (given that user A already did) when we look up the SmartApp to execute in the cache, we see that there is already a SmartApp with the same checksum in the cache (aka the code is the same) so instead of creating a new class for user B we just reuse the one that was created for user A. GC comes into the picture when we multiple this situation by thousands or tens of thousands of users and smartapps and we are at a memory limit. If User B tried to to execute and there wasn’t enough room in memory to create his SmartApp, User A’s Smartapp would have to be garbage collected first (major GC - stop the world collection because of how Class unloading works) to make room for User B’s SmartApp. Now - since we’ve de-duplicated a lot of SmartApps we’re not at the limit anymore and even if we were, chances are that the SmartApp is already in memory and we wouldn’t have to perform a GC anyway.
4 Likes