fredag 30 oktober 2015

Mind sweeped

Today I'm playing a game of Minesweep. I never really got the hang of that game, but I'm hoping that one day we might be able play some more intriguing games. On the Amiga, using JAmiga!

So, yes, I've finally managed to get the existing AWT functionality working! Much of this is not my code, but created like ten years ago (!) by the original JAmiga developer, Peter Werno. There were a few issues that kept it from running using the new JamVM, and otherwise updated code, but I've finally got the original demos to work.

Volatile

There were a few synchronization issues, which didn't happen before. One minor, easy quick fix, was to add the word "transient", I mean "volatile" to the running flag of the window listener thread. This is how it works: the main Java thread wants to open a window. Then a new "window listener" thread is started, which actually opens the window. In order for the main thread to know when the window has been opened, it polls and loops for a flag to be set to true by the window listener thread.

// main thread waits for(ever) for running to be true 
MainThread::startGUI() {
   new WindowListenerThread().openWindow();
   while(running == false) {
     // do nothing
   }
}

...
// window listener notifies "object" when opened
WindowListenerThread::openWindow() {
   window.open();
   running = true;
}

In the old code, this was a normal boolean flag, not marked with special word "volatile". "Volatile" means that the variable can be changed by more than one thread, and, if you don't mark it that way, the JVM can make clever assumptions if it thinks that this variable isn't going to change. This means that if the main thread keeps looping and looking at it, the flag will, most of the times, be false. Even though it will take like no time to open that window, the loop will probably have made quite a few loops, and thus, in order to optimize and get a snappier Java experience, instead of actually fetching the value of the flag each time, the JVM assumes it is always false. And this is all according to the specifications and the way Java works. Previously the JVM didn't make this clever assumption (or if it was the old Java compiler that didn't make them).

I also added some synchronization around these parts, so instead of a constant loop, the loop is synchronized, meaning it checks the flag, and then waits to be notified from the window listener thread, and only then checks the flag.

// main thread waits for "object" to be notified
MainThread::startGUI() {
   new WindowListenerThread().openWindow();
   while(running == false) {
      object.wait();
   }
}

...

// window listener notifies "object" when opened
WindowListenerThread::openWindow() {
   window.open();
   running = true;
   object.notify();
}

This synchronization (the notify() and wait() methods) are part of the Java standard, and used all over the place. And when looking at it for the AWT stuff, I found some things in my implementation that were not quite working. I've known that the synchronization and signalling parts have had some glitches, so that signals sometimes aren't received as they should, leading the JVM to a halt. I knew I was taking a few shortcuts before, but now I'm pretty confident it works according to specification, since I this time actually carefully read the specifications... And, I've also been able to verify that it seems to work better, since I actually now use JAmiga to compile Java code when I'm developing JAmiga on my X1000. We kind of almost have a Java implementation so we can build Java ourselves on the Amiga!
Edited: of course I meant volatile, not transient

So, all the graphics is done now?

Now, this doens't mean that the graphics are all done, and that we can download NetBeans and run it. There's still quite a few unimplemented methods in the JAmiga specific AWT-packages. But it's getting there!

onsdag 7 oktober 2015

Software Freedom Day!

Saturday the 19th september I travelled to Uppsala, on Software Freedom Day, where Uppsala Linux User Group had an event. I was invited to talk about Jamiga: Java on Amiga.

You can see it below. It's in Swedish, but there are subtitles in English.

A big thanks to ULUG and Josef Andersson for inviting me, and special kudos to Joel Edberg for filming and doing the editing!

Besides me babbling about JAmiga, there were also talks on how open source software is used at SVT (the Swedish public service television), a talk about Gnome and a series of interviews on how open source products are used at various Swedish startups. Very interesting stuff indeed! Also, not to forget the beer and wine at a local pub afterwards. Nice to meet some Amiga folks IRL.

lördag 21 mars 2015

Interesting platform, but missing implementation here

In my last blog entry (which was ages ago, I know!), I bragged about my OpenJDK efforts. Or bragged is perhaps not the word, but, I mentioned it. I sadly haven't had time to do much about OpenJDK lately, or my Amiga for that matter. But now things at work, and in my new house (yay!) are starting to go back to normal, giving me some time to tinker with JAmiga and OpenJDK.

And this is what I'm currently greeted with:

"Interesting platform, but missing implementation here". Ha! If they only knew...

Interesting platform

My AmigaOne X1000 is currently abroad for a physical check-up, but meanwhile I've been busy with my Ubuntu laptop. I managed to compile a working adtools setup with the help of salass00 guide excellent guida at os4coding.net. It wasn't that hard to do, if you just follow the instructions. However, the GCC version currently in trunk cannot be built (March 2015), so you should instead use the 4.9.x tag. At step 5, "Build and install gcc", you have to alter "gcc-build/Makefile" which points to "gcc-trunk", and "trunk", and change this to "gcc-4.9.x" and "4.9.x", respectively. And you must have checked out the 4.9.x branch from SVN.

With the adtools cross-compiler suite up and running, I've begun my porting efforts. I've done this before, both trying the IcedTea OpenJDK project, and vanilla OpenJDK 7 and 8. My current focus is however on OpenJDK 9, without any iced tea -- just regular coffee (currently mostly decaf though, or perhaps just disgusting brown water). OpenJDK isn't released or done yet. If I understand the OpenJDK procedures correctly, each big version (i.e. 9), has a number of sub projects working on different aspects of OpenJDK. The project "Jigsaw" is my aim at the moment. I've talked about Jigsaw previously, referring to it as an onion, in short it aims to modularise OpenJDK. My hope is that I'll initially will get away with just porting the "java base" stuff, and then iteratively proceeding with the rest of Java. For the GNU classpath this is already possible, with its different libraries for javalang, javanet, and so on. OpenJDK in essence only has one big java-library. It is possible to disable stuff like AWT and such in OpenJDK, but in order to skip f.i. the java-net stuff, I would have to write dummy functions in order to make it compile. But with Jigsaw, the idea is to be able to disable entire modules, where java-net is one.

Missing implementation

Now, going back to the error message above. I know the reason for it, and I sort of knows what's needed. And its quite a lot. The error relates to "hotspot", which is OpenJDK's virtual machine -- where I want to use "JamVM". So, I can either try to implement support for hotspot, or try and adapt the build process to skip hotspot. It is possible to build OpenJDK without hotspot, if you use IcedTea. But IcedTea currently only supports OpenJDK 8. And, IcedTea needs some adaptation to support AmigaOS as well. So I think I'm doing the right thing going for OpenJDK 9. Hopefully.