IcedTea6 1.8.9 and Zero/Shark

[Xerxes Rånby]

On 2011-08-12 21:20, Florian Weimer wrote:
> * Xerxes Rånby:
>
>> tor 2011-08-11 klockan 19:54 +0200 skrev Florian Weimer:
>>> I'm trying to prepare another security update for Debian.  After
>>> applying the changes from 1.8.9, Debian's Zero/Shark does not build
>>> anymore.  It hangs during testing; jtreg hangs after throwing an
>>> exception:
>>
>> Good news are that Shark and OpenJDK actually built.
>>
>> I agree its a pain that you see a stall during testing.  The version
>> of Shark that you are packaging do contain known bugs, my best
>> suggestion to you are to upgrade the package.
>
> This is on the long-term stable branch.  My options there are somewhat
> limited, particularly since I do not maintain the package on the
> development branch and cannot test changes there.

Today I noticed that the JIT in Shark was practically disabled on the current developement 
branch after the bump to hs20. When i re-enabled the jit then i noticed that the buildbots 
hits the same bug as you describe when the buildbots test the latest Shark on x86_64 using 
Debian Squeeze.
http://builder.classpath.org/icedtea/buildbot/builders/icedtea6-squeeze-x86_64-quick-shark/builds/128/steps/jtregcheck/logs/stdio

The same version of icedtea6 and Shark pass on the ia32 builder that are running Ubuntu Lucid.
http://builder.classpath.org/icedtea/buildbot/builders/icedtea6-lucid-ia32-quick-shark/builds/5/steps/jtregcheck_1/logs/stdio

>
> It astonishes me that the failures are apparently CPU-specific.

LLVM have much cpu specific code, even some cpu feature code that kicks in on some core 
versions.

Shark itself only have a hand-full places where it do generate different code when running 
on x86_64 compared to ia32. Places like:
openjdk/hotspot/src/share/vm/shark$ grep LP64 *
sharkBuilder.cpp:    "llvm.atomic.cmp.swap.i" LP64_ONLY("64") NOT_LP64("32") ".p0i" 
LP64_ONLY("64") NOT_LP64("32"),
sharkCacheDecache.hpp:#ifdef _LP64
sharkCacheDecache.hpp:#endif // _LP64
sharkContext.hpp:    return LP64_ONLY(jlong_type()) NOT_LP64(jint_type());

>
>> The first shark release that passed the TCK was based on the icedtea
>> 1.9.x release in combination with hs17.
>
> We actually downgraded from hs16 to hs14, and we seem to have fewer
> bugs as a result.  The failures I see could well be LLVM bugs, so
> changing Hotspot might not help much.
>
> Perhaps I should simply disable Zero builds on i386 and amd64.

I will start examine the security patches and see if any of them broke Shark.
It are possibly a x86_64 LLVM bug that now triggers after the slightly changed hotspot.

Which version of LLVM are you using?

I will look into this.

Cheers
Xerxes