i386 support is broken

[isopov]

From the defines it seems that i386 is intended to be supported. But in Makefile you may find hardcoded:
JVM_SHARED_LIB := $(JAVA_HOME)/jre/lib/amd64/server
for i386 it sghould be
JVM_SHARED_LIB := $(JAVA_HOME)/jre/lib/i386/server

Also when compiling it give following warnings:

vanilla_java_affinity_impl_NativeAffinity.c: In function ‘Java_vanilla_java_busywaiting_impl_JNIBusyWaiting_whileEqual0’:
vanilla_java_affinity_impl_NativeAffinity.c:118: warning: cast to pointer from integer of different size
vanilla_java_affinity_impl_NativeAffinity.c: In function ‘Java_vanilla_java_busywaiting_impl_JNIBusyWaiting_whileLessThan0’:
vanilla_java_affinity_impl_NativeAffinity.c:136: warning: cast to pointer from integer of different size

Also (don't know whether it is caused by i386):

Failed tests:
dumpLocks(vanilla.java.affinity.AffinityLockTest)

Tests in error:
assignReleaseThread(vanilla.java.affinity.AffinityLockTest)

[peter-lawrey]

These are good points. I don't have access to a 32-bit machine so I haven't been able to test it. The JVM_SHARED_LIB would need to change for 32-bit systems, it needs to be amd64 for 64-bit Intel system. (And something else again for Sparc etc)

The warnings are valid, but shouldn't be a problem for 32-bit systems and the address should be a 32-bit value in the first place.

Can you try running the AffinityLockTest in your IDE/command line and giving me the full output so I can see why its failed?

[peter-lawrey]

Can you check the JNA implementation works for you? (Even if the native one doesn't compile

I have changed

JVM_SHARED_LIBS := -L$(JAVA_HOME)/jre/lib/amd64/server -L$(JAVA_HOME)/jre/lib/i386/server

so it shouldn't matter whether you have an amd64 or i386 system.

[isopov]

It seems that they both failed due to the isue #10, but now they both erorr due to

jCaused by: java.lang.ArrayIndexOutOfBoundsException: 2
at vanilla.java.affinity.AffinityLock.cpuLayout(AffinityLock.java:68)
at vanilla.java.affinity.AffinityLock.(AffinityLock.java:53)
... 24 more

EDIT: Maybe that should be disscused in #10. Code tries to take from array using core id as index, while core id is 2 and array of locks is 2x2

[peter-lawrey]

I have had to change the data structure this uses so that cores ids are not continuous.

Have test this change locally. Thank you for testing it on a i3.

[isopov]

If you need confirmation - this issue is resolved for me.

[peter-lawrey]

Confirmation is appreciated as I can only test it so much with the system I have.

[akerbos]

I know this is a hassle, but maybe you can use virtual machines to perform basic portability tests?

[peter-lawrey]

The problem with virtual machines is that they have virtual CPU environment and affinities, or done provide information that a real system will (because its not a real CPU layout)

To work around this I have loaded the cpuinfo from an assortment of machine.

Using a virtual machine would be useful for testing windows, and I have plans to set up much a system.

Its much easier for me, for people to report issues and even provide fixes and I am more than happy for people to improve the library.

[akerbos]

I see your point. I was not suggesting you should deeply test your library on a multitude of systems. Building it should work on the major operating system flavors, though, and that you can easily test in virtual machines.

[peter-lawrey]

I have tested it builds and works on a Windows 7 64-bit laptop and a Ubuntu 11 and Centos 6 machine.