I'll point out that under openBSD for example they have started to move  
towards allocating space for memory at random locations, versus   
starting at low memory to avoid certain classes of malware that is  
making assumptions about memory allocation behavior, ie the N memory  
allocation for this  application occurs at 0x001cfe so if we poke  
there.... This in future will I think increase the probability that  
when you ask for 1GB of virtual memory for the image it will not be  
allocated say at the 400K boundary it might be allocated at the 2GB  
boundary.

Ian's work address "the address" problem but from what he told me it  
causes a performance issue. Over the winter I guess some of us will dig  
a bit deeper and see how it solves 32bits on
32bits.

Tim -> Hint perhaps we can put a stop check in after we allocate the  
image segment and if it spans the 2GB boundary we complain and quit,  
versus core dumping?

On Dec 11, 2004, at 10:25 AM, C. David Shaffer wrote:

> Colin Putney wrote:
>
>> David,
>>
>> The bug Tim is talking about is indeed a VM bug. What happens is that  
>> the VM (sometimes?) treats pointers to objects as signed integers.  
>> This works as long as the address of the object is less than 2GB -  
>> ie, the highest bit of the pointer isn't set. Beyond that limit, the  
>> VM attempts to do "pointer arithmetic" involving negative numbers,  
>> which produces incorrect results.
>>
>> This is a fairly deep-seated bug in the core VM, nothing to do with  
>> the platform-specific stuff or compilation options. The only work  
>> around is to arrange for your OS to allocate memory below the 2GB  
>> threshold. It's kind of tricky and I can't give you any advice for  
>> doing it beyond searching the list archives - others have run into  
>> this.
>
>
> Thanks for clarifying.  I thought Tim was trying to say that the image  
> size was >2Gb which seemed strange for any image of mine, let along a  
> stock "full" image :-)  I understand the problem now...I suspect there  
> are kernel options to avoid problems with this.  I'll look into it and  
> post what I find.  Thanks!
>
> David
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===