I don't use the JNode GUI regularly (does anyone?) but I've noticed recently that I can no longer run in a 512Mb VMWare virtual. With 512Mb, the GUI starts OK, but when I try to launch the GUI console, it grinds for a few seconds ... then nothing. On exiting the GUI, I see OutOfMemoryException stacktraces on the text console. With a larger virtual (e.g. 1024Mb) I don't get this problem.

I suspect that launching the GUI console is triggering a burst of native code compilation, and there is not enough free memory to do the job.

Does anyone have any idea what may have caused the GUI to start using more memory, and how to address this? Maybe native compiler memory use could be reduced by compiling code in smaller chunks?

The JNode documentation claims that JNode can run with 256Mb, and until recently the GUI worked with 512Mb. But not any more ... apparently.

I just did a 'svn up' of my jnode tree, and something dawned while I was waiting for the classlib files to download.

They are big files: a total of 32Mb in their compressed form. Each time we update them we use 32Mb on SourceForge.

Now the SourceForge usage policies for SVN disk space usage are pretty relaxed , but what we are doing (checking large binaries into SVN) is not how SVN was designed to be used. In fact it would probably be regarded as "bad practice" ... though I've seen much worse.

There are multiple aspects to this:

1. At some point the SourceForge staff might notice that our disc usage is sky-rocketing, and they might ask us to stop doing this.
2. Some people (myself included) have internet connections with a cap on the amount of data we can download per month. Others people have slooowwww internet connections. In either case, regular downloads of +30Mb could become an issue.
   

As more commands are added to jnode, its becoming quickly apparent that we need a better place to store strings for the help system outside of the xml and Command class. We should discuss and agree upon a proper way to handle help info before our command classes and xml descriptors become cluttered with strings that we'll only have to pull out at some point anyway for i18n purposes.

I have setup a public git repository that is mirrored off of the sourceforge svn. For anyone that would prefer to use git, you can clone this repository and interface with it until a patchset is ready to commit to mainline jnode.

For those that know how to work git already here are the urls.
Pull : git://repo.or.cz/jnode-mirror.git
Push : git+ssh://@repo.or.cz/srv/git/jnode-mirror.git

There is anonymous access via the 'mob' user, but it only has push access to the 'mob' branch. In order to gain full push access, you have to setup a username on http://repo.or.cz . All you need is a username, and email and a public ssh key. If you put a password on your ssh key, then you will need the password each time you push, if you give it no password, it will push automatically. Let me know your username, and i'll add to the list.

For those not totally familiar, i'll run down the basics of getting setup. I would recommend that for anyone new to git to read the git manual. It has lots of great examples on everything from the basics to more advanced multi-branch merges and bisecting regressions. The manual is at: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html

The 64bit version of JNode is known to be broken for some time.
Besides the runtime problem of the 64bit build it does not build on my local setup and I wonder why it works on the build server. As noted in this issue the asm code contains "bugs". So I wonder if we should deactivate the building of the 64bit version for the moment. What do others think?