RoboRIO won't let us use more than 50mb of RAM?

[Jared Russell]

Sounds like Java isn't configured to use a very large heap by default. There should be a way to pass an -Xmx option to the JVM, but I'm not sure where exactly to put it in the current RoboRIO setup.

[Jared]

I ran into this today too, and I originally thought exactly what Jared thought, that the JVM wasn't configured to let the java program use very much memory, but the error message states that "there is not enough memory for the Java Runtime Environment to continue".

I checked the error log, which confirmed that the system ran out of memory, not that the heap size was too small.

Unlike magnets, I got down to 46Mb free on the Driver Station before a crash occured. Interestingly, after the crash, the Driver Station window became maximized, which let me see cool debugging information about the Driver Station.

The error logs records the output of /proc/meminfo. Perhaps somebody with more linux experience could explain what's happening.

---------------  S Y S T E M  ---------------

OS:Linux
uname:Linux 3.2.35-rt52-2.0.0f0 #1 SMP PREEMPT RT Tue Jun 3 20:49:19 CDT 2014 armv7l
libc:glibc 2.17 NPTL 2.17 
rlimit: STACK 256k, CORE 2048k, NPROC 1852, NOFILE 4096, AS infinity
load average:2.34 0.80 0.28

/proc/meminfo:
MemTotal:         237120 kB
MemFree:           46784 kB
Buffers:               0 kB
Cached:            68316 kB
SwapCached:            0 kB
Active:            97544 kB
Inactive:          34200 kB
Active(anon):      85224 kB
Inactive(anon):     1768 kB
Active(file):      12320 kB
Inactive(file):    32432 kB
Unevictable:       28304 kB
Mlocked:           28356 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         91820 kB
Mapped:            46288 kB
Shmem:              2432 kB
Slab:              20768 kB
SReclaimable:       9904 kB
SUnreclaim:        10864 kB
KernelStack:        2120 kB
PageTables:         1372 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      187324 kB
Committed_AS:     173552 kB
VmallocTotal:     516096 kB
VmallocUsed:       19928 kB
VmallocChunk:     491452 kB

The problem isn't a too small heap size, but that the JVM isn't able to use 46mb of RAM.

[Ether]

Originally Posted by Jared

not that the stack size was too small

Jared said heap, not stack. Memory is allocated from the heap.

[edit] I see you corrected that...

[Joe Ross]

I can confirm that increasing the heap with -Xmx does not allow the user to allocate more memory. I did confirm that setting the maximum heap to a smaller value causes a different error

Unhandled exception: java.lang.OutOfMemoryError: Java heap space at [org.usfirst.frc.team8330.robot.Robot.disabledPeriodic(Robot.java:45), edu.wpi.first.wpilibj.IterativeRobot.startCompetition(IterativeRobot.java:102), edu.wpi.first.wpilibj.RobotBase.main(RobotBase.java:234)]

[wireties]

Originally Posted by Ether

Jared said heap, not stack. Memory is allocated from the heap.

[edit] I see you corrected that...

Note that you do not have to worry much about stacks space for user programs in Linux. Your threads have huge allocated virtual stack spaces (like 2MB) and the required physical pages for the stack are committed as needed. So, in effect, your stacks start at 4K (the size of one page) and grow into the size required (within reason).

HTH

[Ben Wolsieffer]

You should be able to add arguments be editing "WPILIB_DIR/java/current/ant/robotCommand". I'm pretty sure this file is uploaded every time code is deployed. Also, keep in mind that this file will be overwritten when WPILib is updated.