Windows 7 and Java 8u101 memory leak

[michael-logan]

Hi,

The JVM that JBrowserDriver is using way too much memory than what it should be. I am passing in arguments to limit memory but it is not helping. Am I doing something wrong?

Here is my JBrowserDriver creation. driver = new JBrowserDriver(Settings.builder() .javaOptions("-XX:+PrintCommandLineFlags", "-Xmx350m", "-Xms250m", "-Xmn200m","-XX:+CreateMinidumpOnCrash") .build());

Here is one of the Processes listed using wmic. C:\Program Files\Java>wmic process where processid=22568 get processid,commandli ne,workingsetsize CommandLine ProcessId WorkingSetSize "C:\Program Files\Java\jre1.8.0_101\bin\java.exe" -classpath C:\Users\myaccount\AppData\Local\Temp\jbd_classpath_6334421468675510827\classpath.jar -Djava.io.tmpdir=C:\Users\jkh45054\AppData\Local\Temp\jbd_tmp_8960966459842955948 -Djava.rmi.server.hostname=127.0.0.1 -XX:+PrintCommandLineFlags -Xmx350m -Xms250m -Xmn200m - XX:NewSize=200m -XX:MaxNewSize=200m -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio= 50 com.machinepublishers.jbrowserdriver.JBrowserDriverServer -121 -122 -123 225 68 1053876224

The last two numbers are ProcessID and WorkingSetSize (respectively). Using this MSFT website as a reference (https://msdn.microsoft.com/en-us/library/aa394372(VS.85).aspx), the memory/WorkingSetSize is 1053876224 bytes, about 1053MB.

It is my understanding that when I set all of this: -Xmx350m -Xms250m -Xmn200m -XX:NewSize=200m -XX:MaxNewSize=200m

..the memory used for the JBrowserDriver jvm really shouldn't go much higher than 350 MB.

I've tried using JProfiler and JConsole to determine if there is a memory leak. I'm not a Java expert but it looks like JProfiler sees the process using 300MB when it's much higher than that looking through Windows Task Manager. Here is an export of the memory profile.

Time [s] Committed size Free size Used size 0 301056000 236426000 64630000 1.9 301056000 225746000 75310000 3.45 301056000 224319000 76737000 4.45 301056000 222559000 78497000 5.48 301056000 208789000 92267000 6.48 301056000 197804000 103252000 7.48 301056000 196530000 104526000 8.48 301056000 193783000 107273000 9.48 301056000 189980000 111076000 10.49 301056000 188716000 112340000 11.49 301056000 182155000 118901000 12.53 301056000 176811000 124245000 13.53 301056000 162470000 138586000 14.53 301056000 155703000 145353000 15.54 301056000 153769000 147287000 16.54 301056000 153767000 147289000 17.54 301056000 147500000 153556000 18.54 301056000 136672000 164384000 19.54 301056000 129293000 171763000 20.54 301056000 127462000 173594000

Thanks in advance.

[michael-logan]

Forgot to include versions.

Java Version: C:\Program Files\Java>java -version java version "1.8.0_101" Java(TM) SE Runtime Environment (build 1.8.0_101-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

Windows Version: Windows 7 6.1 SP1.

[PatrickHuetter]

This may be related to #100

[michael-logan]

I changed my the JBrowserDriver instantiation to this:

JBrowserDriver(Settings.builder() .javaOptions("-XX:+PrintCommandLineFlags", "-Xmx350m", "-Xms250m", "-Xmn200m","-XX:+CreateMinidumpOnCrash", "-XX:+UseG1GC", "-server", "-XX:+AggressiveOpts") .cache(false) .build());

I'm still noticing the high memory usage.

I ran the Eclipse MAT tool, acquired a heap dump.

This is the top suspect in the Leak Report.

Leaks

Problem Suspect 1

56 instances of "int[]", loaded by "" occupy 11,621,560 (46.36%) bytes.

Biggest instances: •int[622592] @ 0xec800000 - 2,490,384 (9.94%) bytes. •int[600000] @ 0xea900000 - 2,400,016 (9.57%) bytes. •int[600000] @ 0xeac00000 - 2,400,016 (9.57%) bytes. •int[270336] @ 0xed200000 - 1,081,360 (4.31%) bytes. •int[225280] @ 0xec700000 - 901,136 (3.60%) bytes. •int[135168] @ 0xebd00000 - 540,688 (2.16%) bytes. •int[135168] @ 0xebe00000 - 540,688 (2.16%) bytes. •int[67584] @ 0xf6a00000 - 270,352 (1.08%) bytes. •int[67584] @ 0xf6a42010 - 270,352 (1.08%) bytes. •int[67584] @ 0xf6a84020 - 270,352 (1.08%) bytes.

[hollingsworthd]

Does it ever actually crash? Sometimes the memory usage reported by the OS can be deceptive. I would tend to trust the Java memory profiling tools more.

[michael-logan]

Hi @hollingsworthd

I did not see the JVMs crash during my testing. My system did go into a state of starvation when the memory usage was high. The only thing I want to rule out is that this memory problem affecting a test.