Client java version

Jump to navigation Jump to search

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.

Beaming (talk)04:03, 4 September 2017

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.

Xor (talk)05:45, 4 September 2017

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.

Beaming (talk)06:20, 4 September 2017

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?

Xor (talk)11:18, 4 September 2017

> 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.

MultiplyByZer0 (talk)11:58, 4 September 2017

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.

Beaming (talk)16:25, 4 September 2017

Apologies, Xor and Beaming.

MultiplyByZer0 (talk)22:23, 4 September 2017

No worries. I can take criticism when it is justified. You did a lot of wiki clean up work alone which was long overdue. I am not surprised that you felt that the rest of us do not care.

Beaming (talk)02:18, 6 September 2017

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.

Beaming (talk)06:24, 4 September 2017

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.

Xor (talk)06:57, 4 September 2017

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/Client java version/reply (27).

I do not think that above report indicates that MoxieBot is broken. Actually, the log indicates that the bot was working and was reporting sensible things. The part about

SYSTEM: ncj.MoxieBot 1.0 has died

is due to its logic: MoxieBot does not fire when there are no bullets in the air. If the other bot runs out of energy, then they both wait and robocode gives an energy penalty kick after certain "no fire" timeout. Eventually they both killed by penalty energy drain, which is reported as "has died".

I played MoxieBot in the GUI it gives similar log entry while it is moving and firing.

Beaming (talk)02:31, 5 September 2017

In the log above, there are 25 lines of "Hit by a wave that was not being correctly tracked", indicating MoxieBot losing energy. That would be consistent with MoxieBot stalling and MyFirstRobot getting a 100% hitrate on it. MyFirstRobot fires 1.0 power bullets, which cause 4.0 damage, and 100 / 4 = 25 hits to kill = 25 log messages.

I also made a video of MoxieBot vs. TrackFire on that computer. It stalls for 2 rounds, but works on the other 8. It doesn't seem so bad when not minimized.

I wonder if the bug is that MoxieBot loses its radar lock and cannot regain it, which wouldn't be that hard of a fix...

MultiplyByZer0 (talk)03:37, 5 September 2017
Edited by author.
Last edit: 05:44, 5 September 2017

Yep. This is what I see as well. It seems to be a bug in the MoxieBot logic. Not in the robocode.

By the way ThreadDeath is also there. Looks like I need to try java7 or earlier and see if ThreadDeath related losses are there.

Beaming (talk)05:37, 5 September 2017

I also checked the historical robocode 1.8.3, MoxieBot has the same buggy behaviour.

Beaming (talk)05:41, 5 September 2017

openjdk8 here, on Linux.

Skilgannon (talk)08:26, 4 September 2017

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)

Cb (talk)10:14, 4 September 2017

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

Dsekercioglu (talk)10:33, 4 September 2017
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.

MultiplyByZer0 (talk)11:36, 4 September 2017

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.

GrubbmGait (talk)12:11, 4 September 2017


Rsalesc (talk)12:47, 4 September 2017

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 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?

Beaming (talk)16:20, 4 September 2017

@ 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.

Beaming (talk)16:27, 4 September 2017

Okay I'm closing it.

Dsekercioglu (talk)16:28, 4 September 2017

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.

Xor (talk)16:42, 4 September 2017

Would adding a bot written with JDK9 and compiled with robocode would create a problem if there was an error with JDK9?

Dsekercioglu (talk)13:27, 6 September 2017

If there is an error in JDK, than sure it will be a problem.

But there might be a problem with JDK9 compilation, even if jdk9 itself is good, if the rest of us run literumble with java8. You bot might even not start in our clients.

Couple years ago when java transitioned from java 6 to java 7, we had this issue in rumble. People who made their bots with more recent java were in disadvantage and their bots showed a lower score.

I would suggest to cross compile your bot to java8 version, since according to the poll the rest of us run java8. Or go to extremes and make it compatible with java7 via retrolambda, as User:Xor does.

Beaming (talk)16:19, 6 September 2017

Java 7 compatible is a very good idea, I am on 1.7_051 (but intend to go to JDK 8 in the near future) and can't run battles for a handful of bots. Just look at the missing pairings of GrubbmThree 0.9a. Btw, other clients should do those, why don't they. But it seems that there are also a few bots that can't handle a Java 8 client, like tcf.Drifter and sm.Devil (see comparison between GrubbmThree and MaxRisk)

GrubbmGait (talk)17:43, 6 September 2017

There is something fishy with literumble. In console, I see a lot of entries like

Ignoring: gh.micro.GrubbmThree 0.9a,cb.nano.Insomnia 1.0,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.ColdBreath 1.9,SERVER
Ignoring: dsekercioglu.HammerR 1.1,gh.micro.GrubbmThree 0.9a,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,suzushin7.nano.Galaxy03 1.01,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,nosteel.Welby 0.0.3,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,cs.PumpkinPie 1.0,SERVER
Ignoring: cb.nano.Insomnia 1.0,gh.micro.GrubbmThree 0.9a,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Husky 1.9,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Wyvern 1.0,SERVER
Ignoring: gh.micro.GrubbmThree 0.9a,dsekercioglu.Hammer 8.6,SERVER
Ignoring: theo.Hydrogen 2.1r,gh.micro.GrubbmThree 0.9a,SERVER

Beaming (talk)18:17, 6 September 2017

I see the problem. Your bot is entered as

gh.micro.GrubbmThree 0.9a,!Aj169YS0AhgMoQVZe6rd5zXnabUE

If I point a console downloader like 'wget' to this link, it downloads some web page and not the bot. You should no better but to trust your files to MS products which break all possible web standards and serve different content depending on the web accessing clients.

Bottom line, we cannot run your bot because literumble clients cannot download it.

Beaming (talk)18:25, 6 September 2017

Nothing to do with MS products, just an indirect download link. Dropbox and Google Drive do this as well.

Direct download link:

That link broke too. (Apparently OneDrive direct download links are not permanent.) Luckily, Rednaxela's server picked it up.

MultiplyByZer0 (talk)18:37, 6 September 2017

I will look into that this evening, I switched provider, so my old webspace is gone. It explains why I provided most (or all) of the battles although I have separate installs for robocode and roborumble.

GrubbmGait (talk)18:37, 6 September 2017

Put them (version a b c and d) on GoogleDrive now. Still missing 7 pairings, so I wait a bit before switching to 0.9b

GrubbmGait (talk)20:44, 6 September 2017

According to the code, it shouldn't be harmful. It's just to make sure the client has the JAR, and to prevent duplicates.

// Check that competitors exist
String jar1 = items[0].replace(' ', '_') + ".jar";
boolean exists1 = (new File(botsrepository + jar1)).exists() && namesAll.contains(items[0]);
String jar2 = items[1].replace(' ', '_') + ".jar";
boolean exists2 = (new File(botsrepository + jar2)).exists() && namesAll.contains(items[1]);

// Add battles to priority battles list
if (exists1 && exists2 && !priorityBattles.contains(record)) {
} else {
    System.out.println("Ignoring: " + record);
MultiplyByZer0 (talk)18:29, 6 September 2017

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 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.

Rsalesc (talk)16:34, 4 September 2017

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?

Skilgannon (talk)20:01, 4 September 2017

So, I was little distracted when I read the source for the first time. Now I've read it again.

This error is thrown when the bot must be stopped because it skipped too many turns in a row, since Thread.stop() is deprecated. Is that right? I can safely assume that if this error appears, then the bot has skipped too many turns in a row?

My only doubt is (it's more like a curiosity than anything else): what may cause the robot to skip this amount of turns when going full speed and not to skip any turns when going 1000 TPS?

I'm on OpenJDK 8 and Ubuntu, by the way.

Rsalesc (talk)02:38, 5 September 2017
Edited by author.
Last edit: 21:54, 5 September 2017

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. (Edit: As of September 5, 2017 8:49 PM CET, I have started running meleerumble). 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.

MultiplyByZer0 (talk)17:33, 4 September 2017

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.

Skilgannon (talk)19:43, 4 September 2017

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.

Beaming (talk)20:09, 4 September 2017

Heavy vs light causing problems sounds to me like a race condition. And I think this might even be a separate issue from MoxieBot getting 0. This clearly needs further investigation.

Skilgannon (talk)20:39, 4 September 2017

I took a look at your results. Your bot is performing below expectations, most prominently with 37.71% survival against sample.Crazy (???), which I cannot reproduce on my own computer.

I do agree that bugs (particularly ones that produce unfair results) ought to be squashed ASAP. However, you cannot expect the amount of work-per-turn your bot is allowed to perform to remain constant between machines (and possibly not even between battles or rounds). Perhaps a CPU-intensive background process is running, or the user decides to play video games, or the OS starts throttling Java, or the CPU drops to 0.15 GHz for no good reason (I've actually seen that happen), or gamma rays hit your computer and flip a bit in the tick time counter, or whatever.

My point was that high-CPU bots must adapt to changing circumstances. Too many bots just ignore SkippedTurnEvent, when it's practically a blaring flashing-red-lights warning from Robocode. You could respond by reducing CPU load, e.g. disabling features, virtual guns, second wave surfing, etc. It's better for your bot to function suboptimally than to not function at all.

MultiplyByZer0 (talk)21:18, 4 September 2017

Agreed that the SkippedTurnEvent is mostly ignored, and that more could be done on this side. However, there is a reason that we have the CPU calibration, and that is because we want all environments to be similar. It is impossible to get consistent results if on one computer you can do second wave surfing with precise intersection and KNN gun with Gaussian kernel density estimation, and the other you have to fall back to single wave and a simple VCS gun. It would require all rumble battles to be contributed by a single machine, and then we are back to a standard environment.

Skilgannon (talk)23:36, 4 September 2017

While I take the blame for my bot performance.

I would claim that I am not ignoring the skip turn event. I have a counter for it, and I release bots which keep it low through the game. Typically in the rumble, it reports zero about every second round in 35 rounds game, in 45% rounds it is 1; in 2 or 3 rounds it spikes up to 7 or even 15 per round. Even 15 skips per 700 turns games is not too much to loose a game to sample.crazy with HoT gun.

So I still think it is the "Thread.Death" which is probably triggered by skipped turns.

I will try to reduce the bot CPU demand and see if the problem goes away.

Beaming (talk)02:42, 5 September 2017

ThreadDeath is just Thread.stop() doing its job.

See this article.

MultiplyByZer0 (talk)01:48, 6 September 2017

Are we actually talking about time-per-turn problem? I supposed, given the age of Robocode and Roborumble, that this is a well discussed topic and that every possible decision to make the system work fair enough while providing the "contributing" feature was already made. It seems that what we are talking about here is a bug. I know every environment is not equal, but even with the very little time I have on Robocode I could conclude a robot should work under the assumption that at least a reasonable quota of its turn time will be respected (even if in reality it's not eventually). If that quota is not being respected even after like, 10 battles, in a machine that is OK, and the results are absurd like the results Beaming reported, there must be a bug somewhere, even if it's on Beaming's side, and IMO it's worth it to discuss it and, maybe, to find it, since it may explain some other weird behavior in the future.

Rsalesc (talk)02:13, 5 September 2017

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.

Beaming (talk)20:16, 4 September 2017

I don't think Robocode actually runs more than 1 thread at a time. I think the extra CPU is from the JVM JIT optimizer running in parallel.

Skilgannon (talk)20:41, 4 September 2017

I meant the whole robocode machinery. I recall that couple years ago the robocode client (and its java) was confined to one CPU, today it is not the case. See the attached screenshot.

htop screenshot

Beaming (talk)03:14, 5 September 2017

I have a hunch that I would like to test. Never mind. That idea was almost definitely wrong.

MultiplyByZer0 (talk)01:39, 5 September 2017