Array new: SmallInteger maxVal

 
VisualWorks throws an exception "Size exceeds implementation limit of 2^28 elements".

Pharo and Squeak also crash the VM when you evaluate:

   (Array new: SmallInteger maxVal) last

What is interesting is that when you doIt in Squeak trunk:  

(Array new: SmallInteger maxVal) last

nothing happens, but VM crashes when you printIt

In Pharo VM already crashes when you just doIt.

It crashes in both when you inspectIt.
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

 





--
http://gulik.pbwiki.com/

 

 
It's a issue of what is insane, plus adding boundary checks everywhere  
that is rarely needed.

The correct response for the issue is to throw a out of memory  
exception when the VM figures out it
can't allocate the 4GB of memory here.

I a quick check shows the primitive fails, then the image side  
primitive failure code does the wrong thing...

In this case I get a MethodContext claiming to be  
"RunArray>>copyFrom:to:"
which if you attempt to work further with, causes problems.

On 2009-10-07, at 1:37 PM, Michael van der Gulik wrote:

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

 
John M McIntosh wrote:
>
> It's a issue of what is insane, plus adding boundary checks everywhere
> that is rarely needed.
>
> The correct response for the issue is to throw a out of memory
> exception when the VM figures out it
> can't allocate the 4GB of memory here.
>

Isn't that possible on a 64bit vm/image?

 

On 08.10.2009, at 10:43, Douglas Brebner wrote:

http://squeakvm.org/squeak64/faq.html

- Bert -

 
On Thu, Oct 08, 2009 at 09:43:34AM +0100, Douglas Brebner wrote:
Well, there are definitely bugs in the VM right now and these need to be
fixed. But as a practical matter I find that the following takes several
minutes to complete on my computer:

        Array new: 16r001FFFFFF

This is well within the addressing range for both 32-bit images and
32-bit VMs, so as a practical matter 64-bit addressing does not matter
here.

So in summary:

- The VM needs to be fixed to behave properly even if the amount of
memory requested is unreasonable.

- It might be useful to have the image guard against requests that
are unreasonable (e.g. raise an error instead of calling a primitive
that is going to take several minutes to complete).

The first point is indisputable, the second could probably be debated
for a long time ;)

Dave