2

I was wondering about where the CLR allocates method table. We know that class object references hold on heap and stack points to them. But also, this object's method references allocated in somewhere called 'method table'.

As the title implies, I wonder this method table is another object that CLR manages in the heap or a completely different allocation zone.

Mert
  • 113
  • 1
  • 5
  • 4
    Why does it matter to you? Just checking whether this might be a XY Problem - https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem . – mjwills Jul 15 '19 at 12:31
  • heap and stack is going to be on ram mostly – Pranay Rana Jul 15 '19 at 12:32
  • 1
    @mjwills I just wanted to know how it works. – Mert Jul 15 '19 at 12:41
  • 1
    @PranayRana I know yes, but I meant somewhere individually partitioned in memory. Just like heap and stack. – Mert Jul 15 '19 at 12:47
  • @Mert - as per my reading it should be in AppDomain , as CLR put each application in separate AppDomain so other process should not affect or override or create problem – Pranay Rana Jul 15 '19 at 14:56
  • _"We know that class object references hold on heap and stack points to them"_ -- really? We do? Please document that claim. Because, last I checked, object references may be stored in both the stack and the heap, and in the latter this includes either the large-object heap, or one of the three generational heaps. As for the "method table" or "memory table" (which is it?), it's not even clear what data structure you're asking about. Are you looking for the virtual dispatch table ("v-table")? Some kind of map of memory? Given that this is an implementation detail, in what context do you care? – Peter Duniho Jul 15 '19 at 15:05
  • @PeterDuniho I am sorry my bad, I meant method table and edited the question thanks for that. Though, I guess method table is the same thing as virtual method table right ? Additionally, yes references can be stored in the heap but I was mentioning about primal objects such as an integer, of course it can also be stored in heap but not by default, as far as I am aware. – Mert Jul 15 '19 at 16:58
  • _" I was mentioning about primal objects such as an integer, of course it can also be stored in heap but not by default"_ -- do you mean "primitive types"? The type of the object has _nothing_ to do with where the value is stored. Sadly, this is a common misconception, held by people who are too willing to accept rumor as fact. Try reading this: https://stackoverflow.com/questions/2559271/are-these-objectss-references-on-the-stack-or-on-the-heap – Peter Duniho Jul 15 '19 at 17:02
  • @PeterDuniho you know what, you are right.I meant structs but depending on the situation, structs can be allocated in stack as well, e.g. a local variable. https://stackoverflow.com/questions/203695/does-using-new-on-a-struct-allocate-it-on-the-heap-or-stack/203783#203783 Anyway, sadly I didn't have a clarification on method table's memory management. Is it something in heap or stack, its still a limbo. – Mert Jul 15 '19 at 17:58
  • Stack variables are ephemeral, so it wouldn't make any sense for a vtable to be allocated on the stack. Frankly, I find your question confusing. I don't understand why you think there's any chance at all that the vtable might be on the stack, nor do I understand what _practical_ problem is addressed by knowing where the vtable is stored ("practicality" being a requirement for on-topic SO questions). Vtables in managed code work very much like those in unmanaged code, which means it's unlikely the vtable is stored in the main heap either. See https://stackoverflow.com/questions/2413483 – Peter Duniho Jul 15 '19 at 18:05
  • @PeterDuniho So all methods are getting called using vtable then? That was the confusion that I had, because some functions are not virtual. So that was part which was confusing me. – Mert Jul 15 '19 at 18:14
  • 2
    No. Non-virtual methods are called without the benefit of a vtable. In fact, in some cases the compiler can determine the exact method to call at compile time, and even those calls will bypass the vtable. What all that has to do with _where_ the vtable is stored, still eludes me. – Peter Duniho Jul 15 '19 at 18:16
  • 1
    The CLR maintains a bunch of internal heaps, one of these stores the method tables. Literature generally refers to it by the name "loader heap". – Hans Passant Aug 07 '19 at 12:55

0 Answers0