Re: [omr-dev] ResolvedMethod question

["Mark Stoodley" <mstoodle@xxxxxxxxxx>]

Note that a MethodBuilder object can live
longer than a compilation (it's the thing being compiled,
after all).

I would actually prefer that TR::ResolvedMethods
be confined to a compilation rather than being
"cached" in the MethodBuilder object. It would *probably* be
better if function name lookup worked
exclusively on demand using the RequestFunction
callback which is only called during a compilation.

But callbacks aren't popular with everyone,
I'm discovering :) .

Mark Stoodley		8200 Warden Avenue
Senior Software Developer		Markham, L6G 1C7
IBM Runtime Technologies		Canada
Phone:	+1-905-413-5831
e-mail:	mstoodle@xxxxxxxxxx
We cannot solve our problems with the same thinking we used when we created them - Albert Einstein

From:      
 "Irwin D'Souza"
<dsouzai@xxxxxxxxxx>
To:      
 omr developer discussions
<omr-dev@xxxxxxxxxxx>
Cc:      
 omr-dev-bounces@xxxxxxxxxxx
Date:      
 2018/06/14 11:15 AM
Subject:    
   Re: [omr-dev]
ResolvedMethod question
Sent by:    
   omr-dev-bounces@xxxxxxxxxxx

---

>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 assume you're referring to 

typedef TR::typed_allocator<std::pair<const char * const, TR::ResolvedMethod
*>, TR::Region &> FunctionMapAllocator;
typedef std::map<const char *, TR::ResolvedMethod *, StrComparator,
FunctionMapAllocator> FunctionMap;
FunctionMap _functions;

in which case, the TR::ResolvedMethod is allocated using trMemory()->heapMemoryRegion()

TR::ResolvedMethod *method = new (trMemory()->heapMemoryRegion()) TR::ResolvedMethod(
(char*)fileName,
(char*)lineNumber,
(char*)name,
numParms,
parmTypes,
returnType,
entryPoint,
0);

where 
trMemory() 
returns a pointr to a member of 
MemoryManager memoryManager

which gets destroyed when the MethodBuilder object is destroyed. So, the
lifetime of a ResolvedMethod, AFAICT, is within the scope of the compile.

Regards,

Irwin D'Souza
JIT Compiler Developer
IBM Runtime Technologies
Email: dsouzai@xxxxxxxxxx
Phone: 905-413-2956

Dibyendu
Majumdar ---06/13/2018 07:18:51 AM---Hi Leonardo, On 13 June 2018 at 01:58,
Leonardo <leonardo2718@xxxxxxxxxxxxxx> wrote:

From: Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>
To: Leonardo <leonardo2718@xxxxxxxxxxxxxx>, omr
developer discussions <omr-dev@xxxxxxxxxxx>
Date: 06/13/2018 07:18 AM
Subject: Re: [omr-dev] ResolvedMethod question
Sent by: omr-dev-bounces@xxxxxxxxxxx

---

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
_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev



_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev