Hi all,
We just found out that the VM crashes when trying to build very large integers. I'm not sure what could cause the problem... Best, Fabio |
On 01.06.2016, at 13:27, Fabio Niephaus <[hidden email]> wrote:
> > Hi all, > > We just found out that the VM crashes when trying to build very large integers. > I'm not sure what could cause the problem... Maybe largeIntgrowTo doesn’t check the size? Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x9b5fa572 __pthread_kill + 10 1 libsystem_pthread.dylib 0x91403654 pthread_kill + 101 2 libsystem_c.dylib 0x93dddc34 abort + 156 3 org.squeak.Squeak$(VM_MONIKER) 0x00139db9 sigsegv + 175 4 libsystem_platform.dylib 0x9e4bd79b _sigtramp + 43 5 ??? 0xffffffff 0 + 4294967295 6 org.squeak.Squeak$(VM_MONIKER) 0x00139d0a getCrashDumpFilenameInto + 82 7 org.squeak.Squeak$(VM_MONIKER) 0x00177262 largeIntgrowTo + 107 8 org.squeak.Squeak$(VM_MONIKER) 0x001771f1 normalizePositive + 190 9 org.squeak.Squeak$(VM_MONIKER) 0x0017678c primDigitMultiplyNegative + 597 10 ??? 0x04cb4cc8 0 + 80432328 11 org.squeak.Squeak$(VM_MONIKER) 0x000c203a interpret + 741 - Bert - smime.p7s (5K) Download Attachment |
> On 01.06.2016, at 13:43, Bert Freudenberg <[hidden email]> wrote: > > On 01.06.2016, at 13:27, Fabio Niephaus <[hidden email]> wrote: >> >> Hi all, >> >> We just found out that the VM crashes when trying to build very large integers. >> I'm not sure what could cause the problem... > > Maybe largeIntgrowTo doesn’t check the size? > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libsystem_kernel.dylib 0x9b5fa572 __pthread_kill + 10 > 1 libsystem_pthread.dylib 0x91403654 pthread_kill + 101 > 2 libsystem_c.dylib 0x93dddc34 abort + 156 > 3 org.squeak.Squeak$(VM_MONIKER) 0x00139db9 sigsegv + 175 > 4 libsystem_platform.dylib 0x9e4bd79b _sigtramp + 43 > 5 ??? 0xffffffff 0 + 4294967295 > 6 org.squeak.Squeak$(VM_MONIKER) 0x00139d0a getCrashDumpFilenameInto + 82 > 7 org.squeak.Squeak$(VM_MONIKER) 0x00177262 largeIntgrowTo + 107 > 8 org.squeak.Squeak$(VM_MONIKER) 0x001771f1 normalizePositive + 190 > 9 org.squeak.Squeak$(VM_MONIKER) 0x0017678c primDigitMultiplyNegative + 597 > 10 ??? 0x04cb4cc8 0 + 80432328 > 11 org.squeak.Squeak$(VM_MONIKER) 0x000c203a interpret + 741 > > > - Bert - Btw it worked fine in the interpreter and Cog. - Bert - smime.p7s (5K) Download Attachment |
On Wed, Jun 1, 2016 at 5:29 AM, Bert Freudenberg <[hidden email]> wrote:
So which VM does it fail on?
_,,,^..^,,,_ best, Eliot |
On 01.06.2016, at 19:45, Eliot Miranda <[hidden email]> wrote:
> (2 raisedTo: 100000000) basicSize > So which VM does it fail on? Mac Spur 5.0.3692 - Bert - smime.p7s (5K) Download Attachment |
We have similar crash in Pharo by "200000 factorial" crash.dmp includes last record #digitMultiply:neg:. It is same as here. 2016-06-01 22:48 GMT+02:00 Bert Freudenberg <[hidden email]>: On 01.06.2016, at 19:45, Eliot Miranda <[hidden email]> wrote: |
In reply to this post by Bert Freudenberg
Thanks all,
On Wed, Jun 1, 2016 at 1:48 PM, Bert Freudenberg <[hidden email]> wrote: On 01.06.2016, at 19:45, Eliot Miranda <[hidden email]> wrote: OK, tis fixed in VMMaker.oscog-eem.1879. Reporting - 774 tallies, 6,836 msec. **Tree** ... [100 (6,836) [] SmalltalkEditor(TextEditor) evaluateSelectionAndDo: [ 100 (6,836) Compiler evaluate:in:to:notifying:ifFail:logged: [ 100 (6,836) Compiler evaluateCue:ifFail:logged: [ 100 (6,836) Compiler evaluateCue:ifFail: [ 100 (6,836) UndefinedObject DoIt [ 100 (6,836) AndreasSystemProfiler class spyOn: [ 100 (6,836) BlockClosure ensure: [ 100 (6,836) [] AndreasSystemProfiler class spyOn: [ 100 (6,836) AndreasSystemProfiler spyOn: [ 100 (6,836) BlockClosure ensure: [ 100 (6,836) [] UndefinedObject DoIt [ 100 (6,836) SmallInteger(Integer) timesRepeat: [ 100 (6,836) [[]] UndefinedObject DoIt [ 100 (6,836) SmallInteger(Number) raisedTo: [ 100 (6,836) SmallInteger(Number) raisedToInteger: [ 98.45 (6,730) LargePositiveInteger * [ 98.44 (6,730) LargePositiveInteger(Integer) * [ 98.44 (6,730) LargePositiveInteger(Integer) digitMultiply:neg: [ 50.36 (3,442) SmalltalkImage primitiveGarbageCollect [ 28.3 (1,935) LargePositiveInteger normalize [ 28.3 (1,935) LargePositiveInteger(Integer) growto: [ 28.26 (1,932) LargePositiveInteger(Integer) copyto: [ 28.26 (1,932) SmalltalkImage primitiveGarbageCollect **Leaves** 78.61 (5,374) SmalltalkImage primitiveGarbageCollect **Memory** old -16,777,216 bytes young +15,421,544 bytes used -1,355,672 bytes free -15,421,544 bytes **GCs** full 14 totalling 5,279ms (77.0% uptime), avg 377.0ms incr 1 totalling 0ms (0.0% uptime), avg 0.0ms tenures 0 root table 0 overflows **Processes** Total process switches: 1596 Without Profiler: 48 Stack page overflows: 4567 Stack page divorces: 15 _,,,^..^,,,_ best, Eliot |
Thanks, Eliot! On Thu, Jun 2, 2016 at 3:19 AM Eliot Miranda <[hidden email]> wrote:
|
In reply to this post by Eliot Miranda-2
On 02.06.2016, at 03:19, Eliot Miranda <[hidden email]> wrote:
> OK, tis fixed in VMMaker.oscog-eem.1879. > > Reporting - 774 tallies, 6,836 msec. Nice! Is this finally a benchmark where SqueakJS can beat other VMs? [10 timesRepeat: [(2 raisedTo: 100000000) basicSize]] timeToRun Interp: 18042 ms Cog: 7965 ms Spur: ? SqueakJS: 2821 ms (*) :D - Bert - (*) http://bertfreudenberg.github.io/SqueakJS/run/#url=http://freudenbergs.de/bert/squeakjs&files=[Squeak4.5-13680.image,Squeak4.5-13680.changes,SqueakV41.sources] smime.p7s (5K) Download Attachment |
On my machine: SqueakJS: 2832ms RSqueak: 2523ms (*) (*) using fallback Smalltalk code for large integer; https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/rsqueak/bundle/RSqueak.zip Maybe the JITs realize that the result of "2 raisedTo: ...." is not being used and omit the calculation? -- On Thu, Jun 2, 2016 at 12:24 PM Bert Freudenberg <[hidden email]> wrote: On 02.06.2016, at 03:19, Eliot Miranda <[hidden email]> wrote: |
I'm fairly sure that the RSqueak JIT realizes that with both 2 and 100000000 being constants in the doIt method, basic size is always going to return the same thing. In that case we're measuring the first ~1000 iterations, then the JIT time, and then only the cost of returning a constant.
|
One iteration of this “benchmark” is really just two dozen LargeInt multiplies (thanks to our logarithmic #raisedToInteger: implementation). The problem for most VMs is garbage, since the integers grow very fast very quickly. On the interpreter, 10 iterations do 580 (!) full GCs, whereas Cog “only” needs 30 full GCs. SqueakJS does 0 GCs.
- Bert - > On 03.06.2016, at 14:25, timfelgentreff <[hidden email]> wrote: > > I'm fairly sure that the RSqueak JIT realizes that with both 2 and 100000000 > being constants in the doIt method, basic size is always going to return the > same thing. In that case we're measuring the first ~1000 iterations, then > the JIT time, and then only the cost of returning a constant. > > > Fabio Niephaus-3 wrote >> On my machine: >> >> SqueakJS: 2832ms >> RSqueak: 2523ms (*) >> >> (*) using fallback Smalltalk code for large integer; >> https://www.hpi.uni-potsdam.de/hirschfeld/artefacts/rsqueak/bundle/RSqueak.zip >> >> >> Maybe the JITs realize that the result of "2 raisedTo: ...." is not being >> used and omit the calculation? >> >> -- >> >> On Thu, Jun 2, 2016 at 12:24 PM Bert Freudenberg < > >> bert@ > >> > >> wrote: >> >>> On 02.06.2016, at 03:19, Eliot Miranda < > >> eliot.miranda@ > >> > wrote: >>>> OK, tis fixed in VMMaker.oscog-eem.1879. >>>> >>>> Reporting - 774 tallies, 6,836 msec. >>> >>> Nice! >>> >>> Is this finally a benchmark where SqueakJS can beat other VMs? >>> >>> [10 timesRepeat: [(2 raisedTo: 100000000) basicSize]] timeToRun >>> >>> Interp: 18042 ms >>> Cog: 7965 ms >>> Spur: ? >>> SqueakJS: 2821 ms (*) >>> >>> :D >>> >>> - Bert - >>> >>> (*) >>> http://bertfreudenberg.github.io/SqueakJS/run/#url=http://freudenbergs.de/bert/squeakjs&files=[Squeak4.5-13680.image,Squeak4.5-13680.changes,SqueakV41.sources] >>> >>> >>> > > > > > > -- > View this message in context: http://forum.world.st/2-raisedTo-100000000-crashes-VM-tp4898583p4899014.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. smime.p7s (5K) Download Attachment |
Free forum by Nabble | Edit this page |