tisdag 29 januari 2013

The colour Mauve

As briefly mentioned in my previous entry, trying anything more fancy than sending a little data over the network, causes JamVM to wildly crash. I've yet not found the reason for this, it only happens for one particular example (that I've come across) and I can't find any obvious cause for it. It happens right after JamVM has actually ended, and the crash is according to Grim Reaper caused by the process of name "", which milliseconds before was named "jamvm.exe". I'm guessing it has something to do with the C-library trying to close/free something that I've already freed, or something like that. One upside of this problem is that I finally got around to sorting out my issues regarding which C-library I'm using.

JamVM currently uses clib2

So, there, I've said it. Its in black and white. I'm using clib2, and I'm sticking to it. I find that I constantly ask myself about design decisions I've made, and wondering both when, and why I came up with a certain solution. I will not use newlib, for the simple reason that I just wrote that "JamVM currently uses clib2". The JNI libraries (java-net, java-io, etc) should preferably use no C-library, or clib2 when needed. Being libraries, we're not using the C-library startup code. Some libraries however dependes on the reference GNU Classpath implementation, which uses c-library functions. So, in some cases it is more convenient to use a C-library.

I'm not entirely one-hundred percent sure that you can mix different c-libraries in your shared libraries, but I really do not see why not. As long as you don't try to make them talk to each other by interchanging implementation specific handles like sockets or such. But I see no reason why one library calling clib2's printf should interfere with another library calling newlib's printf. Steven Solie has a few good pointers on AmigaOS 4 programming in general, and specifically for networking. He also mentions that clib2 is open-source, and therefore a good choice in terms of debugging options. Which I believe it will prove to be, if I don't stumble upon my problem by accident.

What about that colour?

My previously mentioned doodling with mauve (the test suite for JVM's) continues. Instead of hopelessly banging my head against the keyboard, I thought it wise to continue my mauve runnings. With that I might be able to pinpoint the cause of crash more accurately, instead of wading through hierarchies of Java classes. And that is also one step closer to finishing the bounty.

Note to self

Like I said, my memory fails me. So I thought I'd write down how I run mauve. And it isn't that complicated. I have a mauve installation on my DH1, and it's only a matter of putting it in the classpath to be able to run the "Harness" class. However, putting stuff in the classpath should be as easy as setting an environment variable. But clib2's getenv implementation only has a buffer size of 256 bytes, which means that my scattered long windling classpath doesn't fit. Instead of solving the problem, I hardcoded the classpath. Fugly. But it works. Anyhow, with that in place, starting mauve is as easy as:

jamvm.exe -vm=jamvm.exe Harness java.lang.String

The "java.lang.String" reference is the test to actually run. Not entering this will run all tests. Entering something like java.* will run anything in the "java" package.
Edit: Just remembered that you need to say which VM you want to test. If none is specified, it uses "java", which in my particular case will execute the original JAmiga VM, and not JamVM.

Finding bugs as we speak!

Trying to run mauve, and simultaneously writing this blog entry, I'm actually bumping over a bug of "getenv" in java.lang.VMSystem not being linked correctly. How coincidental. Which concludes my rambling for the night. Off to get that bug!

2 kommentarer:

  1. Newlib is also open source: http://sourceware.org/newlib/

    It would be nice to know why you don't want newlib, which is FYI, the Clib chosen in OS4 development.

    1. Yes, I know newlib is the default clib in OS4, and that it is open-source. However, as I understood Steven Solie's post, it is not possible to easily debug newlib to see what's going on, since the OS4-specific version is not entirely open-sourced. Not that I really want to know any newlib (nor clib2) inner details. It was just convenient to look at the clib2 code, trying to find out what my crash might be due to. By looking at the clib2 code I could actually make changes such that it crashed in other ways, which made me think I was on to something. (And, no, I'm not implying clib2 has bugs. I know the bug is in my code, but seeing where it crashes could more easily tell me where my error might be.)

      I really have no well-substantiated reason for choosing either clib, Things like clib2 lacking SIGKILL define, newlib not having a setjmp implementation, have made me switch back and forth, often making me wonder which I actually use. So the above statement on using clib2 is not to be seen as a recommendation or any critique against newlib. Its only a note, so I know what I'm currently using. (Although, the setjmp stuff is really not anything I want to do myself, the SIGKILL define is a much easier fix.)

      But I might very well switch to newlib, but for the moment I'm sticking with clib2.