[erlang-questions] Erlang C NIF access to process struct

[Boshan Sun]

Yes Dmytro I've also enjoy reading your BEAM Wisdom series and Erik
Stenman's BEAM book. I think you guy's work are very good resource out
there for explaining BEAM, along with of course, the source code.

Mikael thanks for fixing those hipe_bifs:show_* functions, that would
really delight 64-bits Erlang users :)


2017-11-06 4:34 GMT-08:00 Mikael Pettersson <mikpelinux@REDACTED>:

> My PR should fix both issues with show_heap/1.  I wasn't aware the other
> show_* BIFs had issues, I may take a look at them soonish.
>
> There is no updated document for the tag scheme AFAIK, but reading
> erts/emulator/beam/erl_term.h should, if you can decipher all #ifdefs and
> macros, provide the current details.  The general principles remain the
> same, but new types and alternatives have appeared, and existing ones may
> have been reassigned.
>
> On Mon, Nov 6, 2017 at 4:55 AM, Boshan Sun <sunboshan@REDACTED> wrote:
>
>> Does your fix also fix the variable alignment issue as well? The variable
>> is in the beginning of the next row now, and should be in the end of same
>> row. Also can you fix hipe_bifs:show_estack/1, hipe_bifs:show_nstack/1,
>> hipe_bifs:show_pcb/1? They all suffer the "off" issue.
>>
>> BTW, I just read your paper *A Staged Tag Scheme for Erlang* and it
>> explains Erlang's tag scheme pretty well. Thanks for that. The paper was
>> written in 2000 for R6B/R7A, just wondering do you guys have some updated
>> paper regarding for current state of Erlang/OTP's tag scheme?
>>
>> Thanks!
>>
>> 2017-11-05 1:34 GMT-08:00 Mikael Pettersson <mikpelinux@REDACTED>:
>>
>>> The "off" table is due to a glitch in the output routine.  The too short
>>> "H  E A P" banner is indeed a 32-vs-64 bit bug.  I fixed both in
>>> https://github.com/erlang/otp/pull/1619.
>>>
>>> WRT accessing the current "struct process", I haven't looked in detail,
>>> but in general the NIF interface wants to abstract away representational
>>> details and replace them function calls (actual runtime function calls, not
>>> just function-like macros).  I don't see direct accesses to "struct
>>> process" fitting into that.
>>>
>>> On Sun, Nov 5, 2017 at 4:39 AM, Boshan Sun <sunboshan@REDACTED> wrote:
>>>
>>>> Hi all,
>>>>
>>>> In Erlang, you can use `hipe_bifs:show_heap(self()).` to debug the
>>>> process's heap.
>>>>
>>>> From: 0x000000001ee5c6e0 to 0x000000001ee5c748
>>>>  |         H E A P         |
>>>>  |            Address |           Contents |
>>>>  |--------------------|--------------------|
>>>> 4 | 0x000000001ee5c6e0 | 0x000000000000004f |
>>>> [] | 0x000000001ee5c6e8 | 0xfffffffffffffffb |
>>>> 3 | 0x000000001ee5c6f0 | 0x000000000000003f |
>>>> [4] | 0x000000001ee5c6f8 | 0x000000001ee5c6e1 |
>>>>  |--------------------|--------------------|
>>>>
>>>> However the implementation is for 32-bits machine, and the table is
>>>> kind of off for a 64-bits erlang.
>>>>
>>>> I want to write a C NIF to print similar heap information. What I need
>>>> is the address of `process -> heap` and the heap size so I can get the
>>>> heap's information.
>>>>
>>>> My question is, is there a way to get a pointer to the given process
>>>> via pid in C NIF?
>>>>
>>>> In NIF doc there's enif_get_local_pid
>>>> <http://erlang.org/doc/man/erl_nif.html#enif_get_local_pid> , how does
>>>> this pid translate to the process pointer?
>>>>
>>>> Thanks!
>>>>
>>>> Boshan
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171106/ace699d5/attachment.htm>