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.
On Wed, Oct 7, 2009 at 9:17 PM, Torsten Bergmann astares@gmx.de wrote:
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.
...should this be fixed in the image or the VM?
Is it the responsibility of the image to make sure that the VM isn't passed insane values, or is the responsibility of the VM to not crash when the image asks for insane values.
Gulik.
On 07.10.2009, at 22:37, Michael van der Gulik wrote:
On Wed, Oct 7, 2009 at 9:17 PM, Torsten Bergmann astares@gmx.de wrote:
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.
...should this be fixed in the image or the VM?
Is it the responsibility of the image to make sure that the VM isn't passed insane values, or is the responsibility of the VM to not crash when the image asks for insane values.
The latter.
- Bert -
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:
On Wed, Oct 7, 2009 at 9:17 PM, Torsten Bergmann astares@gmx.de wrote:
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.
...should this be fixed in the image or the VM?
Is it the responsibility of the image to make sure that the VM isn't passed insane values, or is the responsibility of the VM to not crash when the image asks for insane values.
Gulik.
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 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:
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?
http://squeakvm.org/squeak64/faq.html
- Bert -
On Thu, Oct 08, 2009 at 09:43:34AM +0100, Douglas Brebner wrote:
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?
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
vm-dev@lists.squeakfoundation.org