[Vm-dev] Years ago, when mentioned initialize superclasses f(); where two misplaced and two thrown
Janko Korelc
magik.mountain at gmail.com
Tue May 19 08:23:17 UTC 2020
on pasteUpMorph one was assumed to go retrieve code from .. or should be
sticky probably..
On Tue, 19 May 2020 at 10:15, <vm-dev-request at lists.squeakfoundation.org>
wrote:
> Send Vm-dev mailing list submissions to
> vm-dev at lists.squeakfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
> or, via email, send a message with subject or body 'help' to
> vm-dev-request at lists.squeakfoundation.org
>
> You can reach the person managing the list at
> vm-dev-owner at lists.squeakfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Vm-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Win64 Builds broken, slow build times? (Marcel Taeumel)
> 2. Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk
> voidCogVMState. So. (Janko Korelc)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 May 2020 08:39:53 +0200
> From: Marcel Taeumel <marcel.taeumel at hpi.de>
> To: <vm-dev at lists.squeakfoundation.org>
> Subject: Re: [Vm-dev] Win64 Builds broken, slow build times?
> Message-ID: <Mailbird-6e410cd3-a26d-4a7d-8774-8735eddf3f82 at hpi.de>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Eliot, hi Tom,
>
> I reported this issue about a week ago:
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498 [
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/498]
>
>
> Bintray version squeak.cog.spur_win64x64_202005170205 is still broken.
> Segfaults on startup.
>
> Best,
> Marcel
> Am 19.05.2020 01:02:06 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
>
> Hi Tom,
>
>
> > On May 18, 2020, at 1:44 PM, Tom Beckmann wrote:
> >
> >
> > Hi everyone,
> >
> > I just tried building build.win64x64/squeak.cog.spur on the Cog branch
> but got a segfault on startup. I then tentatively went back 10 commits
> (HEAD~10) and it worked again. This is the output I received in gdb:
> >
> > Thread 1 received signal SIGSEGV, Segmentation fault.
> > 0x00000000004016f3 in interpret () at
> ../../spur64src/vm/gcc3x-cointerp.c:2809
> > 2809 memset(theStackMemory, 0, stackPagesBytes);
> > (gdb) bt
> > #0 0x00000000004016f3 in interpret () at
> ../../spur64src/vm/gcc3x-cointerp.c:2809
> > #1 0x000000000052c34c in sqMain (argc=2, argv=0x1dd53a0) at
> ../../platforms/win32/vm/sqWin32Main.c:1709
> > #2 0x000000000052c7f2 in WinMain (hInst=0x400000, hPrevInstance=0x0,
> lpCmdLine=0xfc437c
> "../../../Squeak6.0alpha-19582-64bit-202003021730-Windows/Squeak6.0alpha-19582-64bit.image",
> nCmdShow=10) at ../../platforms/win32/vm/sqWin32Main.c:1802
> > #3 0x00000000004013c7 in __tmainCRTStartup () at
> /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:339
> > #4 0x00000000004014cb in WinMainCRTStartup () at
> /usr/src/debug/mingw64-x86_64-runtime-7.0.0-1/crt/crtexe.c:195
> >
> > The main reason I'm writing, however, is that I only haven't done a
> bisect yet because building the VM appears unusually slow, when compared to
> building on Linux, as in, orders of magnitude slower. I believe I have the
> same setup as we do on appveyor on windows using cygwin64. Incremental
> builds seem to recompile a lot of files and it appears there are race
> conditions when building with multiple threads (-j8). Are these known
> limitations of the Windows build or am I potentially just having the wrong
> setup?
>
> I hope it is simply wrong setup. I have been making these commits in
> recent weeks in the context of getting 64-bit Terf working. Terf is 3D
> ICC’s Croquet-derived business communications tool which was formerly known
> as Teleplace and Qwaq forums and was the context in which OpenSmalltalk-vm
> was conceived.
>
> I am building 64-bits using Clang 10 and MSVC and I assure you this works.
> See HowToBuild for how to build using this configuration.
>
> Your configuration may be obsolete or it may be valid, and if valid we
> should fix it. Can you list exactly what versions of software (Cygwin or
> mingw, gcc, clang) you’re using your build?
>
>
> > Thank you for any pointers!
> > Tom
>
> Eliot
> _,,,^..^,,,_ (phone)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200519/16302344/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 19 May 2020 10:15:15 +0200
> From: Janko Korelc <magik.mountain at gmail.com>
> To: vm-dev at lists.squeakfoundation.org
> Subject: [Vm-dev] Dialect dependent. In Squeak/Pharo/Cuis IIRC
> Smalltalk voidCogVMState. So.
> Message-ID:
> <CAFNCf47Xp72CPW3rrxZPPUzi3AAJVKwD9+x4sQOH=
> M6bB-jDeA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, 19 May 2020 at 08:22, <vm-dev-request at lists.squeakfoundation.org>
> wrote:
>
> > Send Vm-dev mailing list submissions to
> > vm-dev at lists.squeakfoundation.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
> > or, via email, send a message with subject or body 'help' to
> > vm-dev-request at lists.squeakfoundation.org
> >
> > You can reach the person managing the list at
> > vm-dev-owner at lists.squeakfoundation.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Vm-dev digest..."
> >
> >
> > Today's Topics:
> >
> > 1. Re: [Pharo-dev] Squeak and Pharo speed differences (Shaping)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 19 May 2020 01:21:53 -0500
> > From: "Shaping" <shaping at uurda.org>
> > To: "'Pharo Development List'" <pharo-dev at lists.pharo.org>, "'Open
> > Smalltalk Virtual Machine Development Discussion'"
> > <vm-dev at lists.squeakfoundation.org>
> > Subject: Re: [Vm-dev] [Pharo-dev] Squeak and Pharo speed differences
> > Message-ID: <03c401d62da5$ca7b4ba0$5f71e2e0$@uurda.org>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Another GUI-input speed observation:
> >
> >
> >
> > If you click the scroll wheel once to shift the text contents of the
> pane,
> > the visual effect is very fast. I cannot detect any latency; it
> certainly
> > is not close to what I see for text insertion/deletion, cursoring, and
> > double-click selection. The slower operations all involve getting a
> damage
> > rect at a specific point based on cursor position or click position. The
> > faster scrolling function doesn’t need to do that. It just grabs the
> > entire visible rectangle minus one line, and blits it shifted down by one
> > line, along with the one new line. That looks like an almost zero-cost
> > collection of damage rects. It’s a simple, fast calculation. Collection
> > of damage rects for the slower operations looks much more expensive. The
> > events involved in both cases are delivered to the target handler with
> the
> > same latency. The slowness or quickness seems to have after that.
> >
> >
> >
> >
> >
> > Shaping
> >
> >
> >
> > Hence graphics output necessarily lags input on Morphic. So these speed
> > differences have nothing to do with vm performance and everything to do
> > with GUI architecture.
> >
> >
> >
> > Both Squeak and Pharo show the same delay for text selection latency.
> > The architecture difference is not likely causing that.
> >
> >
> >
> > Given that both Pharo and Squeak useorphic and hence nothing have the
> same
> > tender-in-step architecture isn’t the fact that they show the sane
> > performance issue evidence that points to precisely this being the cause?
> >
> >
> >
> > Yes, but not architecture, by which I think you mean the pushing of
> events
> > versus the fixed-frequency regular loop in Morphic. I would expect a big
> > variation in the Morphic case, but I don’t know what the fixed frequency
> > is; it could well under the noise floor. My first thought would be that
> > getting the damage rects is the problem, but I’ve not seen the code.
> >
> >
> >
> > How do we index or look up the word rectangle to render? I’m think
> that
> > is more likely the cause. Is a map created at method compile time and
> > updated after text is moved during edits?
> >
> >
> >
> > My understanding is that damage rectangles are retrieved,
> >
> >
> >
> > Right, but this is the potentially slow part—the retrieving or perhaps
> > more specifically mapping a point to a rectangle containing a contiguous
> > sequence of non-whitespace character (a word).
> >
> >
> >
> > combined to produce a smaller (non-overlapping?) set, and that the entire
> > morph tree is asked to render within these damage rectangles. You can
> read
> > the gods for yourself.
> >
> >
> >
> > It’ll be a while.
> >
> > ….
> >
> >
> >
> > I just tried some new experiments. I should have thought of these
> > earlier. Character insertion and cursoring in any direction by one
> > character have the same latency. Collecting the damage rectangle at the
> > cursor position and around the selected word are both taking about the
> same
> > time as far as I can tell with my eye, and this time is longer than in VW
> > or any Windows app. But VW doesn’t use the Windows message queue
> > directly. All incoming Windows events are converted to Smalltalk
> > equivalents and are queued on the Smalltalk side. And it works well.
> Why
> > not mimic that pattern to get the extra speed? Does something in
> > Squeak/Pharo architecture prevent us from doing that?
> >
> >
> >
> > How do we set a multi-process time profiler running so that we don’t need
> > to eval blocks to get tallies. I just want to use the editor and watch
> > method hit distribution. I see the Time profiler window; it seems to
> need
> > a code snippet to work.
> >
> >
> >
> >
> >
> > How is the JIT code cache cleared?
> >
> >
> >
> > Dialect dependent. In Squeak/Pharo/Cuis IIRC Smalltalk voidCogVMState.
> >
> >
> >
> > Okay.
> >
> >
> >
> >
> >
> > Can’t remember how it’s done in VW.
> >
> >
> >
> > CompiledMethod allInstancesWeakly do: [:compiledMethod | compiledMethod
> > flushCachedVMCode]
> >
> >
> >
> >
> >
> > Baseline state: the only thing that comes to mind here is Collect All
> > Garbage.
> >
> >
> >
> > There’s also Smalltalk garbageCollectMost which just runs a scavenge.
> > IIRC someInstance has a side effect of running a scavenge in VW.
> >
> >
> >
> > Okay.
> >
> >
> >
> >
> >
> > and then ensure, through the relevant introspection primitives,
> >
> >
> >
> > What are these? What state features am I introspecting after the test?
> > Sizes of heap subspaces? I can do Time microsecondsToRun: on the blocks.
> >
> >
> >
> > In Squeak/Pharo/Cuis see Smalltalk vmParameterAt: or Smalltalk vm
> > parameterAt: and senders.
> >
> >
> >
> > Okay. I see this list:
> >
> >
> >
> > parameterAt: parameterIndex
> >
> > "parameterIndex is a positive integer corresponding to
> one
> > of the VM's internal
> >
> > parameter/metric registers. Answer with the current
> value
> > of that register.
> >
> > Fail if parameterIndex has no corresponding register.
> >
> > VM parameters are numbered as follows:
> >
> > 1 end (v3)/size(Spur) of old-space (0-based,
> > read-only)
> >
> > 2 end (v3)/size(Spur) of young/new-space
> > (read-only)
> >
> > 3 end (v3)/size(Spur) of heap (read-only)
> >
> > 4 nil (was allocationCount (read-only))
> >
> > 5 nil (was allocations between GCs
> > (read-write)
> >
> > 6 survivor count tenuring threshold
> > (read-write)
> >
> > 7 full GCs since startup (read-only)
> >
> > 8 total milliseconds in full GCs since
> > startup (read-only)
> >
> > 9 incremental GCs (SqueakV3) or scavenges
> > (Spur) since startup (read-only)
> >
> > 10 total milliseconds in incremental GCs
> > (SqueakV3) or scavenges (Spur) since startup (read-only)
> >
> > 11 tenures of surving objects since startup
> > (read-only)
> >
> > 12-20 were specific to ikp's JITTER VM, now 12-19 are
> open
> > for use
> >
> > 20 utc microseconds at VM start-up (actually at
> > time initialization, which precedes image load).
> >
> > 21 root table size (read-only)
> >
> > 22 root table overflows since startup
> (read-only)
> >
> > 23 bytes of extra memory to reserve for VM
> > buffers, plugins, etc (stored
> >
> > in image file header).
> >
> > 24 memory threshold above which shrinking
> object
> > memory (rw)
> >
> > 25 memory headroom when growing object memory
> > (rw)
> >
> > 26 interruptChecksEveryNms - force an
> > ioProcessEvents every N milliseconds (rw) 27 number of times
> > mark loop iterated for current IGC/FGC (read-only) includes
> > ALL marking
> >
> > 28 number of times sweep loop iterated for
> > current IGC/FGC (read-only)
> >
> > 29 number of times make forward loop iterated
> > for current IGC/FGC (read-only) 30 number of times compact
> > move loop iterated for current IGC/FGC (read-only)
> >
> > 31 number of grow memory requests (read-only)
> >
> > 32 number of shrink memory requests (read-only)
> >
> > 33 number of root table entries used for
> current
> > IGC/FGC (read-only)
> >
> > 34 number of allocations done before current
> > IGC/FGC (read-only)
> >
> > 35 number of survivor objects after current
> > IGC/FGC (read-only)
> >
> > 36 millisecond clock when current IGC/FGC
> > completed (read-only)
> >
> > 37 number of marked objects for Roots of the
> > world, not including Root Table entries for current IGC/FGC
> > (read-only)
> >
> > 38 milliseconds taken by current IGC
> (read-only)
> >
> > 39 Number of finalization signals for Weak
> > Objects pending when current IGC/FGC completed (read-only)
> >
> > 40 BytesPerOop for this image
> >
> > 41 imageFormatVersion for the VM
> >
> > 42 number of stack pages in use
> >
> > 43 desired number of stack pages (stored in
> > image file header, max 65535)
> >
> > 44 size of eden, in bytes
> >
> > 45 desired size of eden, in bytes (stored in
> > image file header)
> >
> > 46 machine code zone size, in bytes (Cog only;
> > otherwise nil)
> >
> > 47 desired machine code zone size (stored in
> > image file header; Cog only; otherwise nil)
> >
> > 48 various header flags. See getCogVMFlags.
> >
> > 49 max size the image promises to grow the
> > external semaphore table to (0 sets to default, which is
> 256
> > as of writing)
> >
> > 50-51 nil; reserved for VM parameters that persist in the
> > image (such as eden above)
> >
> > 52 root table capacity
> >
> > 53 number of segments (Spur only; otherwise
> nil)
> >
> > 54 total size of free old space (Spur only,
> > otherwise nil)
> >
> > 55 ratio of growth and image size at or above
> > which a GC will be performed post scavenge
> >
> > 56 number of process switches since startup
> > (read-only)
> >
> > 57 number of ioProcessEvents calls since
> startup
> > (read-only)
> >
> > 58 number of ForceInterruptCheck calls since
> > startup (read-only)
> >
> > 59 number of check event calls since startup
> > (read-only)
> >
> > 60 number of stack page overflows since startup
> > (read-only)
> >
> > 61 number of stack page divorces since startup
> > (read-only) 62 compiled code compactions since startup
> > (read-only; Cog only; otherwise nil)
> >
> > 63 total milliseconds in compiled code
> > compactions since startup (read-only; Cog only; otherwise nil)
> >
> > 64 the number of methods that currently have
> > jitted machine-code
> >
> > 65 whether the VM supports a certain feature,
> > MULTIPLE_BYTECODE_SETS is bit 0, IMMTABILITY is bit 1
> >
> > 66 the byte size of a stack page
> >
> > 67 the max allowed size of old space (Spur
> only;
> > nil otherwise; 0 implies no limit except that of the underlying
> > platform)
> >
> > 68 the average number of live stack pages when
> > scanned by GC (at scavenge/gc/become et al)
> >
> > 69 the maximum number of live stack pages when
> > scanned by GC (at scavenge/gc/become et al)
> >
> > 70 the vmProxyMajorVersion (the
> interpreterProxy
> > VM_MAJOR_VERSION)
> >
> > 71 the vmProxyMinorVersion (the
> interpreterProxy
> > VM_MINOR_VERSION)"
> >
> >
> >
> >
> >
> > Shaping
> >
> >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> >
> http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200519/e10c9704/attachment.html
> > >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Vm-dev mailing list
> > Vm-dev at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
> >
> >
> > ------------------------------
> >
> > End of Vm-dev Digest, Vol 167, Issue 62
> > ***************************************
> >
>
>
> --
> gee, gravitino, graviton exchange
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200519/f0edeead/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Vm-dev mailing list
> Vm-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/vm-dev
>
>
> ------------------------------
>
> End of Vm-dev Digest, Vol 167, Issue 63
> ***************************************
>
--
gee, gravitino, graviton exchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200519/4cd07203/attachment-0001.html>
More information about the Vm-dev
mailing list