[Local GC] Move handle creation to IGCHandleTable#10757
[Local GC] Move handle creation to IGCHandleTable#10757adityamandaleeka merged 4 commits intodotnet:masterfrom
Conversation
|
|
||
| virtual void* GetHandleTableForHandle(OBJECTHANDLE handle); | ||
|
|
||
| virtual OBJECTHANDLE CreateHandleOfType(void* table, Object* object, int type); |
There was a problem hiding this comment.
Should the definition of OBJECTHANDLE be on the interface? I see it's defined in vars.hpp and gcenv.base.h today.
src/vm/appdomain.hpp
Outdated
| @@ -1323,7 +1326,9 @@ class BaseDomain | |||
| OBJECTHANDLE CreateDependentHandle(OBJECTREF primary, OBJECTREF secondary) | |||
| { | |||
| WRAPPER_NO_CONTRACT; | |||
There was a problem hiding this comment.
This isn't a wrapper anymore - can we use ::CreateDepehdentHandle's contract here?
fee973d to
dd86429
Compare
|
@dotnet-bot test Ubuntu arm Cross Release Build |
| return ::CreateTypedHandle(m_hHandleTableBucket->pTable[GetCurrentThreadHomeHeapNumber()], object, type); | ||
|
|
||
| IGCHandleTable *pHandleTable = GCHandleTableUtilities::GetGCHandleTable(); | ||
| return pHandleTable->CreateHandleOfType(m_hHandleTableBucket->pTable[GetCurrentThreadHomeHeapNumber()], OBJECTREFToObject(object), type); |
There was a problem hiding this comment.
HandleTableBucket seems to be implementation detail of the HandleTable. Shouldn't it move to the GC side as well?
Also, it does not look right that I have to call to GC two times to create the handle: first to get thread home number, and then to actually create the handle.
There was a problem hiding this comment.
Yes, that will be addressed in a future PR. The home heap number will not be exposed anymore.
|
LGTM - as an intermediate point. |
|
Thanks! |
dd86429 to
4475214
Compare
…table_local_gc_init [Local GC] Move handle creation to IGCHandleTable Commit migrated from dotnet/coreclr@d276140
This change adds handle creation functions to the IGCHandleTable interface, and modifies the VM to use the interface for handle creation rather than calling functions in objecthandle.h directly.
Rather than adding a separate function for each
Create__<type>__Handlefunction (of which there are many) to the interface, I consolidated them to a few major categories and added theCreate__<type>__Handlefunctions to a header on the VM side that will call the appropriate thing on the interface. This minimizes changes to VM source while also not adding clutter to the interface.I've also moved the handle-related code that was in gcheaputilities to its own file, since there is now a lot more code there.
Most of the handle creation functions are pretty straightforward, but there are a couple of interesting cases:
CreateDuplicateHandleentirely since it's only used in one place in the VM and instead modified the caller to achieve the same result with the other functionality we already have on the interface.CreateHandleWithExtraInfowhich takes avoid*that can be anything the user wants.CreateWinRTWeakHandleis now a convenience function that lives in the VM side and callsCreateHandleWithExtraInfowith theIWeakReferenceas the extra info.@Maoni0 @jkotas @swgillespie @sergiy-k