lxx.Tomcat 3.55 vs cs.ags.Scarlet 1.1c

Jump to navigation Jump to search

Yeah, I was wondering if it were at all possible to limit memory per bot with the Java classloaders... I guess not? It sucks that one of these two bots is probably being punished just for using more memory than average, even though it might still be well short of its fair share of 256 megs.

Though if we used per bot limits in Melee, I wonder if a lot of us would have issues. You can probably get away with far more than your "fair share" of 51 megs in Melee, since you're usually not facing 9 other memory hungry bots.

Voidious21:35, 28 February 2012

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:RoboRumble/Participants/lxx.Tomcat 3.55 vs cs.ags.Scarlet 1.1c/reply (19).

 

I can only think of a dedicated JVM per bot to achieve this kind of limit. This is how it is done in Java clouds out there.

The challenge comes when you try to integrate the JVMs together to calculate battle state and skipped turns.

MN13:58, 29 February 2012
 

The robocode engine has already went through some changes to effectively support a similar (remote-ish VM) situation for .NET bots. I imagine that past work would make it less of a problem to use per-bot VMs in java. The biggest issue may be latency between the VMs slowing down the turns.

Rednaxela15:50, 29 February 2012