Client java version

Can we have a quick survey about java version with which you run your litumble clients?

I see that performance of my bots dropped since I switched to java-8-openjdk for bot compilations. Plus I see ridiculosly low scores for my bot against some very simple bots at the literumble. On my machine I beat them with much bigger margin. So I suspect that there is something strange with one of the clients.

For the record, I compile everything with java-8-openjdk and run my literumble clients with java provided within this jdk.

I'm using Java 8 for my rumbles. However, it seems that some bot stopped working on Java 8? etc. MoxieBot.

I'm also using Java 8 and its features for bot development. However, I compile my bot with Java 8, then transpile the bytecode to Java 6 compatible using retrolambda, as Java 8 compiled code will generally refuse to run on lower platform.

Cross porting from Java 8 seems to be excessive, if the rest of us are running Java 8. But let's see what others are running.

But why risk getting low scores when there are someone using Java6? I think anyone who participant in rumble should make the bot compatible with Java 6 until it is not officially supported by the literumble.

Maybe what we really need is a vote for moving the minimum requirement of running rumble from Java 6 to Java 8?

> what we really need is a vote

The problem with the Robocode community is that everyone talks making changes, but no one actually does anything.

Please don't be so harsh.

Our problem that we don't have large enough community. We can count active users in two hands. You cannot expect everyone to jump on the issues right away.

At least we can make reasonably complete bug reports and see if they can be addressed.

By the way, ncj.MoxieBot 1.0 is running OK on my machine. It sometimes freezes but it seems to be the fault of the internal logic.

But all my bots are getting 100% against MoxieBot on my computer, whereas there seems to be some 50% on the rumble, which makes me think that it doesn't work as expected on Java 8.

openjdk8 here, on Linux.

java version "1.8.0_102" Java(TM) SE Runtime Environment (build 1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)

JDK 9 on Mac. Having the same problems with you.

java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

on Windows 10.

Java 1.7, as I just use an older unused computer for it. Some bots don't run in the rumble, but those battles are not even fought, so no pollution of the stats. I plan to update to Java 1.8 later this week.

openjdk8

Ok. Among recent literumble clients uploads we mostly have java8. The only exceptions are Dsekercioglu and GrubbmGait, we also have uncertainty on Anonymous uploads. GrubbmGait did not make uploads more recent than 4 days old, while I have score glitches on more recent releases. It could be abnormality in Java9.

One more thing. If I run GUI client at full speed with debug graphics toggle off, from time to time I see a error message in console from robocode 1.9.2.5 about java Threads dying. In such battles my score drops a lot, strange thing that it is not directly related to skipped turns counts. It could be a bug in robocode itself.

Does anyone see such phenomenon?

@ Dsekercioglu, would you mind switching off you liteclient for a while? Let's see if we can pinpoint the issue to java9 glitches.

@ all, if you are not running java8, please do not run liteclient for a week, starting from 2017/09/04.

Okay I'm closing it.

Or you can just use two versions in parallel ;) For me I develop my bot and run the rumble on Java 8, but I always test it on Java 6 before every release to make sure it works.

Just install them in different directories, and call java executable with the correct directories when starting robocode/roborumble.

Yeah, I have exactly the same issue, but since I never saw anyone complain about this, I just ignored it. I can reproduce the issue with 1.9.2.6 as well.

I spent a lot of time reading Robocode's source trying to find a connection between that and skipped turns with no real success. Perhaps Skilgannon, which seems to be strongly related to how Robocode evaluate skipped turns as it is today, could share his thoughts about this.

When testing it with Roborio, there were a few times I fixed the running speed at 1000 TPS and could see skipped turn messages instead of these Thread errors, but this only happened when using my old GoTo code, which was really slow. I can't see skipped turn messages with Roborio 1.2.4, for example.

Then I tried to run Neuromancer with the same setup and could see a lot of these Thread dying errors as well, despite seeing no skipped turn messages when locking at 1000 TPS.

What is weird is not that the crashes are occurring at all. Maybe they really make sense. But the thrown exception instead of a helpful message is somewhat weird.

I sometimes see the ThreadDeath things as well, it seems completely sporadic. I can't reproduce it at all with the current dev version.

A possible issue is the platform it is run on. Windows has a system timer with a very coarse tick (30ms IIRC). We had to use the nanosecond timer in chunks of 0.999999ms to emulate the larger timer. Maybe this nanosecond timer is broken in later releases of Oracle JDK.

So I'm curious: the people who are seeing Moxiebot broken, are you running Windows? Are you using Oracle JDK or OpenJDK?

Perhaps we should all give more details about how we run the rumble client.

I run RoboRumble intermittently, not continuously (only when I see interesting new bots added to the participants list). So far, I've only run roborumble (not meleerumble or others), but that may change soon. It's running on my everyday-use computer, and not a dedicated machine. Sometimes I run Robocode battles or browse to CPU-intensive webpages, and that may cut into the amount of CPU the client gets. My CPU constant is 6500859 ns (6.5 ms) per turn. I have a 4-core machine, and RoboRumble tends to take up 30-60% CPU constantly. It takes about 15 minutes to execute 50 battles.

Seriously though, if your robot is incompatible with certain setups, the fault lies in your robot. Perhaps you should respond to SkippedTurnEvents by reducing the amount of computation your robot performs.

Running the rumble client on an ultrabook when I'm not using it and it is plugged into power. Often it uses 2 cores even with a single client. CPU constant is about 5.3ms in openjdk8 using Linux.

About the skipped turn thing, I agree. A big part of Robocode is how long you have to do your processing in. It is a massive tradeoff and I know some of my bots occasionally step over the edge. However, I also don't want to change the rules of the competition. If there is something in Oracle JDK8 that is killing certain bots we need to figure out what that is.

I am not arguing that heavy on skipping bots should not be punished, my complain that it is erratic and seemingly coming from Java itself. Looks like it shows when a heavy bot is matched against a low CPU demanding one.

By the way, sometimes it to my advantage. I see strange unexplainable APS gain in melee against 'sgp.JollyNinja 3.53' [1]

Note that my v7.4 is very mediocre when compared against v6.1, except one case JollyNinja.

Here is my setup,

I run literumble clients on two machines almost non stop. Each runs one rumble and one melee client at the same time. Since one has 4 cores and the other 6, this should not be a problem with CPU calculations under normal circumstances. Also, there is plenty of RAM so no swapping. If I expect high CPU demanding tasks, I stop clients so they not affected by CPU fight with other programs.

All my machines are 64 bit linux with openjdk-8-jdk-headless.

But I think at some point robocode became multi-threaded, so CPU constant (6.5 ms in my case) is not so relevant anymore. In top, I can see that rumble client often eats more than 100%, i.e. it spans between cores. Also, load on a machine seems to be high, i.e. it is often in the range of 3 for the 6 cores machine.

Plus there is CPU throttling which kicks in when ever it wants, thanks to modern hardware design.