NPE when unlocking lock

Has this problem recurred ever?

That exact exception has not occurred but looking at exceptions in stess config seems to suggest a gcmap problem which may be the cause of this.

http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/stress.938/gcstress/Opt_1/dacapo/eclipse/default/Output.txt 2007-09-05 16:01:06.0
http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/stress.904/gcstress/Opt_1/dacapo/eclipse/default/Output.txt 2007-09-02 16:00:56.0
http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/commit-x87.870/production/default/SPECjbb2005/SPECjbb2005/default/Output.txt 2007-08-27 19:00:55.0
http://jikesrvm.anu.edu.au/cattrack/results/rvmx86lnx32.anu.edu.au/stress.833/gcstress/Opt_1/dacapo/eclipse/default/Output.txt 2007-08-21 16:01:15.0

I was looking at VM_Lock and it seems 'scary' to me

growLocks copys the (static) array apparently without concern for what any other thread/processor is doing.

It appears possible for one processor copying the locks array to miss copying a value that is added after the copy has begun.

This would explain an unexpected NPE when trying to read the VM_Lock object after reading it out of the object header, since it could have been essentially nulled by another processor growing the array.

Perhaps growing in chunks and using an arraylet style access pattern might be better? These are heavy locks after all.

Hopefully I am crazy, but if this is a possible pattern then it could explain some of the odd locking issues we have had.

The initial size is also pretty huge, suggesting that we should decrease it for stress to try find any issues related to this.

+1

the lack of any mutex on lines 230 to 233, and line 279 look scary to me.

I'd suggest going with the arraylet style. We have a VMLock[][] in the bootimage that is fairly small. We initially populate a couple of it's children. As needed threads alloc a new VMLock[] under proper synchronization and install it. We don't copy VM_Lock[] at all.

The cost is an extra indirect & some mask/shift operations to get to the actual lock objects, but since we're dealing with fat locks, we shouldn't care.

In case Daniel's comments about arraylets isn't clear, a lock access would look something like this.

VM_Lock myLock = VM_Locks[lockid>>LOG_CHUNK_SIZE][lockid&((1<<LOG_CHUNK_SIZE)-1)]

where LOG_CHUNK_SIZE would probably be something between 10 and 14 and we'd size VM_Locks to support roughly the same number of locks we do now.

Just a note that synchronization here doesn't mean use of the synchronized keyword, we'll need to use processor locks to avoid potential recursion.

Changed to the arraylet style model in 13746. We shouldn't see this any more