Reloc, JAmiga and JamVM

I'm a bit giddy and happy! I have from time to the other been working on JAmiga. Today, I however lost encouragement. With JAmiga.

However, still determined to get Java to Amiga, I persuaded my previous JamVM path. And have made success!

Me and kas1e have previous discussed a strange relocation error which revolved around elf.library shouting out a requester about "Unsupported reloc". Kas1e found quite a lot of information, which I have tried with, to minor avail. Today, I however searched some more, and tried some other things.
The solution was easy: first, do everything kas1e suggest, i.e. remove any TLS stuff. And then, what I found out by chance, you need to remove all "__thread" definitions you might have left in your code. They hsould be within #ifdef HAVE_TLS, but I had one spare lying around. And with that removed, the relocation error disappeared. So, I now have a JamVM crashing! Which is great!

Some background info on the TLS stuff. TLS stands for Thread Local Storage, and is a way for multi threaded programs to store thread local data. Basically, if you want a global object available for your thread, you can't use a static variable, since that will be shared by all threads. Introducing TLS, which relocates the memory dynamically by adding some non-standard elf-stuff. And this is controlled by the __thread keyword. A declaration "int __thread myVar;" is then defined as a thread local storage, and gets some special attention in our elf binary. Apparently, which kas1e found out, GCC from the Amiga adtools is built with TLS support enabled by default, so by just having a __thread keyword will trigger the elf magic -- which elf.library doesn't support.

So, to conclude, keep looking at the JAmiga blog, where I will post a new entry soon of my new JamVM progress.

\o/

@joakim

Happy to see progress on this project

Keep up the good work man!

Go on! We need the java platform.

Quote:
I'm happy you are happy

For the ignorant like me, what is JamVM compared to Jamiga? Is it a library to be used together with Jamiga, or is it another VM engine implementation to replace Jamiga? I didn't find an answer to that in the 2012/2011 blog posts.

@billt

Good question! JamVM is a virtual machine, just like JAmiga. So JamVM replaces JAmiga.

Then there is the class library which need to be adapted to Amiga stuff, such as using bsdsocket.library for network stuff (which I have started on for JAmiga and can re-use), file I/O, and GUI. Basically, with me moving to JamVM, I can focus on Amiga-specific stuff, and not re-implement what has already been done in JamVM.

Another possible way to think of: JamVM/JAmiga is the CPU, and the class library is the OS. Sort of.

Thank you for helping me to understand. I had an idea of what the class library was and what Jamiga itself was, but got confused about the new JamVM talk.

I'm very excited to see you talking Java8. Very nice to see that we're not all hoping for Java5 someday...

Sounds great! Keep it up!

@thread

I think nobody noticed this Jamiga update

@Elwood
Thanks for the heads-up. Seems good.

Although it sounds like limitations of our pthreads implementation need to be documented better (or at all?!?).

\o/ \o/

Thanks, Java is really badly needed!

@ChrisH: Yes, more documentation on the inner details of the pthread implementation would be needed. More specifically how signals are used/handled.
[Pseudo-technical ramblings will follow]

The pthread library for instance lacks pthread_sigmask(). (pthread_sigmask() is supposed to tell us which signal the pthread responds to. The same thing that sigprocmask() does for an entire process). I assume this is due to the way Amiga processes work, compared to how pthreads work. As I understand it, each pthread is in the Amiga implementation mapped to an Amiga Process. Each Amiga Process can be signalled on its own, whereas in the "real" pthread world, i.e. Unix/Linux, a pthread is more a "side track of execution" within its starting process, and not a separate child process. In a pthreaded program, it isn't possible to signal one specific pthread from a user perspective, you rather send the signal to the entire process, which then, through pthread_sigmask, decides if a pthread should handle it.

The reason for not having a pthread_sigmask, might be that we don't have a sigprocmask() call either. Or, we have it in clib2, but not in newlib. Perhaps it just wasn't possible to implement pthread_sigmask(), without knowing exactly how sigprocmask() is implemented, and trying to mimic that behvaiour in newlib. But I'm just guessing.

Anyhow, in JamVM we have a Signal Handler pthread, which should take care of any signals sent to JamVM (i.e. Ctrl-C and such). But in the Amiga implementation, this Signal handler is really just a child process to the main JamVM process, and signals sent to the main process won't reach the Signal Handler -- at least not without some manual signal proxying "magic".

I might have been able to use the pthread implementation, and just made my own pthread_sigmask. But given I needed som signal proxying magic, I need to hook those bits in together with all the other pthread calls. And furthermore, I don't really know what kind of signals the pthread implementation uses, if any.

Blah blah blah blah.
[/Pseudo-technical ramblings end here]

I'm not really one hundred percent sure of all my claims above, but I can at least for certain tell you that I now finally managed to get a "Hello World" running using JamVM. There are a few more details in the JamVM engine to tend to, but I should be able to continue the real work on integrating the Amiga stuff, more specifically networking.