Having installed a simple application and run this sucessfully on the Yun using jamvm, I ten uploaded my project and ran it:
root@SPlatten:/opt# java -jar DSgateway.jar
Exception in thread "main" java.lang.OutOfMemoryError
at java.io.InputStreamReader.read(InputStreamReader.java:379)
at java.io.BufferedReader.fill(BufferedReader.java:370)
at java.io.BufferedReader.readLine(BufferedReader.java:469)
at gnu.java.util.jar.JarUtils.read_attributes(JarUtils.java:194)
at gnu.java.util.jar.JarUtils.readMainSection(JarUtils.java:140)
at gnu.java.util.jar.JarUtils.readMFManifest(JarUtils.java:101)
at java.util.jar.Manifest.read(Manifest.java:162)
at java.util.jar.Manifest.<init>(Manifest.java:89)
at java.util.jar.JarFile.readManifest(JarFile.java:303)
at java.util.jar.JarFile.<init>(JarFile.java:268)
at gnu.java.net.protocol.jar.Connection$JarFileCache.get(Connection.java:99)
at gnu.java.net.protocol.jar.Connection.connect(Connection.java:141)
at gnu.java.net.protocol.jar.Connection.getJarFile(Connection.java:170)
at gnu.java.net.loader.JarURLLoader.initialize(JarURLLoader.java:85)
at gnu.java.net.loader.JarURLLoader.<init>(JarURLLoader.java:76)
at gnu.java.net.loader.JarURLLoader.initialize(JarURLLoader.java:143)
at gnu.java.net.loader.JarURLLoader.<init>(JarURLLoader.java:76)
at java.net.URLClassLoader.addURLImpl(URLClassLoader.java:387)
at java.net.URLClassLoader.addURLs(URLClassLoader.java:418)
at java.net.URLClassLoader.<init>(URLClassLoader.java:217)
at java.lang.ClassLoader$1.<init>(ClassLoader.java:1099)
at java.lang.ClassLoader.createSystemClassLoader(ClassLoader.java:1099)
at java.lang.ClassLoader.defaultGetSystemClassLoader(ClassLoader.java:1084)
at java.lang.VMClassLoader.getSystemClassLoader(VMClassLoader.java:296)
at java.lang.ClassLoader$StaticData.<clinit>(ClassLoader.java:154)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:799)
I'm not aware that I have any large memory requirements, the classes I've written don't have any large static arrays, it is likely to be really out of memory?
Trying to turn on swap space is useless, because by default jamvm claims only 1MB for its maximum heap size (see the -X option for details), while (normally) Linux doesn't hit its swap space with that small amount of memory; that bus error has another cause (I run jamvm with 40MB heap space fine).
kind regards,
Jos
ps. it -Xmx, not -Xms (that's the stack size limit)
According to the jamvm help:
-Xms is the initial size of the heap,
-Xmx, is the maxium size of the heap.
-Xss, is the stack size
Unrecognised command line option: -h
Usage: java [-options] class [arg1 arg2 ...]
(to run a class file)
or java [-options] -jar jarfile [arg1 arg2 ...]
(to run a standalone jar file)
where options include:
-client compatibility (ignored)
-server compatibility (ignored)
-cp <jar/zip files and directories separated by :>
-classpath <jar/zip files and directories separated by :>
locations where to find application classes
-D<name>=<value> set a system property
-verbose[:class|gc|jni]
:class print out information about class loading, etc.
:gc print out results of garbage collection
:jni print out native method dynamic resolution
-version print out version number and copyright information
-showversion show version number and copyright and continue
-fullversion show jpackage-compatible version number and exit
-? -help print out this message
-X show help on non-standard options
root@SPlatten:/opt# java -X
-Xbootclasspath:<jar/zip files and directories separated by :>
locations where to find the system classes
-Xbootclasspath/a:<jar/zip files and directories separated by :>
locations are appended to the bootstrap class path
-Xbootclasspath/p:<jar/zip files and directories separated by :>
locations are prepended to the bootstrap class path
-Xbootclasspath/c:<jar/zip files and directories separated by :>
locations where to find Classpath's classes
-Xbootclasspath/v:<jar/zip files and directories separated by :>
locations where to find JamVM's classes
-Xasyncgc turn on asynchronous garbage collection
-Xcompactalways always compact the heap when garbage-collecting
-Xnocompact turn off heap-compaction
-Xms<size> set the initial size of the heap
(default = MAX(physical memory/64, 1M))
-Xmx<size> set the maximum size of the heap
(default = MIN(physical memory/4, 1024M))
-Xss<size> set the Java stack size for each thread (default = 256K)
size may be followed by K,k or M,m (e.g. 2M)
Ok, don't use the -Xmx flag to make the heap larger then, but your Yun won't hit the swap space unless you fill it up with other memory consuming processes ... (-Xmx32M makes your heap large enough for substantial Java programs while it still doesn't need that (slow) swap space).
SPlatten: @sonnyyu, followed the link, not really sure what it is and how it can help?
If PC has not enough memory then we upgrade it by add more memory, we never/hardly increase swap. AR9331, the heart of Yun has max RAM 64MB and no room to grow. Its big cousin which support more RAM, We could change board which has more RAM.
Robert, author of jamvm has been helping me to resolve some of the issues I've been experiencing. I have tested the same project on a Beaglebone Black running openJDK and it works fine. Unfortunately it won't run on jamvm on the Yun. Robert was saying that the Virtual Machine used by jamvm on the Yun is GNU and no longer supported. However openJDK uses IcedTea.
At the moment I'm a bit screwed as I need a java virtual machine capable of running my project.