[OpenSmalltalk/opensmalltalk-vm] [Win10] [Squeak] High CPU usage in different images for a few minutes after resume from sleep (#537)

 

I noticed this a few times, and today I observed it a bit: After resuming my Win10 message from sleep, my two open Squeak.exe processes both made up each ~14% CPU load. I suspect this performance gap is caused by the VM because, in one image, a nearly empty Morphic world was open (two non-stepping windows only) and in the other one, a completely empty MVC world; both images were responsive; and according to Squeak's CPU watcher, only ~20% of time were spent in the UI process but 80% in idle. After a few minutes, both VM instances fall back to ~0.1% of total CPU usage.

Is there any chance to find an explanation for this behavior in the VM implementation, are there any hidden background operations (maybe certain WM_MESSAGES) that are triggered after resuming from sleep? Does anyone else notice similar behavior?

For sake of completeness, I should mention that my RAM and disk usage are chronically near maximum (90% of RAM in use, 25 GB on SSD free. Squeak images are so large 😐). But this does not change after a few minutes so I don't think it explains the observed slowdown completely.

VM build 202010232046; but I could already have experienced similar issues a few months ago.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/537", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/537", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

Any ideas? How would I debug this?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/537#issuecomment-834153050", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/537#issuecomment-834153050", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>

 

Hi Christoph,

the VM maintains a circular buffer of the most recent 256 invoked non-JIT primitives, the primitive trace log. This is sometimes a useful clue to what the VM has been doing up to the point where the primitive trace log (PRL) is dumped. On Unix the PTL and current stack can be printed on stdout by sending SIGUSR1 to the VM. If you wanted to dump the PTL on Windows you’d have to work out how to signal the VM. I’m in no way a Windows expert so I have no idea how to do this. But if I were in your shoes this is the route I would take.

_,,,^..^,,,_ (phone)

> On May 7, 2021, at 1:01 AM, Christoph Thiede ***@***.***> wrote:
>
> 
> Any ideas? How would I debug this?
>
>
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

<script type="application/ld+json">[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/537#issuecomment-835419053", "url": "https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/537#issuecomment-835419053", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]</script>