Re: C API to check VM is running?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: C API to check VM is running?
- From: Sean Conner <sean@...>
- Date: Mon, 9 Sep 2019 23:09:12 -0400
It was thus said that the Great Xin Zhao once stated:
> thank you for your reply.
> I read your blog and code carefully. It made me learn a lot.
>
> Yes, using signal functions is very dangerous, but read the source
> code, lua_sethook is safe to be called in signals. so I used it.
I'm wondering why you are using signals for this. I know on Linux, you
can link a program with the "-pg" options to generate an executable that can
be run to generate profile information. On the Mac and Solaris (and I
believe FreeBSD), you don't even need to do that as you can use dtrace to
profile any arbitrary program. And I'm sure there are ways of profiling
under Windows (although I am not familiar with Windows).
In my experience, signal handlers are not worth the effort.
> /*
> ** This function can be called asynchronously (e.g. during a signal).
> ** Fields 'oldpc', 'basehookcount', and 'hookcount' (set by
> ** 'resethookcount') are for debug only, and it is no problem if they
> ** get arbitrary values (causes at most one wrong hook call). 'hookmask'
> ** is an atomic value. We assume that pointers are atomic too (e.g., gcc
> ** ensures that for all platforms where it runs). Moreover, 'hook' is
> ** always checked before being called (see 'luaD_hook').
> */
> LUA_API void lua_sethook (lua_State *L, lua_Hook func, int mask, int count) {
>
> My goal is to only analyze lua code hotspots.
> And the reason why I did not use lua debug sampling is because 90% of
> the code in our program is lua, and lua also calls many bound C++
> functions.
> The problem with lua debug is slow and inaccurate, because the
> execution time of each instruction is different.
A hot spot will show up regardless of frequency of sample. Yes, profiling
code may slow it down, but the profiling overhead isn't counted when
profiling. As I mentioned in my post
http://boston.conman.org/2019/08/21.1
I used a rather large timing interval at first, and the hot spot jumped out.
When I ran it with an interval that was 1/10th the size (10 times more
frequently) the hot stop didn't change.
> It may take more time
> to run 1 instructions than 100 instruction, such as calling a bound
> C++ function to write a file.
I only wrote the output at the end of the run, not as it was running.
> Currently this profiling tool is running well, of course, as you see,
> the code below is bad, and may be only work at my machine.
>
> unsigned short nny = *(unsigned short *)((char*)L+196);
> unsigned short nCcalls = *(unsigned short *)((char*)L+198);
>
> so may be it would be better if there is a C API here. to check lua VM
> is running.
Include lstate.h so you don't have to manually calculate the offsets.
-spc