Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [omr-dev] ResolvedMethod question

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


Inactive hide details for Dibyendu Majumdar ---06/13/2018 07:18:51 AM---Hi Leonardo, On 13 June 2018 at 01:58, Leonardo <leonarDibyendu 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




Back to the top