I studied the behaviour of the scheduler during a 18 game schedule which took 2 hours to complete. During this time heap usage was stable and never exceeded 500 MB.
I'm almost certain that there is nothing in the working of the scheduler that causes memory leak.
The only source of problem I can think of is in connection with the reuse of engines. If an engine requests that it is reloaded after each game, the engine game driver will do this. At the same time the scheduler by default closes all engines after each game and loads the participants of the new game. There is a timing here, the scheduler waits for the engine game to terminate properly and do what it wants to do. If this timing is not enough then there may be concurrency between the two reloadings which can corrupt engine data.
I strongly recommend that engine tournaments are played by XBOARD engines with reuse=1 feature. This makes no difference for scheduled games, because the engine will be reloaded anyway.
There seems to be an issue in displaying the pv of the engine in search output tab.
Given a position.
r3k2r/pp1pb1pp/4p3/5p2/8/4P3/PPPP1PPP/RNB1KB1R w KQkq - 1 7
From search output tab.
7. Bb5 a5 8. Nc3
From console tab of Bigbang.
17 854 614 4333955 f1b5 e8g8 b5d7 a7a5 b1c3
The 2nd (e8g8) and third (b5d7) moves in a pv were not displayed in output tab.
I'm almost certain that this problem has to do with castling. For the GUI encodes castling in Chess960 format for internal use. This has been taken into account in the code but may have been missed in the new engine driver. It is likely that e8g8 was refused because the board is only prepared to execute e8h8.
Pv calculation in engine thinking output corrected. I was thinking along the right lines but the problem was even more subtle. This was a very useful observation, because it let me reveal a deeper, very tricky bug in the function which examines whether a move given in algebraic notation is legal. This function was also developed for the engine pv calculation, luckily it does not play part in other parts in the program. I usually use SAN notation where castling is same for Standard and Chess960.
Scheduler and engine game timing was modified so that both threads perform longer sleeps waiting for operations to finish. In particular scheduler now waits 20 seconds for the engine game to make proper cleanup ( this was 8 seconds ).
I run a new match using a scheduler. This time I only use 2 engines, and 1 starting position. The engine is between Bigbang and atomkraft both are set with 128 MB hash. Still with TC 40/40.
Heap size started around less than 512. Right now before game 1 ends, heap size is 1259. In javaw.exe it registers 1.5 GB (memory, private working set) from win task manager.
The scalachesgui I use in post #71 is from post #74.
The 2-game match between Bigbang and atomkraft ended with a max heap size if 1259.
Restarted the scalachessgui and run a new 2-game match between Bigbang and stockfishai. Game 1 is in progress (move 9) and heap size is below 512, sometimes 325, 333, 355, 369, 348. javaw.exe is below 1GB.
After 12th move, heap size is above 512.
Correction in post 76.
The scalachesgui I use in post #75 is from post #74.
For formatted/styled content I use HTML. In order to do this I have to use JavaFX WebView. This is a fully capable browser which has browsing history. When a content is updated many times, this history can accumulate.
There is no explicit method to clear WebView history.
There is a backdoor method: you have to navigate it to 'about:blank'. However this causes the screen to blink.
I introduced a compromising solution: I clear history on the WebView only after a certain amount of content loads. This avoids constant blinking, but from time to time the history will be deleted so it cannot accumulate.
The latest release contains this cautionary measure:
I tried this scalachessgui version running atomkraft vs Bigbang on 3 starting positions using schedule.
After more than 7 hrs of continuous run, the maximum heap size shown in gui is 1362 (started in not more than 500). The maximum memory used by javaw is 3.3 GB so far. It is increasing as time increases which started in not more than 0.6 GB.
So the heap size and the memory used by javaw increases as time increases in a 2-engine, 3-starting positions scheduled long TC match.
I have run some tournaments with Winboard 4.8.0b and these engines:
- Nebiyu Alien
Although, it (seems) is not possible to include UCI engines in variants under WB.
So, I tried scalachessgui. On windows task manager I see the process javaw seldom uses 0-30% of CPU on my core i5. On my AMD Phenom (also 4 physical cores,) this goes to 20-55% (more than 2 cores) and is more constant. I also notice the engines sometimes do not use a full core, maybe because there is a delay of few seconds to initialize the engines. Is this normal behaviour?
I downloaded and compiled many versions of modified Stockfish source code for Atomic chess. I see that most of them lose on time (unless you turn on "never lose on time" option, which seems unfair to other engines that comply with the TC.)
I also tried this:
I can't make it play atomic under any chess gui. Winboard says it does not play the variant (even if UCI_Variant=atomic). On scalachess it only plays standard chess.
On the other hand, Venat has a good time management.
Any help is appreciated.
PS: Is there a link to download Bigbang? I'd like to test it.