harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Berezhniuk" <ilya.berezhn...@gmail.com>
Subject Re: [general] harmony launch failed on AMD Geode LX
Date Fri, 01 Feb 2008 13:01:27 GMT
I second the idea with atomics unification.

I suggest to get rid of APR atomics, and use atomics from PORT.
I already made some steps - HARMONY-5395 contains a patch with missed
'cas' for linux and some corrections to current 'cas' functions - but
there are still plenty of work on atomic inc/dec etc.

I'm going to continue this when I have enough time.

Thanks,
Ilya.

2008/2/1, Mark Hindess <mark.hindess@googlemail.com>:
>
> On 1 February 2008 at 1:42, Gregory Shimansky <gshimansky@apache.org> wrote:
> > On 1 Ñ„ÐµÐ²Ñ€Ð°Ð»Ñ  2008 Mark Hindess wrote:
> > > On 31 January 2008 at 22:00, Mark Hindess <mark.hindess@googlemail.com>
> > wrote:
> > > > On 22 January 2008 at 20:37, Gregory Shimansky <gshimansky@apache.org>
> > wrote:
> > > > > SeongCheon, Kang said the following on 22.01.2008 20:29:
> > > > > > I Installed Apache-harmony-jre-603435 on AMD Geode LX based
system
> > > > > > board (PC Engines ALIX.1C) that is installed xubuntu 7.10.
> > > > > >
> > > > > > I executed Equinox OSGi service platform and harmony just prints
out
> > > > > > 'illegal instruction' after 10 seconds. But, 'hello world' works
> > > > > > well. :-
> > > >
> > > > )
> > > >
> > > > > > And, I installed Sun JRE 5. Equinox OSGi service platform works
well
> > > > > > on i
> > > >
> > > > t.
> > > >
> > > > > > What's the problem? Anyone has tested on AMD Geode LX or/and
xubuntu
> > > > > > 7?
> > > > >
> > > > > I think it may be because it doesn't support SSE according to
> > > > > wikipedia. To make sure that it is the case you can use gdb to print
> > > > > out the failing instruction like
> > > > >
> > > > > (gdb) x/1i $eip
> > > > >
> > > > > and see what it shows and where this instruction appears (whether
it is
> > > > > in generated code or in Harmony compiled code).
> > > > >
> > > > > Also you can try to run the application in interpreter mode using
-Xint
> > > > > option for VM.
> > > >
> > > > I recompiled classlib with -march=c3 rather than -march=pentium3.  But
> > > > even with -Xint HelloWorld still dies with illegal instruction.  gdb
> > > > says:
> > > >
> > > > (gdb) bt
> > > > #0  0xb76e49f3 in MemoryWriteBarrier ()
> > > >    from drlvm/bin/default/libharmonyvm.so
> > > > #1  0xb76e16f0 in String_Pool::lookup ()
> > > >    from drlvm/bin/default/libharmonyvm.so
> > > > #2  0xb76e17c4 in String_Pool::lookup ()
> > > >    from drlvm/bin/default/libharmonyvm.so
> > > > #3  0xb76d6a08 in Global_Env::Global_Env ()
> > > >    from drlvm/bin/default/libharmonyvm.so
> > > > #4  0xb77528a4 in JNI_CreateJavaVM ()
> > > >    from drlvm/bin/default/libharmonyvm.so
> > > > #5  0x08049a55 in invocation (portLibrary=0xbffff918, argc=5,
> > > > argv=0xbffffd54 ,
> > > >     handle=134654592, version=65540, ignoreUnrecognized=1 '\001',
> > > >     mainClass=0xbffffe6a "HelloWorld", classArg=4,
> > > >     propertiesFileName=0x806aa00
> > > > "drlvm/bin/default/harmonyvm.properties", is StandaloneJar=0,
> > > > vmdllsubdir=0xbffff842 "default") at ../shared/main.c:672 #6  0x08049160
> > > > in gpProtectedMain (args=0xbffff8f8) at ../shared/main.c:393 #7
> > > > 0x0804b4a1 in main (argc=5, argv=0xbffffd54, envp=0xbffffd6c) at
> > > > ../shared/cmain.c:146
> > > > (gdb) x/1i $eip
> > > > 0xb76e49f3 <_Z18MemoryWriteBarrierv+3>: sfence
> > > >
> > > > Suggestions welcome.
> > >
> > > Answering my own question... I'm going to try:
> > >
> > >   lock; addl $0,0(%%esp)
> > >
> > > in place of sfence in vm/vmcore/src/thread/linux/atomics.cpp.
> >
> > Yes I think this should help on processors with no SSE (not to mention
> > SSE2) support.
>
> It does.  HelloWorld runs okay with -Xint.  (Now I just need to find a
> way to run the tests on a machine which boots to a small ramdisk from
> compact flash and doesn't currently support network file systems.)
>
> Without -Xint, predictably, it fails with not-immediately-helpful core
> which reports:
>
> (gdb) bt
> #0  0xa649d24d in ?? ()
> (gdb) x/1i $eip
> 0xa649d24d:     (bad)
>
> It might be worth adding an option to the federation build compile for
> a more limited processor so that people can do some testing w/-Xint - on
> OLPC, Geode and VIA based machines?
>
> > In fact VM's atomics stuff needs some unification. There are about three
> > write barrier and atomic compare implementations that I know of, and
> > probably several that I don't know of...
>
> Definitely.
>
> -Mark.
>
>
>

Mime
View raw message