[Vm-dev] Re: VM patches for oop comparison and usqInt declarations

Andreas Raab andreas.raab at gmx.de
Thu Jun 14 00:19:22 UTC 2007


BTW, this is a really great catch John. We have seen various lockups in 
this precise loop and the subtlety of the lockup condition is beautiful. 
  I mean you really have to appreciate that the condition here is that 
"lastWord + BytesPerWord <= lastWord" for the situation to go wrong.

Cheers,
   - Andreas

John M McIntosh wrote:
> 
> I stuck some compares in the pointer accessors and got
> 
> 
>             for (w = firstWord; w <= lastWord; w += BytesPerWord) {
>                 longAtput(target, longAt(w));
>                 target += BytesPerWord;
>             }
> 
> 
> in incCompMove
> 
> w is 0x86401004
> firstWord is 0x7ffffff4
> lastWord is 0x7ffffffc
> 
> 
> mmm Oh wait w being an integer of value -2042621948  is well always less 
> than lastWord.
> 
> Perhaps other suspects?
> 
>     for (i = firstField; i <= lastField; i += BytesPerWord) {
>     for (i = BaseHeaderSize; i <= lastField; i += BytesPerWord) {
>     for (i = ((lastPointerOf(oop)) + BytesPerWord); i <= (sz - 
> BaseHeaderSize); i += BytesPerWord) {
> 
> 
> On May 27, 2007, at 6:22 AM, David T. Lewis wrote:
> 
>>
>> On Wed, Apr 25, 2007 at 06:59:49AM -0400, David T. Lewis wrote:
>>> The attached zip contains six change sets and an update for 
>>> sqMemoryAccess.h.
>>> The changes are intended to resolve problems with oop variable 
>>> declarations
>>> and comparison operations that may occur on platforms that assign object
>>> memory to high virtual memory address values.
>>
>> Can anyone confirm whether these changes are producing the intended
>> results, i.e. a system that used to crash with >2GB oop issues, and
>> no longer crashes after applying the changes? I don't have any Squeak
>> platform that exhibits the problem, so so I can't confirm whether or
>> not the problem is actually resolved.
>>
>> Thanks,
>>
>> Dave
>>
> 
> -- 
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> 
> 


More information about the Vm-dev mailing list