![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
first patch
« previous entry | next entry »
Aug. 3rd, 2007 | 12:49 pm
It seems that my first patch fixing pscan issues in OpenJDK has made it in b17.
More to come when I'm finished with gcj + javac, where I'm currently trying to track down a regression (NPE in javac on a jtreg test) that only happens when running the javac jtreg test suite on gcj/ecj compiled javac. The previous one I had found required fixing Classpath's EnumSet implementation to conform more closely to the API spec. I've also got to resync my code & patches to b17 today, to see if the odd javac compiler error message regression is gone away, otherwise I'll have to track it down.
I'll also have to check if the last pending bit (ECHO) of Makefile fixes I've kept around has made it into javac, and do the bug tracker dance to get the fix in. It's a rather temporary issue, as the javac build system is going to switch over to using make as a wrapper to ant tasks at some point in time (good idea, imho: the fewer build systems are maintained in parallel, the better), but still, it's better to have it in a more straightforward make-able form without having to hunt for patches until that switch happens.
Earlier this week, I've stumbled across a gcj ICE while trying to natively compile the patched up javac (which has been the major reason for me to autoconfiscate javac: it's rather easy to persuade automake to churn out gcj native builds along with regular bytecode ones), and tried to track it down using delta, an interesting little tool for reducing error inducing inputs to their minimal form. Unfortunately, my reduced test case still needed the rest of the javac source code, so I'll need to have another go at it with the updated ecj + gcj classes once I've tracked down the regression I'm hunting atm.
Hacking on gcj is a bit of a time sink, due to the long build times: it takes about 4 hours for a full gcc/gcj build in Java maintainer mode (I needed to patch EnumSet, and I am hacking on GCCMain), plus 30 minutes for the gcj regression test suite on my ageing laptop. A full jtreg run also takes about 30 minutes, so the round trip time between my changes and seeing them crash and burn is not nearly as spontaneous as I'd like it. It turns out that ccache doesn't really help with gcc build times, as the majority of time is spent in the rebuilding with xgcc, afaict. So accordingly, I don't expect distcc to have much of an effect, either, and I don't think I'll be able to reduce my roundtrip times to something more immediate without investing in a new laptop. Oh well, the battery on this one is dying anyway. Sigh.
More to come when I'm finished with gcj + javac, where I'm currently trying to track down a regression (NPE in javac on a jtreg test) that only happens when running the javac jtreg test suite on gcj/ecj compiled javac. The previous one I had found required fixing Classpath's EnumSet implementation to conform more closely to the API spec. I've also got to resync my code & patches to b17 today, to see if the odd javac compiler error message regression is gone away, otherwise I'll have to track it down.
I'll also have to check if the last pending bit (ECHO) of Makefile fixes I've kept around has made it into javac, and do the bug tracker dance to get the fix in. It's a rather temporary issue, as the javac build system is going to switch over to using make as a wrapper to ant tasks at some point in time (good idea, imho: the fewer build systems are maintained in parallel, the better), but still, it's better to have it in a more straightforward make-able form without having to hunt for patches until that switch happens.
Earlier this week, I've stumbled across a gcj ICE while trying to natively compile the patched up javac (which has been the major reason for me to autoconfiscate javac: it's rather easy to persuade automake to churn out gcj native builds along with regular bytecode ones), and tried to track it down using delta, an interesting little tool for reducing error inducing inputs to their minimal form. Unfortunately, my reduced test case still needed the rest of the javac source code, so I'll need to have another go at it with the updated ecj + gcj classes once I've tracked down the regression I'm hunting atm.
Hacking on gcj is a bit of a time sink, due to the long build times: it takes about 4 hours for a full gcc/gcj build in Java maintainer mode (I needed to patch EnumSet, and I am hacking on GCCMain), plus 30 minutes for the gcj regression test suite on my ageing laptop. A full jtreg run also takes about 30 minutes, so the round trip time between my changes and seeing them crash and burn is not nearly as spontaneous as I'd like it. It turns out that ccache doesn't really help with gcc build times, as the majority of time is spent in the rebuilding with xgcc, afaict. So accordingly, I don't expect distcc to have much of an effect, either, and I don't think I'll be able to reduce my roundtrip times to something more immediate without investing in a new laptop. Oh well, the battery on this one is dying anyway. Sigh.
