August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Benjamin Thaut | On 8/21/2015 12:24 AM, Benjamin Thaut wrote:
> Export basically means "Make this function or class visible across
> shared library boundaries". I don't see how this connects to the object factory.
Object.factory() only has a point when it is used to instantiate classes in a DLL/so. It fits in nicely with export.
| |||
Permalink
ReplyAugust 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | Am Thu, 20 Aug 2015 23:16:10 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:
> On 8/20/2015 11:00 PM, Mike wrote:
> > Ideally it would be nice to only pull in those ModuleInfo instances that are actually needed in the program, and by association, only pull in those TypeInfo instances needed by the ModuleInfo. If no ModuleInfo is used, and the associated TypeInfo is also not used, then neither is pulled in.
>
> I do plan to do a review of ModuleInfo with this in mind, but not immediately.
>
Right now we use ModuleInfo to iterate all linked modules*. Keeping
modules but removing the ModuleInfo seems irreconcilable with that use case?
Of course completely removing a module could work.
*:
foreach(mod; ModuleInfo) is used in
* druntime to run unittests for all modules
* gdc druntime to find all modules with TLS variables for emulated TLS
support
* IIRC also somehow used in dynamic shared library loading/unloading?
| |||
August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Mike | Am Fri, 21 Aug 2015 11:03:00 +0000
schrieb "Mike" <none@none.com>:
> On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
> > On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
> >> Disabling TypeInfo forces one to compromise on slicing, postblit
> >
> > Why slicing and postblit would need typeinfo?
>
> See below for the source code. Some obvious, some not.
>
> * dynamic cast - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-83bcb64558f947e39f87d7435709dfe7R364 * array literal - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-bed7d2226948b1e098749985d7a60633R2353 * postblit - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR918 * destructor - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR1039, https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-867588d7078efd0364c256152fb5a2e7R2053 * new - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R5091 * AAs - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R10710 * slicing - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R11857
>
> etc...
>
> Disabling TypeInfo requires quite a compromise on D's features. I want TypeInfo, I just don't want dead code.
>
> Mike
>
>
It's been some time since I looked at this so I don't remember exactly how severe these limitations are. However, it should be noted that not all 'array literals', ... need TypeInfo, only a subset of them does. Some are fixable others (dynamic downcast) probably not.
| |||
August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Johannes Pfau | On 8/21/15 6:59 AM, Johannes Pfau wrote:
> Am Thu, 20 Aug 2015 23:16:10 -0700
> schrieb Walter Bright <newshound2@digitalmars.com>:
>
>> On 8/20/2015 11:00 PM, Mike wrote:
>>> Ideally it would be nice to only pull in those ModuleInfo instances
>>> that are actually needed in the program, and by association, only
>>> pull in those TypeInfo instances needed by the ModuleInfo. If no
>>> ModuleInfo is used, and the associated TypeInfo is also not used,
>>> then neither is pulled in.
>>
>> I do plan to do a review of ModuleInfo with this in mind, but not
>> immediately.
>>
>
> Right now we use ModuleInfo to iterate all linked modules*. Keeping
> modules but removing the ModuleInfo seems irreconcilable with that use case?
> Of course completely removing a module could work.
>
> *:
> foreach(mod; ModuleInfo) is used in
> * druntime to run unittests for all modules
> * gdc druntime to find all modules with TLS variables for emulated TLS
> support
> * IIRC also somehow used in dynamic shared library loading/unloading?
>
It's used to call static ctor/dtors as well.
I think for modules that have none of these features, you could omit the ModuleInfo.
-Steve
| |||
August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Mike | On 8/21/15 7:03 AM, Mike wrote: > On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote: >> On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote: >>> Disabling TypeInfo forces one to compromise on slicing, postblit >> >> Why slicing and postblit would need typeinfo? > > See below for the source code. Some obvious, some not. > > * dynamic cast - > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-83bcb64558f947e39f87d7435709dfe7R364 You need some static data to hold the vtable. I think typeinfo is fine to have for this, but I don't think it's actually necessary. > > * array literal - > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-bed7d2226948b1e098749985d7a60633R2353 > > * postblit - > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR918 > > * destructor - > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR1039, > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-867588d7078efd0364c256152fb5a2e7R2053 > > * new - > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R5091 > > * AAs - > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R10710 > > * slicing - > https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R11857 These are all runtime limitations rooted in legacy that could be lifted. If druntime was just hooks that the compiler called with the type as a template parameter, we could fix all this. -Steve | |||
August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Mike Attachments:
| On 21 August 2015 at 13:03, Mike via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> On Friday, 21 August 2015 at 08:11:37 UTC, Kagamin wrote:
>
>> On Friday, 21 August 2015 at 06:00:44 UTC, Mike wrote:
>>
>>> Disabling TypeInfo forces one to compromise on slicing, postblit
>>>
>>
>> Why slicing and postblit would need typeinfo?
>>
>
> See below for the source code. Some obvious, some not.
>
> * dynamic cast - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-83bcb64558f947e39f87d7435709dfe7R364 * array literal - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-bed7d2226948b1e098749985d7a60633R2353 * postblit - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR918 * destructor - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-1f51c84492753de4c1863d02e24318bbR1039,
>
> https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-867588d7078efd0364c256152fb5a2e7R2053 * new - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R5091 * AAs - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R10710 * slicing - https://github.com/D-Programming-GDC/GDC/pull/100/files?diff=unified#diff-5960d486a42197785b9eee4ba95c6b95R11857
>
> etc...
>
> Disabling TypeInfo requires quite a compromise on D's features. I want TypeInfo, I just don't want dead code.
>
>
Where removing RTTI disables D feature's in a compromising way, I'd start by questioning the why.
Eg: Why does array literals need RTTI? Looking at _d_arrayliteralTX implementation, it only does the following with the given TypeInfo provided:
- Get the array element size (this is known at compile time)
- Get the array element type flags (calculated during the codegen stage,
but otherwise known at compile time)
- Test if the TypeInfo is derived from TypeInfo_Shared (can be done at -
you guessed it - compile time by peeking through the baseClass linked list
for a given TypeInfo type we are passing).
So we have this function that accepts a TypeInfo, but doesn't really *need* to at all.
void* _d_arrayliteralTX(size_t length, size_t sizeelem, uint flags, bool
isshared);
Just putting it out there....
Iain.
| |||
August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Walter Bright | On 21-Aug-2015 13:44, Walter Bright wrote: > On 8/21/2015 12:24 AM, Benjamin Thaut wrote: >> Export basically means "Make this function or class visible across >> shared library boundaries". I don't see how this connects to the >> object factory. > > Object.factory() only has a point when it is used to instantiate classes > in a DLL/so. It fits in nicely with export. > Still abusing visibility keyword is probably bad idea, it's already tricky with private implying final or some such nonsense. Just add @ObjectFactory UDA to object.d and be done with it? -- Dmitry Olshansky | |||
August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | On 8/21/15 7:22 AM, Iain Buclaw via Digitalmars-d wrote:
> Where removing RTTI disables D feature's in a compromising way, I'd
> start by questioning the why.
>
> Eg: Why does array literals need RTTI? Looking at _d_arrayliteralTX
> implementation, it only does the following with the given TypeInfo provided:
>
> - Get the array element size (this is known at compile time)
> - Get the array element type flags (calculated during the codegen stage,
> but otherwise known at compile time)
> - Test if the TypeInfo is derived from TypeInfo_Shared (can be done at -
> you guessed it - compile time by peeking through the baseClass linked
> list for a given TypeInfo type we are passing).
>
> So we have this function that accepts a TypeInfo, but doesn't really
> *need* to at all.
>
> void* _d_arrayliteralTX(size_t length, size_t sizeelem, uint flags, bool
> isshared);
>
> Just putting it out there....
I strongly suggest we *don't* go this route. This means that any changes to what is required for the runtime to properly construct an array requires a compiler change.
A MUCH better solution:
T[] _d_arrayliteral(T)(size_t length)
Also, isn't the typeinfo now stored by the GC so it can call the dtor? Perhaps that is done in the filling of the array literal, but I would be surprised as this is a GC feature.
-Steve
| |||
August 21, 2015 Re: Object.factory() and exe file size bloat | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Steven Schveighoffer | On Friday, 21 August 2015 at 11:34:58 UTC, Steven Schveighoffer wrote: > A MUCH better solution: > > T[] _d_arrayliteral(T)(size_t length) It needs to be trivial wrapper which forwards to proposed > void* _d_arrayliteralTX(size_t length, size_t sizeelem, uint flags, bool > isshared); Otherwise you get another binary bloat issue. | |||
Copyright © 1999-2021 by the D Language Foundation