RV: Instrumenting Send and what is
StrikeFontSet>displayString:on:from:to:at:kern:baselineY: doing?
John M McIntosh
johnmci at smalltalkconsulting.com
Sun Oct 30 18:44:24 UTC 2005
David the change set is on
ftp://ftp.smalltalkconsulting.com/experimental/JMMRecordMsgSends.
1.cs.zip
If you want to change the logic to invoke what you suggest please do
and send me the change set. Having a working example for the Unix VM
would be a good thing.
The method of interest would be:
Change?
Interpreter >>initVmStatsTraceMessageSendLevels
vmStatsTraceMessageSendLevels := 0.
vmStatsTraceMessageSendStorageFile := 0.
Then consider two sig handlers of your choice. One that tracks the
level increment number and increments it by one for each signal and
then invokes.
Smalltalk setVMStatsTraceMessageSendLevels: theIncrementNumber
The other handler would just reset theIncrementNumber to zero and
invoke the setVMStatsTraceMessageSendLevels:
----------
ORIGINAL:
*Apologies to people horrified by this piece of code abuses of how
self cCode: works and how it interacts with SLANG, however as
experimental code things can be a bit hacked*
Interpreter >>initVmStatsTraceMessageSendLevels
vmStatsTraceMessageSendLevels := 0.
vmStatsTraceMessageSendStorageFile := 0.
self cCode: ' {
void handleUSR1(int signal);
void handleUSR2(int signal);
signal(SIGUSR1, handleUSR1);
signal(SIGUSR2, handleUSR2);
}
}
#include <libc.h>
#include <signal.h>
void handleUSR1(int signal) {
foo->vmStatsTraceMessageSendLevels++;
}
void handleUSR2(int signal) {
foo->vmStatsTraceMessageSendLevels = 0;
if (foo->vmStatsTraceMessageSendStorageFile)
fclose(foo->vmStatsTraceMessageSendStorageFile);
foo->vmStatsTraceMessageSendStorageFile = 0;
'
On 30-Oct-05, at 10:21 AM, David T. Lewis wrote:
> On Sat, Oct 29, 2005 at 09:46:39PM -0700, John M McIntosh wrote:
>
>>
>> b) As an extra feature based on conversation with Michael at
>> breakfast this morning you can also do
>> under os-x (unix/darwin) a kill signal to turn recording on.
>>
>> kill -USR1 19278 {Pick a squeak VM process id}
>>
>> kill -USR1 19278 {increment the level by one, go to 2}
>> kill -USR1 19278 {increment the level by one, go to 3}
>>
>> kill -USR2 19278 {turn recording off, and close the file}
>>
>
> Hi John,
>
> Here's one additional suggestion. Rather than dedicating SIGUSR1
> and SIGUSR2 to this specific function, you can select what signals
> to use from the image, and also handle the signals in the image.
> The OSPP plugin provides the required signal forwarding primitives,
> so the idea would be to forward SIGUSR1 and SIGUSR2 (or whatever)
> to semaphores in the image, with processes waiting on the semaphores
> to do the #setVMStatsTraceMessageSendLevels: calls that control
> the trace logging.
>
> The reason this is important is that someone else may want to use
> SIGUSR1 and SIGUSR2 for some other purpose. For example, some pthread
> libraries on Linux make use of these signals, which would mean that
> a Linux VM that used pthreads might not work if you steal the signal
> handlers away from the pthreads library. I think that the svalib on
> Linux also uses these signals, which would affect somebody who wanted
> a VM on Linux that ran directly on the VGA display rather than on
> X window. And who knows about all the sound libraries and so forth.
> Also, somebody running a Seaside server might want to use SIGUSR1
> to signal the server to do an image save (just making this up as a
> possible example).
>
> Note: I'm afraid that I did not put convenience methods into OSPP for
> the SIGUSR1 and SIGUSR2 signals (but that's an easy fix), so you would
> need to specify the actual integer values 10 and 12, as in
>
> startTracingSemaphore := OSProcess accessor forwardSignal: 10.
> [[startTracingSemaphore wait.
> (traceLevel < 5) ifTrue:
> [traceLevel := traceLevel + 1.
> Smalltalk setVMStatsTraceMessageSendLevels: traceLevel]]
> repeat] fork
>
> The above is not tested, but you get the idea.
>
> And I should fix up OSP so you can say "OSProcess accessor
> forwardSigUsr1"
> instead of "OSProcess accessor forwardSignal: 10".
>
> Dave
>
>
>
>
>
--
========================================================================
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
========================================================================
===
More information about the Squeak-dev
mailing list
|