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):
Tests in error:
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?
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.
It seems that they both failed due to the isue #10, but now they both erorr due to
jCaused by: java.lang.ArrayIndexOutOfBoundsException: 2
... 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
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.
If you need confirmation - this issue is resolved for me.
Confirmation is appreciated as I can only test it so much with the system I have.
I know this is a hassle, but maybe you can use virtual machines to perform basic portability tests?
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.
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.
I have tested it builds and works on a Windows 7 64-bit laptop and a Ubuntu 11 and Centos 6 machine.