Filed http://jira.codehaus.org/browse/JRUBY-6253 for the JIT class naming issue.
- Charlie
On Wed, Dec 7, 2011 at 2:59 AM, Charles Oliver Nutter
<head...@headius.com> wrote:
> So...couldn't sleep.
>
> I made a modification to test/test_timeout.rb, where the net/http
> timeout test was using www.google.de as a site to connect to...and
> presumably timeout. That test has always been a little flaky,
> especially on a fast connection like AWS. I modified it instead to use
> Google's public DNS server, 8.8.8.8, which appears to ignore port 80.
> With this change, jruby-test-all-release is green.
>
> I moved on to the JVM builds.
>
> My first change was removing some Hotspot-specific flags from the env
> for jruby-test-matrix builds, which prevented the JRockit build from
> starting up. I have not rerun it yet.
>
> I think IBM Java 5 might be a lost cause. I made some minor good
> changes to test/testMap.rb, but then ran into encoding issues (missing
> charsets) that would be very cumbersome to hack around. We might need
> to drop this one unless someone wants to fight through it.
>
> IBM Java 6 is a better story. The primary issues:
>
> * Because we have been binding private methods, a test in testMap.rb
> failed to work properly because instead of calling Map.put(Object,
> Object) it called a private version put(Integer, Object). Subsequent
> gets from Java were unable to see the values. I think it's probably a
> good idea for us to stop binding private methods; you can go after
> them with java_method, java_send, and the like. Agreed?
>
> * IBM is very restrictive of class names. Specifically, the # we now
> have in some class names from the JIT prevents them from loading *at
> all*. This will have to be addressed in some way, or JIT on IBM Java 6
> will never succeed. Other than that, I removed the # from reified
> class names, which helped
>
> * It is also restrictive of method names. I modified class reification
> to skip methods that were not entirely made up of Java identifier
> characters, but only when on IBM.
>
> These fixes *almost* got IBM Java 6 to pass, but there are compiler
> specs that fail probably because of the method name restrictions.
> Again, this is a bigger problem.
>
> - Charlie
>
> On Wed, Dec 7, 2011 at 12:05 AM, Charles Oliver Nutter
> <head...@headius.com> wrote:
>> More...
>>
>> * The intermittent Fiber failure in the 1.9 RubySpec build were my
>> fault. I did not take enough care to make sure rogue fibers could not
>> wake up threads at random. I committed a new version that uses
>> Exchanger and it appears to consistently pass all specs. I still need
>> to investigate if it impacts performance.
>>
>> * There are two encoding specs that only fail on Java 5. It appears
>> that Java 5's CharsetEncoder is happily allowing invalid EUC_JP input
>> to be transcoded to ISO-8859-1 while Java 6 disallows it with an
>> error. Since the CharsetEncoder is set to REPORT on errors, I must
>> assume this is a bug. I'm introducing a new tag, "java1.5" that we can
>> use to mask out this and other specs. It will be applied automatically
>> when running on a particular version of Java.
>>
>> With these fixes, the interpreted 1.9 spec run is green, and
>> "speci-ci" is finally green again after months of being red. Hooray!
>>
>> The next target was to get jruby-test-all-release green, since it
>> failed last night. I modified test/test_timeout.rb's net/http timeout
>> test to use a server that appears to ignore port 80, one of the Google
>> open DNS servers, 8.8.8.8. That appeared to make the test quicker and
>> more reliable on my machine, so I pushed it. I have not yet run a
>> jruby-test-all-release CI run yet to test it.
>>
>> Tomorrow I will hopefully finally get to the cross-JVM builds.
>>
>> - Charlie
>>
>> On Tue, Dec 6, 2011 at 3:07 AM, Charles Oliver Nutter
>> <head...@headius.com> wrote:
>>> And yet more...
>>>
>>> * Modified the mspec runs to pass "-T -J-XX:MaxPermSize=512M" instead
>>> of trying to set JAVA_OPTS all over. It seems that mspec must do some
>>> env scrubbing, or something...so telling it to explicitly pass a -J
>>> argument to the child JRuby process seems to have worked. The
>>> interpreted, compiled (JIT), and precompiled (forced JIT) 1.8 spec
>>> runs are all green again.
>>>
>>> * The 1.9 spec runs appear to fail with varying numbers of failures.
>>> That's going to take more time to investigate. The fiber specs in
>>> particular seem to pass sometimes and fail sometimes.
>>>
>>> * I've started making an attempt to get the Windows builds green
>>> again. They seem to have decayed to the point of not actually even
>>> starting up ant right, which could be due to my other changes. I added
>>> an explicit path to ant's home and an ANT_HOME env var, and they're at
>>> least attempting to build again. They are still failing, however; we
>>> need to sit down with a Windows box and get everything green there.
>>>
>>> * I kicked off the cross-JVM matrix, and it appears that JRockit fails
>>> because we're using nonstandard flags (CMS stuff, it appears) and J9
>>> fails (both versions) due to actual test failures. Will require a bit
>>> more work. sun-java-5 and sun-java-6 are both green again.
>>>
>>> - Charlie
>>>
>>> On Tue, Dec 6, 2011 at 1:20 AM, Charles Oliver Nutter
>>> <head...@headius.com> wrote:
>>>> Additional tweaks...
>>>>
>>>> * There's a difference in File.flock behavior between Java 5 and later
>>>> versions. Specifically, on later versions you have to have the file
>>>> open in specific modes (read/write) to be able to do shared and
>>>> exclusive locks. There's a guard in RubySpec for this behavior, which
>>>> is exhibited on OpenJDK 6 and later and *should* be exhibited on any
>>>> version of MRI on Solaris (which is the lowest-common-denominator
>>>> excuse for the Java behavior). Because it only fails on Java 5 and the
>>>> majority of users are on Java 6, I've added a Java 5-specific
>>>> exclusion to spec/jruby.1.8.mspec and spec/jruby.1.9.mspec. That
>>>> appears to be getting the spec runs green on Java 5...finally!
>>>>
>>>> * The spec runs were configured in Jenkins to have a maximum permgen
>>>> of 128M, which caused my tweak from earlier to not take effect. I
>>>> modified the Jenkins environment for spec-ci to allow permgen up to
>>>> 512M.
>>>>
>>>> If I have time this evening (sick baby up late) I will attempt to get
>>>> the cross-JVM build matrix green as well. We'll be greener than we've
>>>> been in a long time, once that happens.
>>>>
>>>> - Charlie
>>>>
>>>> On Mon, Dec 5, 2011 at 11:30 PM, Charles Oliver Nutter
>>>> <head...@headius.com> wrote:
>>>>> Man, is this ever a painful job.
>>>>>
>>>>> I've spent most of the day trying to get CI builds green again, and
>>>>> the server has been working against me.
>>>>>
>>>>> Most of the major builds were red...the spec builds, test-all, dist,
>>>>> and I think jruby-base as well. In the process of fixing one build I
>>>>> uncovered regressions in others, or uncovered bugs that caused more
>>>>> builds to go red. Needless to say, I didn't expect to spend 15 hours
>>>>> on this.
>>>>>
>>>>> I think I'm finally closing in on having everything green again, and
>>>>> there were a few facts that came out of this I wanted to bring to
>>>>> everyone's attention.
>>>>>
>>>>> * As I posted earlier, I added another test-all build for jruby-1_6.
>>>>> It should help keep us honest.
>>>>>
>>>>> * Ant 1.7.0 is a pain in the ass. It appeared to ignore the JDK we
>>>>> started it up with and always launched 'java' with whatever the
>>>>> command on PATH was. BUT, it would run that JVM with the runtime you
>>>>> started it up with...or something like that. In any case, those nasty
>>>>> bizarre VerifyErrors came back. Ultimately I ended up going through
>>>>> and explicitly making pretty much all builds use the ant182 install of
>>>>> ant, *and* I modified Jenkins to puts that ant install at the front of
>>>>> PATH. If I didn't do that, it seemed to keep picking up the
>>>>> system-wide emerged "ant" and reverting to the old issues.
>>>>>
>>>>> * I had to bump up permgen on a couple of the precompiled tests again.
>>>>> They're at 512M now. I also added permgen size to the spec runs, which
>>>>> might cause them to break on JVMs that don't have a permgen flag. I'll
>>>>> cross that bridge shortly.
>>>>>
>>>>> * I also forced almost all builds to run with Java 5. We've had some
>>>>> bad Java 6 code sneak through again recently, and we need to keep the
>>>>> builds honest across the board. All builds, unless otherwise
>>>>> specified, will run with Java 5.
>>>>>
>>>>> I'm still in progress, but I'll write again in a while as more builds go
>>>>> green.
>>>>>
>>>>> - Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
