Can K/N maintains compact binary size like C++ does (when K/N reflection is disable)? The TypeInfo ...

# kotlin-native

[Landerl Young]

Can K/N maintains compact binary size like C++ does (when K/N reflection is disable)?

The TypeInfo struct has lots of fields:

struct TypeInfo {
    const TypeInfo* typeInfo_;
    ClassNameHash name_;
    int32_t instanceSize_;
    const TypeInfo* superType_;
    const int32_t* objOffsets_;
    int32_t objOffsetsCount_;
    const TypeInfo* const* implementedInterfaces_;
    int32_t implementedInterfacesCount_;
    const MethodTableRecord* openMethods_;
    uint32_t openMethodsCount_;
    const FieldTableRecord* fields_;
    int32_t fieldsCount_;
    ObjHeader* packageName_;
    ObjHeader* relativeName_;
    int32_t flags_;
    const ExtendedTypeInfo* extendedInfo_;
};

So, which of them are related to reflection, which are not.

AFAIK:
1. supreType_ and implementedInterfaces_ are useful for runtime type cast check.
2. vtable (not listed but comes after the TypeInfo struct) is useful for virtual methods calling.
3. openMethods_ is useful for interface method calling.

But some of the rest fields like packageName_, relativeName_, name_, instanceSize_, objOffsets_, fields_, etc. seem to be reflection related? Should they be moved into ExtendedTypeInfo so them can be omitted when reflection is disabled?

May I get your help @olonho ? Thanks.😀

[olonho]

instanceSize_, objOffsets are used in memory manager, and we generally assume that knowing object’s full class name is valuable enough to always keep this info

[olonho]

reflection is not supported in K/N, BTW

[Landerl Young]

Thanks for the reply.🎉
But how about fields_, I see there is a LookupFieldOffset method but didn’t find any one calling it?

[Landerl Young]

And further more, will K/N plain to support reflection in the future?

[olonho]

fields shalln't take much space, but indeed shall be removed. Java-style reflection is not planned.

[Landerl Young]

Thanks~ helps a lot!