Older blog entries for tan (starting at number 8)

Some Good ol' Benchmarking

Tom Tromey just posted on the gcj mailing-list a link to an interesting Java to C benchmark. It's actually a followup to a previous one, to which other Java runtimes have been added.

Basically, that's a comparison of micro-benchmarks between some "classical" (JITed) Java environments, compiled ones (GCJ and JET) and the equivalent C programs.

As I understand it, the results show that comparing Java to C performance-wise does not have much meaning. Depending on the task at hand, Java timings are in a +30% to -30% interval with respect to C performances.

If such a worn-out subject interest you, I would recommend reading the classical "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl". I suppose some shootout results would be a nice read too (their FAQ is a must-read). Oh, look, there's even a detailed wikipedia page about languages comparison.

My Dream Language

I'm actually more interested, as stated in my previous post, by what may or may not help a library to gain acceptance. Execution time of "scripted" or VM-based languages is a typical FUD; runtime memory usage is more of a concern (especially when compiling to native). Linking to other languages is probably what matters more, actually. That's the only argument I could imagine in favor of C.

For application writing, it's clear to me that using a garbare-collected, multi-paradigms language (especially with a rich functional expressiveness) is a no-brainer, from a productivity and maintainability point of view. But for maximum reuse, what's needed is multiple, clearly-defined libraries. For which I'm afraid no perfect implementation environment exists.

I would love the above high-level characteristics (which rules out C, C++ and to a lesser extend Java), easy linking with existing C libraries (that one is OK with most languages), and natural, efficient reuse from other popular languages and environments (Java, C#, C++, Python and PHP easily come to mind).

Now I'm getting Boring

Ahh, the good old Graal of universal, transparent componentry... Perhaps some agnostic glue is needed... CORBA failed us, Web Services are overkill to fit together applicative components... Wouldn't D-BUS be more interesting in this case (but calls granularity should be properly thought out)?

So which paradigm/language/framework could provide us with some kind of universal "software mashup"? Any opinion (or better, bibliography) on this matter, which I feel is quite the opposite of a language comparison (would you fear the trolling)? Am I getting boring? :-)

If You're still with me

In (not so) other news, I noticed a revised edition of the Dragon Book was available. Among the new topics are better code analyze and optimization, JIT compiling, garbage collecting... I need this (pricy) beast!

Hi all,

I've been toying with the idea of implementing some networking protocol stuff for some time now. That was actually one of my motivations for working with native compilation of Java code to Win32 platform, but that proved disappointing. J2SE has a big, tightly coupled runtime / libraries set, and it seems difficult to produce lean and mean binaries out of it (that's my current experience anyway).

In the mean time since my last post on this matter, more than a year and a half ago, I gradually understood Java was not the weapon of choice for small, nicely desktop integrated tools (please disprove me!). It can be done, but I feel it goes against Java basic design decisions, which mean you're then kind of fighting against your platform. Productivity killer. Baaad.

So I'm kind of confused. What I want to do is some networking code. I will develop it as one or some libraries, and build some apps above it, since I feel there's nothing sadder that a great idea intermixed with some application code (at the end of the day, if someone want to reuse it, he'll spend a hell of a time figuring out which parts he actually needs).

The apps will be coded in a nice, productive language (I lean toward Python, or perhaps something more exotic to me like Factor).

The libraries would be coded under an LGPL or BSD license, for best reuse; but which language would you choose?

• I can use some nice, high-level language; but I do not want to restrict reuse opportunities with the age-old "how sad this is coded in X when I'm coding in Y, I'll have to port/rewrite it".
• I could code it using C, and provide bindings for some higher-level languages (which, I suppose, excludes C++ from the loop, as it's more difficult to bind to anything else than C). But as good as this is from a reuse point of view, and even if I'm a capable C coder, that is definitively a productivity killer and a sad jump in the past (no offence intended to enthusiast C coders, but I'm kind of accustomed to OOP, generics and automatic memory management now).

There's no win/win solution here, I'm afraid. So I'd like to get your opinion on this matter of maximum reuse / acceptation of a library, at the cost of language expressiveness.

On a related note: should I code in C, I'd prefer to use a portable foundation library since I'd like to target at least the linux and Win32 platform. It would be that less low-level details to bother with. It seems like the Apache Portable Runtime is a good candidate. Does it provide an NIO/select-like abstraction (event-driven networking)? Are there other similar platform-abstraction toolkits you could hint me to?

Regards.

rmathew proposed a patch following our discussion. It solved my SWT crashing issue and made its way to gcc trunk. Helping fixing this bug was a rather enjoyable experience, and remembered me how much I liked assembly language and low-level issues.

Anyway, a canonical SWT "HelloWorld" now works properly, as well as the tray variation I've initially chosen as a simple example.

Now that this code compiles and runs properly, I'm focusing on its packaging. NSIS seems like an obvious choice, but I'd first like to "clean" my compiled app.

Indeed, I'm kind of surprised by its size; this basic example weights 52MB. Stripping it and compressing it with the excellent UPX leads to a 4MB executable, but it still does feel like an awful lot. Perhaps some code analysis could remove unneeded parts? I'll have to goggle about this.

Following rmathew's advice, I looked for a cl.exe (the Win32 compiler) flag equivalent to gcj's -fno-omit-frame-pointer. Which actually exists.

I then had a fun little time disassembling the resulting library to ensure this flag had the desired effect (I used REC for this purpose, a nice but sadly not open-sourced software).

Well, it did, but this did not solve my crashing issues. At this point, it seems like I really should study and trace gcj's stack unwinding code...

The gcj mailing-list (and, more specifically, Ranjit Mathew, the author of the scripts I used to build a Win32 gcj) helped me; I'm not sure I liked the answer, though...

So I need to build an SWT DLL using a specific flag (-fno-omit-frame-pointer). Otherwise, the unwinding code (whatever kind of stack-walking thingy that may be) get confused.

I've actually been able to build a working DLL, but I had to use the standard Windows toolchain (which, surprisingly to me, I could download for free). Adapting those makefiles to gcj will be an interesting exercise...

I'd never thought my desire to integrate open source java software to Windows would lead me to the installation and fiddling with of so much Microsoft tools...

So the gcj toolchain seems to be properly compiled under Windows. And I've been able to compile and run a simple hello world.

After some hesitations, I've also compiled and linked simple SWT code, which is my main goal for now. Sadly, this dies when setting up SWT Display. gdb only revealed some arcade parts of stacktraces handling in libjava; nothing I can debug myself for now.

Since I don't know how to handle this, I posted a message to gcc's java list. I've registered to it when I started playing with gcj; those people seem pretty reactive.

My discovery of the wonders of open-source java compilers continues, as I dig deeper in gcj mailing lists archives...

So ecj does not compile to native code... I'll stick to gcj then.

Actually, I packed together rmathew's instructions in a shell script and after some fiddling, I've successfully built my first Windows gcj compiler yersterday!

It's a priviledged moment: as I didn't have time to read the compilation logs and test the resulting binaries, I am not aware for now of any problem that may have happened :-)

In my study of the native java compilation ecosystem, I discovered an interesting compiler project, GCJX. One of the goals of GCJX is to replace the current Java front-end in GCJ. Sounds nice.

Then I discovered that its main developer, Tom Tromey, is seriously reconsidering his project. But in that same message, I learnt the existence of the seemingly little-known Eclipse Java Compiler (ecj). Which looks nice from a performances point of view, but doesn't even answer to its name...

Anyway. I kind of goofed around with MinGW/MSYS-based gcc compilation, without much luck for now. But I spent some time on cross-native (or whatever it's called) compilation of a Windows gcc compiler under linux, and this looks very promising.

Hum, the previous link doesn't seem up at all time; here is the goggle cache entry.

First entry. Great.

I feel that Java/SWT under Eclipse is a slick way to develop apps. But being able to share those apps with people without the hassles of JVM installation and kludgy integration would be great.

Here enters native compilation. As a testbed, I'd like to compile a small SWT example demonstrating some nice native features (tray icons and tooltips) under Windows.

For this test to be useful, it should be performed using open-source tools and a modern java environment version (1.4.2 at least, preferably 5.0 or whatever it's called today).

Some documentation exists, but I'd like to write some more up-to-date, no-fuss instructions.