TexasHoldem solver can't solve for a Flop only scenario

[dev-ns8]

My JVM is running out of memory when solving for a scenario that only provides community flop cards, no Turn or River card.

Steps to Reproduce:

Settings used above.

Ranges I used for IP and OOP:

NateRange-IP.txt NateRange-OOP.txt

I did some digging with my Debugger, and it appears that either

A) The call to ParallelCfrPlusSolver.setTrainable(GameTreeNode node) is entering into an infinite recursive call state

or

B) The same call from above is not handling memory management between threads properly or creating two many threads.

Stack Trace from GUI application:

java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedConstructorAccessor2.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:173) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:176) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:176) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:180) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:176) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:176) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:180) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:176) at icybee.solver.solver.ParallelCfrPlusSolver.setTrainable(ParallelCfrPlusSolver.java:176) at icybee.solver.solver.ParallelCfrPlusSolver.train(ParallelCfrPlusSolver.java:206) at icybee.solver.gui.SolverGui.solve(SolverGui.java:281) at icybee.solver.gui.SolverGui.access$200(SolverGui.java:23) at icybee.solver.gui.SolverGui$3$1.run(SolverGui.java:328) Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded at icybee.solver.trainable.DiscountedCfrTrainable.<init>(DiscountedCfrTrainable.java:78) ... 16 more

[bupticybee]

This problem is caused by insufficient optimization and it's a known problem. Java version tends to have this problem. The problem is not caused by infinite recursive.

I'm currently working aggressively on c++ version to solve this kind of problems. Now c++ version is 3times faster and takes only less than 25% memory of java version. If you are a programmer, you can try the c++ version(without gui now) https://github.com/bupticybee/TexasSolver/tree/speedup

However if you are not a programmer, I suggest:

1. upgrade you computer memory, use at least 32G or larger memory
2. use smaller range, remove donk size, don't add allin, use only one IP size in your setting.
3. wait until c++ version to offically release

[dev-ns8]

Hmm, Interesting finds. Unfortunate to hear the GUI version can't really be used fully. Have you brainstormed / Researched any potential refactors/workarounds that would mitigate this issue and allow it to solve for a flop-only scenario with the current memory limitations? Just curious if maybe there is any conceivable scenario where I could fork this and refactor it to make it usable. This is a really cool project, I would love to see it work in it's entirety

[bupticybee]

Hmm, Interesting finds. Unfortunate to hear the GUI version can't really be used fully. Have you brainstormed / Researched any potential refactors/workarounds that would mitigate this issue and allow it to solve for a flop-only scenario with the current memory limitations? Just curious if maybe there is any conceivable scenario where I could fork this and refactor it to make it usable. This is a really cool project, I would love to see it work in it's entirety

Of course yes. Java version is optimized be used in turn & river. And flop optimization actually is the main goal of the next release. As mentioned above, I'm working on a c++ version (optimized to be used in flop), this version should solve all the problem you mentioned. I modify the data structure, and moidfy a lot of the algorithm and implement some paper's acceleration methods to make it a lot faster than the java version. Eventually in my plan c++ version will replace java version (someday in the very near future) and of course it will also have a gui.

And if you want to really dig into the algorithm you might want to check https://github.com/bupticybee/TexasSolver/tree/speedup

If you really want to modify the java code you might want to look some memory saving and speeding up tricks in the c++ version and try port it to java: https://github.com/bupticybee/TexasSolver/commit/fcb5dc725bdc53e7cfb9bd66ca7ed33584e5cc2c https://github.com/bupticybee/TexasSolver/commit/89e644751883cd6b91fdfb5becb3ebed5ae23569 https://github.com/bupticybee/TexasSolver/commit/556b5240711f6316b136ef68c14c4e9e02e35f2f https://github.com/bupticybee/TexasSolver/commit/9701e59ec23bd0d5398bc4edac081e598f011315 https://github.com/bupticybee/TexasSolver/commit/1d5e5b235f9ce661d2f0667b89ba2753a9140bcd https://github.com/bupticybee/TexasSolver/commit/910f520ed83361e7f0165e2112072f8f65103e69

these tricks should be able to accelerate the java code at least 100% and save 60% or more memory. However since c++ is the next step to go, I'm not planning to implement these tricks in java version. If you are that interested you can try.

[dev-ns8]

Interesting. Thanks for the leads, I will definitely look into the optimization tips . I have beginner knowledge of C++ and love the idea of having an open sourced Java based Solver. Can you point me more specifically to this known JVM issue?

[bupticybee]

Interesting. Thanks for the leads, I will definitely look into the optimization tips . I have beginner knowledge of C++ and love the idea of having an open sourced Java based Solver. Can you point me more specifically to this known JVM issue?

There are actually a lot of them.

• JVM run bytecodes, which is less efficient than c++
• Lack of control of memory
• Data structure
• GC ...

If you are really interested, read http://www.best-of-robotics.org/pages/publications/gherardi12java.pdf

[bupticybee]

Closing because this issue is inactive for 3 weeks, reopen if necessary.