i386 support is broken about java-thread-affinity HOT 10 CLOSED

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?

from java-thread-affinity.

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.

from java-thread-affinity.

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

from java-thread-affinity.

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.

from java-thread-affinity.

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

from java-thread-affinity.

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

from java-thread-affinity.

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

from java-thread-affinity.

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.

from java-thread-affinity.

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.

from java-thread-affinity.

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

from java-thread-affinity.