On Fri, May 03, 2013 at 09:45:53AM +0100, Frank Shearar wrote:
> Hi Dave,
> 
> There's a comment saying "April 2010 dtl - remove this about one year
> from now". Is it time to remove it?

Yes, I think it is time to remove it.

Background: Earlier VMs had problems with allocation of large objects, and
the problems could crash the VM. We added tests to document the issues,
and the #isSafeVM was added so that folks with older VMs could run the test
suite without crashing.

The VM fixes were in all official VMs as of about April 2010, beginning
with Unix VM 4.0.3.2196. Earlier VMs such as 3.11.3.2135 and before would
probably have the problem.

So yes I think it is safe to remove the check, although it's worth asking
if there might be folks still running the older VMs who might run the
AllocationTest and be annoyed at the resulting system crash?

The VM fixes were done in this update to VMMaker, with additional background
on Mantis (http://bugs.squeak.org/view.php?id=7405):

  Name: VMMaker-dtl.143
  Time: 20 October 2009, 12:00 am
  
  VMMaker 3.11.5
  
  Reference Mantis 7405: Array new: SmallInteger maxVal broken.
  
  Change Set:		ObjectAllocationSizeFixes-dtl-M7405
  Date:			20 October 2009
  Author:			David T. Lewis
  
  Requests for very large object allocation result in various failures including
  VM crashes and incorrect results from primitive calls. This change set adds
  checks for arithmetic overflow in calculation of size requests, and limits the
  maximum size of a #growObjectMemory request to 16r7FFFFFFF to permit use of
  signed 32-bit integer arithmetic in the support code. Also included are some
  variable type declarations and removal of a now unnecessary #oop:isLessThan:
  call.
  
  There may be additional bugs in the support code, which is expected to fail
  gracefully even if someone requests an object memory size increase of
  16r80000000 or more.
  
  In testing on a Linux VM, allocation of objects of size greater than 950MB
  appears to be possible, given enough physical memory to permit the allocation
  to succeed. I do not have sufficient real memory on my system to verify the
  actual results, although I can confirm that this is an effective way to bring
  a Linux system to its knees.

Dave