Probably Geode does not need write barriers - I've found the following statement:
"Earlier i386 CPUs (pre-Pentium-III) are fully ordered - the operations on the bus appear in program order - and so there's no requirement for any sort of explicit memory barriers" Anyway, using some locked instruction is more secure. Thanks, Ilya. 2008/2/1, Gregory Shimansky <[EMAIL PROTECTED]>: > On 1 февраля 2008 Mark Hindess wrote: > > On 31 January 2008 at 22:00, Mark Hindess <[EMAIL PROTECTED]> > wrote: > > > On 22 January 2008 at 20:37, Gregory Shimansky <[EMAIL PROTECTED]> > 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. > > 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... > > -- > Gregory >
