Hacker News new | past | comments | ask | show | jobs | submit login

It was used for creating the native builds of XWT [1] 15 years ago. At the time I found it amazing to see Java programs becoming native (a lot snappier and generally faster too). It seemed (naively) to be beyond what was possible.

However, the main problem with GCJ was it used conservative garbage collection - boehm GC - and as such was fundamentally broken for long running programs (what java is good for). Without wanting to denigrate it too much, it seems to me that a lot of 'good' work has been put into this approach which was essentially a cul-de-sac.

I had a related rather general thought recently about documenting features in projects. Sometimes the hardest thing to know is whether something is in fact a good idea or not (both in theory and in practice) and the amount of effort/quality of documentation is probably not a good indicator of this. So in the case of the GCJ garbage collector, there was always a lot of talk about how clever the garbage collector was and all the technical aspects, but unless you were already an expert, how would you know if it was infact a good idea or not.

[1] That is this one, there are several now doing similar things (!). http://www.xwt.org/

The code lives on here https://sourceforge.net/projects/vexi/




Anyone know if gcj ever experimented with a precise GC? Or did the design of GCC simply not allow for a non-conservative GC implementation?


Historical. We implemented the Bohm GC at Cygnus, funded by Metaphor back around 92/93 if I remember. GCC is / was very conservative.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: