tisdag 28 augusti 2012

JamVM in the making

I have actually received a few donations! I'd like to start by saying thank you, you know who you are!

After a much needed vacation on the French Riviera, I still have a few days off work, and I can put a wee bit more effort into JAmiga/JamVM.

As previously stated I'm focused on JamVM. I've just switched from version 1.5.3 to the latest Git-hub version which have all the OpenJDK stuff and new shiny features. I had to make the switch since, a) its the wise thing to do; why bother with old stuff, and b) I stumbled upon the same JNI function that wasn't implemented in the JAmiga VM (*sigh*).

Things we miss in AmigaOS 4 land which makes porting harder

Automake/autoconf etcetera

Currently I'm moving my 1.5.3 changes to the new JamVM, and trying to sort out the makefiles. Which is tedious, boring and I suck at it. JamVM uses Makefile.am which should be automake'd with tools we don't have for AmigaOS (at least I haven't found them in the usual channels). So I'm doing it by hand. Which isn't that hard. Just boring and time consuming.

This is basically done now -- I'm not entirely happy having the makefiles manually tweaked, but it was the most pragmatic solution for the time being.

Signal stuff

  • sigaction()
  • This function
    allows the calling process to examine and/or specify the action to be associated with a specific signal
    according to the docs.

    This is used in JamVM's initializeSignals() to setup the suspendHandler() function being called when SIGUSR1 is signaled to the thread. I have changed this to instead use IExec->SetExcept(), to call the same function upon receiving SIGUSR1.

  • pthread_sigmask()
  • From the man-page:
    The pthread_sigmask() function shall examine or change (or both) the calling thread's signal mask
    This does the same thing as the function sigprocmask(), but only for one thread. The latter we actually have in clib2's signal.h. We probably don't have it in pthread implementation, since it seems to be using some sort of signaling which AmigaOS don't support by standard.

    But what does it do exactly? It is used in JamVM in the functions enableSuspend() and disableSuspend() (and their variations). For enableSuspend the SIGUSR1 signal is unblocked (SIG_UNBLOCK), and for disableSuspend it is blocked (SIG_BLOCK) -- i.e. when suspend is enabled, the thread will be able to receive the SIGUSR1 signal, and when disabled not. This has impact on the sigaction stuff just mentioned, so my theory is that I will be able to again call IExec->SetExcept() and disable/enable the SIGUSR1 exception catching in enableSuspend and disableSuspend, respectively.

  • sigsuspend()
  • The docs says that
    sigsuspend() replaces the current signal mask with the set of signals pointed to by sigmask and then suspends the thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process

    This is used in the JamVM function suspendLoop(), which is called from enableSuspend() and suspendHandler(). The suspend loop suspends execution until any signal, except SIGUSR1 and SIGTERM (these are removed from the mask using sigdelset prior the call) is sent to the thread, while the JamVM thread flag "suspended" is true (JamVM:s internal structure for its threads). Basically the thread is suspended until signalled not to be.

    I think this could be interchanged with a Wait() on the appropriate signals. If a SIGTERM is sent to the thread, I'm guessing the thread should be terminated... but on the other hand, the signal mask given to sigsuspend has SIGTERM explicitly unset. I'll have to experiment with this, and investigate further.

PThreads

We (AmigaOS 4 users) do actually have the shared library thread.library which implements most of the pthread functionality, however not the pthread_sigmask (as described in the Signal section above), and these functions:

  • pthread_kill()
  • AmigaOS can't "kill" a process. We could ask it (by sending Ctrl-C or something), but that's not the same thing. So for now this a dummy function that does nothing implemented by me.

sched.h

We don't have the sched.h include, and thus not these JamVM needed functions:
  • sched_yield()
  • According to docs, this
    forces the running thread to relinquish the processor until it again becomes the head of its thread list.

    I believe that this can in some way be interchanged with SetTaskPri(FindTask(NULL), 0), which "changes priority of a task [and] a reschedule is performed", where the important part being the rescheduling. I have heard that we really can't trigger an explicit rescheduling in AmigaOS (with the pre-emptive multitasking, I assume), so this is the closest we'll get.

Next actions

I will be implementing and testing my theories above. In a future blog I will report more thoroughly on my chosen methods to implement the missing functionality found. Hopefully this can be of use for other porters in Amiga land.

Again, I wish to thank for the donations. If anyone else wan't to donate, the button is at your right. I have been thinking of starting a bounty, but I currently don't know what to expect from my efforts. But I want you all to know that I won't give up until I can run Eclipse and other java stuff on my Amiga, perhaps not mainly on my AmigaONE XE, but more likely (time wise) on my X1000 (which I hope will come before the end of the year).

3 kommentarer:

  1. Kör hårt Jocke så vi får lite jamiga :-) Blir en liten donation från mig inom kort.

    SvaraRadera
  2. @Jaokim

    Is there reassons why you didn't use cross-compiler for avoid all the problems with maketools ? I for myself use win/cygwin for that, and just copy final binary over the network on aos4 to make a final tests. With cross-compilers everything works kind of the same, just the range of tools are big, speed of compiling very fast and all what you need its just provide one/two flags to make tools , to make it known that its for amiga-pcc build.

    SvaraRadera
    Svar
    1. The only reason is laziness. I currently have no cross-compiler environment setup, and the last time I created one, I remember it being utterly boring to do. I've switched computer since then, and now have a Mac which I'm really not friends with (I could of course use my Windows VMWare). But, yeah, no, lazy.

      Furthermore I want to develop on the Amiga, in Cubic IDE. I guess I could setup a distributed thingie, but then there's the setup again.

      Radera