Re: [omr-dev] ResolvedMethod question

[Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>]

Hi Leonardo,

On 13 June 2018 at 01:58, Leonardo <leonardo2718@xxxxxxxxxxxxxx> wrote:

>> On 11 June 2018 at 21:01, Dibyendu Majumdar mobile@xxxxxxxxxxxxxxx wrote:
>>
>> > I am looking at how to register foreign functions or call a function
>> > via pointer. Looking at MethodBuilder and ThunkBuilder I can see that
>> > to call a function an instance of ResolvedMethod is needed. How is the
>> > ResolvedMethod linked to the Code Cache? Is it stored anywhere - or is
>> > it just an interface that must be defined for any callable function? I
>> > presume that the list of foreign functions can be simply maintained by
>> > the front-end?
>> >
>
> The simple answer is that `TR::ResolvedMethod` is just the interface used to define a callable function. The compiler uses it to "construct" calls. If you haven't already done so, I would recommend taking a look at the implementations of MethodBuilder::DefineFunction(), IlBuilder::Call(), IlBuilder::ComputedCall(), and IlBuilder::genCall().

Okay. I am not 100% sure of the lifetime of a ResolvedMethod. I see
that in JitBuilder the ResolvedMethod instances are put into a map -
presumably these are tied to the lifetime of the Code Cache?

I have been looking at how calls are implemented and noticed that
arguments are promoted to machine Word size. Make sense but I didn't
see how floating point values are handled as the code seems to deal
with integer case only?

>
> As a side note, when discussing "ResolvedMethod", it's important to distinguish between `TR::ResolvedMethod` and `TR_ResolvedMethod`. Sadly, both of these classes exist and are, in fact, different. I believe you only need to worry about `TR::ResolvedMethod`, at least for now. Just something to look out for when reading the code :-)

Okay thank you for alerting me to this; I wasn't aware of it.

>>
>> With regards to the question below - I have an additional question
>> regarding memory and lifetimes. It seems that ResolvedMethod
>> implementation accepts various pointers and holds on to them. But
>> presumably does not free them as far as I can tell. What is the
>> assumption here with regards to memory management?
>
> Internally, the OMR compiler uses a custom memory manager to handle all allocation/deallocations (see https://github.com/eclipse/omr/blob/master/doc/compiler/memory/MemoryManager.md). As such, most (all?) APIs assume that any memory accessed using pointers is already managed and will not take ownership of it. So, to answer your question more directly, the pointers you provide a ResolvedMethod will not be freed. The memory for these pointers can be allocated/freed using the compiler's internal memory manager, but doing so is not required.
>

Okay. I am finding the memory management interface somewhat confusing
- so I have ended up using standard C++ for now. I saw the doc memory
management but there is not real examples given on how to use it.

Thanks for all the help.

Regards
Dibyendu