Older blog entries for audriusa (starting at number 11)

13 Jun 2009 (updated 15 Jun 2009 at 19:04 UTC) »

Have recently finished the practical part of "Advanced Operating Systems" in ETH. More a hobby - like activity, lots of time have passed since I have been a student the last time. Step by step, over half a year each student have implemented a tiny working system on the top of L4 microkernel for NSLU2. It even has its own ELF loader. At times I started to think that it may be interesting to put a java virtual machine on the top of L4 as the first (root) task. In L4, the root task can do many things that the ordinary program cannot do. Most interesting it can map and remap pages, so we can have chunks of memory appearing from nowhere in virtual space. Or extrafast moving by remapping (while it may be difficult to see as these pages are 4 kb at least and must be aligned). If some other task (normal L4 executable) wants to do such things it can only do via requesting root task to do this. Context switches and so on.

L4 also has quite pretty threads, and each thread can have individual mappings. For instance, they can have each its own stack exactly in the same place of the address space. But in general it is a very tiny kernel; apart maps, threads and interprocess pipes there is almost nothing more there. This is not because of incompleteness, it is more a kind of concept.

However drivers seems being a biggest problem, even if we restrict interface to the network alone. It was a not so bad network driver for the NSLU2 chipset in the provided package, but the problem is that this hacker-loved slug seems no longer in production. Some German groups try to run existing Linux drivers under L4 in some emulation mode.

Interesting to see, the CPU cache matters a lot in java, also. If we have something like buffer[a] = buffer[0] for a really long buffer and various different a, it may be up till twice slower then buffer[a] = buffer[a-1]. This is something important to note. There are C guys ready to crucify everyone that says java can be tried in high performance computing, using they own knowledge about caches.

Some days ago I have tried my Dell Latitude D830 together with Fedora 10 Cambridge, and was really surprised how far have everything advanced since relatively hard times of getting Fedora 8 Werewolf working. There is really reasonable difference now when Cambridge seems having absolutely no problems with the laptop - not only wireless and suspend work but even the monitor video output switches flawlessly where needed during presentation. Fedora community have done a great thing once again!

So, the following configuration is supported by Cambridge no worse than Mac hardware by Mac OS: Intel Core 2 Duo T7800 with GMA X3100, Dell Wireless 1490 802.11a/g, 1680 x 1050 resolution.

24 May 2008 (updated 24 May 2008 at 15:46 UTC) »
Thoughts from JavaONE
This year I first time visited JavaONE in San Francisco, hopefully not the last.

It is really very good conference with a lot of things happening. I was impressed on talks about Glassfish, Spring and many other FOSS related things. I was less impressed noticing that some hands - on labs expect a single particular OS running on your laptop as some self - evident thing. But I believe that this is because the software under demonstration is so new and the gaps will be closed in the future. Also, the current status of the PhoneME seems a kind of mess: from one side, it "runs everywhere and is very easy to port", from the other side it is not obvious even where to download the official port for ARM processor. Likely there is a reason why many people with mobile devices seem running JamVM+GNU Classpath and stay happy.

We have also seen Dalibor who is now working for Sun. It was an interesting experience to have a conversation with him in a place so far from Zurich where we both have spent so many time in the past.

"GNU hackers flatten Sun's professionals with they java.util.BitSet" - sounds not so bad. Some simple comparisons show that our BitSet runs roughly 24 % times faster than Sun's 1.6.0 implementation. Sun takes back on HashSet, however - this one is slower in GNU Classpath, more or less by the same percent. See the posted Advogato article for details.

I am not sure why our BitSet is faster. Deciding from OpenJDK, both implementation use the array of long's to keep the data. From the other side, the overall code is so different that it is difficult to say, who makes the benefit. The history of GNU BitSet spans over seven years (1998 - 2005) and have seen many contributions. The main authors of this class seem Jochen Hoenicke, Tom Tromey and Eric Blake.

I have checked near all java.util classes but the remaining differences seem for me too small to be considered seriously. I am, however, happy to discover that GNU Classpath is very far indeed from being universally worse than OpenJDK at any single line of code. The detailed 'class versus class' check may discover more interesting differences.

Today I started to do something that I am sure it was needed long time ago already. I took the latest GNU Classpath distribution and started to rip some selected interesting package, java.util, apart. One time I will check properly if it is worse or maybe same or maybe better the one we have got from Sun.

GNU Classpath has been written over long time by numerous developers. In addition, it usually runs with the different java virtual machine than the Sun's code. In that way, no honest comparison is possible between any units that are smaller than all jre + all rtl together.

So, that I have done so far I moved the chosen set of GNU Classpath java.util classes into some transient package where they do not conflict with java.util from Sun. Some code editing was needed to build everything but in general it was trivial to build it that way. Now I have the two java.util's on the same virtual machine! It is time to try some performance comparison. We will just write some simple tests for that. Stay tuned.

FOSDEM 2008
Unlike two years ago, this time I have been a "completely different person" in FOSDEM: arrived by plane, used hotel and also brought two young developers I supervise - to demonstrate them how the FOSS looks like from the closer distance. Even a very simple things are impressive for some people: that the conference was organized by the university, that it was really large, that the level of the projects is indeed very high and that nobody does not even think to talk about things like cracking iPhones. It is important to resist various FUD in time. This goal seems reached and I am satisfied with the result.
Apart java talks, one of the most interesting things I have seen might be OpenSolaris. While I needed to stuff an extra hard drive into my box just to install it properly, I did - runs fine, scaring the older staff from the oil industry like a resurected ghost: Solaris??? Its dead! It is over! Well, there are many other interesting things - the summarized report was 16 pages long. Really a nice weekend.
... this is to ask a few minutes of your time to help my research group...

Today I haver received one more questionnaire related to the "FOSS research". It is already a second one this month, and as much as I remember already a fifth I have completed. Some wave of "fundamental scientific analysis" on FOSS seems spreading around the world. Why are you programming this? Are the companies involved? Do you feel the owner of your project under GPL? Would you program if you know it would be illegal? How the important development decisions are made inside your project?

Somewhat it was considerably less attention even a year ago. While FOSS developers likely have never be treated as a bunch of hackers about that there is "nothing interesting to know", it seems an achievement that more people accept FOSS development as a kind of process which needs detailed study and understanding. Something similar to the mountain formation.

Hope they will not fish out any weak places in our movement with these surveys. If they potentially could, it is likely time to think about the shared policies how to answer...

9 Nov 2007 (updated 14 Nov 2007 at 19:00 UTC) »

libgcj in C-based parallel clusters?

Today I was setting the MPI cluster. A tcl-based expect script is required to arrange the MPI connections. Expect was not present on my SuSe machines by default, but I found it between optional packages. Still, all that this default installation was doing is it was silently hanging with MPI setup script. Hence our team needed to build the more recent expect distribution from the source, remembering all fun of --configure--with (the default ./configure does not find the tcl configuration script on 64 bit platforms).

We had problems with firewalls, also. MPI uses same approach as the old CORBA implementations did: just opens multiple random ports wherever they like. However our 'cluster' is not just for distributed computing - people use them heavily for various purposes, connecting via ssh -X. Finally we decided to use combined mac + ip address filtering with iptables.

Ok, the MPI cluster is now running with full Fortran and C++ support. Likely we will enjoy it, but how to build a bridge back to java? Some of our java programs already have complex GUIs, others are heavily JSP-based - the prospect to rewrite this stuff in C - even parallel C - does not seem attractive. I is now nice to have a java runtime library that connects with C easily, without the need to load and start all java virtual machine as a separate process. All we need is java-style serialization, RMI and maybe RMI-IIOP. It is far less than GNU Classpath is capable to do. Likely it makes a lot of sense to try our old staying-alive libgcj here ...

Yesterday I was setting up CORBA via SSL on JacORB and was surprised that despite seemingly good support this task can still be such a headache. We needed the single-port SSL connection that would be secure from beginning (no naming service on an unprotected port) and would not require to pass the lenghty server IOR address via some other channel (the example in JacORB uses a shared file system to pass the IOR and in addition is broken in 2.3.0 release). The corbaloc:ssliop address notation still seemed not supported, so the only hack around we were able to find was to patch the pre-generated IOR for the local host with the separately given IP address and SSL port. Thank goodness JacORB has the internal undocumented routines to parse and modify IOR's, same as the GNU Classpath does. It is really sad that these IOR manipulation routines are in the private space and may change dramatically between releases. Likely having the useable naming service via SSL connection without passing of the 2K IOR that must be known in advance should be very easy and trivial to do.

I know that people more talk about the web services in these days, but our "messages" are many megabytes in size even when they are binary. It is really great that I have a lot of things to remember from the GNU Classpath CORBA project - otherwise it would likely take days to figure everything out. Indeed, the company managers should look for the Free software developers to do they tasks ...

2 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!