[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Iain Buclaw  changed:

   What|Removed |Added

 CC|ibuc...@gdcproject.org  |

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4
 CC||ibuc...@gdcproject.org
   Severity|regression  |enhancement

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P4  |P1
   Severity|enhancement |regression

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Shriramana Sharma  changed:

   What|Removed |Added

 CC||samj...@gmail.com

--

Re: Why do static arrays affect executable size?

[Bastiaan Veelo via Digitalmars-d-learn]

Thanks for the clarifications.

Re: Why do static arrays affect executable size?

[Bastiaan Veelo via Digitalmars-d-learn]

On Saturday, 11 February 2017 at 00:16:04 UTC, sarn wrote:
If you explicitly initialise the array to all 0.0, you should 
see it disappear from the binary.


I was actually wondering whether initialisation would make a 
difference, so thank you for this.


Bastiaan.

Re: Why do static arrays affect executable size?

[sarn via Digitalmars-d-learn]

On Friday, 10 February 2017 at 15:12:28 UTC, Jonathan M Davis 
wrote:
Module-level and static variables all get put in the 
executable. So, declaring a static array like that is going to 
take up space. A dynamic array would do the same thing if you 
gave it a value of that size. The same thing happens with 
global and static variables in C/C++.


An important difference with C/C++ in this case is that D floats 
are initialised to NaN, not 0.0.  In binary (assuming IEEE 
floating point), 0.0 has an all-zero representation, but NaNs 
don't.  Therefore, in C/C++ (on most platforms), 
default-initialised floats can be allocated in the BSS segment, 
which doesn't take up executable space, but in D, 
default-initialised floats have to be put into the compiled 
binary.


If you explicitly initialise the array to all 0.0, you should see 
it disappear from the binary.

Re: Why do static arrays affect executable size?

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, February 10, 2017 11:21:48 Bastiaan Veelo via Digitalmars-d-learn 
wrote:
> // enum int maxarray = 0;
> enum int maxarray = 2_000_000;
>
> double[maxarray] a, b, c, d;
>
> void main() {}
>
>
> Compiled using "dub build --arch=x86_64 --build=release" on
> Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592
> bytes v.s. 64_302_592 bytes, depending on the array length.
>
> Is that normal?

Module-level and static variables all get put in the executable. So,
declaring a static array like that is going to take up space. A dynamic
array would do the same thing if you gave it a value of that size. The same
thing happens with global and static variables in C/C++.

Similarly, even with a local variable that's a static or dynamic array, if
you use a literal to initialize it, that literal has to be put in the
executable, increasing its size. But the nature of module-level or global
variables is such that even if they're not explicitly assigned a value, they
take up space.

- Jonathan M Davis

Re: Why do static arrays affect executable size?

[Stefan Koch via Digitalmars-d-learn]

On Friday, 10 February 2017 at 11:21:48 UTC, Bastiaan Veelo wrote:

// enum int maxarray = 0;
enum int maxarray = 2_000_000;

double[maxarray] a, b, c, d;

void main() {}


Compiled using "dub build --arch=x86_64 --build=release" on 
Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592 
bytes v.s. 64_302_592 bytes, depending on the array length.


Is that normal?


Yes.

Why do static arrays affect executable size?

[Bastiaan Veelo via Digitalmars-d-learn]

// enum int maxarray = 0;
enum int maxarray = 2_000_000;

double[maxarray] a, b, c, d;

void main() {}


Compiled using "dub build --arch=x86_64 --build=release" on 
Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592 
bytes v.s. 64_302_592 bytes, depending on the array length.


Is that normal?

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/



looks like this commit more than doubled the size of hello world

https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 09:27:56 UTC, Joakim wrote:
Another check that would be more worthwhile but harder to 
measure would be speed of compilation of druntime/phobos, 
especially since speed of compilation is considered a key 
selling point of D.  Harder to measure because it depends on 
what else is going on on that machine, but with some care and 
enough samples, you could get something representative.


Compilation/linking time are measured for the sample programs.

Re: hello world executable size

[rsw0x via Digitalmars-d]

On Sunday, 28 June 2015 at 10:06:20 UTC, Joakim wrote:
On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev 
wrote:

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
looks like this commit more than doubled the size of hello 
world


https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?


I didn't get that either, maybe he meant the PR that yours 
fixed is the one that doubled it?


it's the PR that's linked when I zoomed in on executable size in 
'Hello World'. It's not visible at first(I guess because the PR 
is so new?,) you have to zoom in once or twice.


I guess a picture is worth a thousand words. 
http://i.imgur.com/p0r5tFH.png

Re: hello world executable size

[Joakim via Digitalmars-d]

On Sunday, 28 June 2015 at 10:11:08 UTC, Vladimir Panteleev wrote:
No, he's right. Removing the import doubled the filesize of a 
helloworld binary.


Ah, I didn't want to download the full 90 MBs graph data again to 
see it.  Yes, I see it now.


On Sunday, 28 June 2015 at 09:58:35 UTC, Vladimir Panteleev 
wrote:
It's not really possible to meaningfully track such an 
inaccurate statistic on a per-commit basis. See it yourself - 
select one of the time tests in AWSY and zoom in. It works in 
aggregate - when zoomed out, you see the medians and can get 
the general big picture. But when comparing any two commits 
directly, there is just too much error.


Seems pretty stable to me, almost as much as file size even, 
which is surprising.  I did note that you'd have to be careful to 
measure it on a relatively unloaded machine and average multiple 
runs, but I don't see why it couldn't be done.  There is some 
variability on some of those, but as long as you didn't overreact 
on small changes and maybe compared one PR's results to averaged 
past data, ie over multiple PRs, as the baseline, it should work.

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 10:37:15 UTC, Joakim wrote:
On Sunday, 28 June 2015 at 10:11:08 UTC, Vladimir Panteleev 
wrote:
No, he's right. Removing the import doubled the filesize of a 
helloworld binary.


Ah, I didn't want to download the full 90 MBs graph data again 
to see it.  Yes, I see it now.


It's only about 5 MB compressed. Some browsers show the 
decompressed size.

Re: hello world executable size

[Joakim via Digitalmars-d]

On Thursday, 25 June 2015 at 12:15:26 UTC, Joakim wrote:
On Thursday, 25 June 2015 at 12:04:26 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote:
Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over 
the years. :) Anyway, I saw that viewer when you announced it 
before: any plans to add it to the github PR checks, along 
with your recent check for documentation info?


Would you believe me if I said that this obvious (in 
retrospect) idea hasn't crossed my mind yet?


I figured that's where you were going when you announced it. :)


Another check that would be more worthwhile but harder to measure 
would be speed of compilation of druntime/phobos, especially 
since speed of compilation is considered a key selling point of 
D.  Harder to measure because it depends on what else is going on 
on that machine, but with some care and enough samples, you could 
get something representative.

Re: hello world executable size

[Joakim via Digitalmars-d]

On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev wrote:

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
looks like this commit more than doubled the size of hello 
world


https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?


I didn't get that either, maybe he meant the PR that yours fixed 
is the one that doubled it?


On Sunday, 28 June 2015 at 09:58:35 UTC, Vladimir Panteleev wrote:

On Sunday, 28 June 2015 at 09:27:56 UTC, Joakim wrote:
Another check that would be more worthwhile but harder to 
measure would be speed of compilation of druntime/phobos, 
especially since speed of compilation is considered a key 
selling point of D.  Harder to measure because it depends on 
what else is going on on that machine, but with some care and 
enough samples, you could get something representative.


Compilation/linking time are measured for the sample programs.


Yeah, I saw that, but I was talking about adding a github check 
for D PRs and how they affect compilation speed, especially for 
dmd PRs.  Druntime/Phobos and eventually ddmd may not be the best 
way to check it, but it's the closest lamppost. ;)


Smaller binary size is nice to have, but not that important, 
especially since we've been neglecting it for some time now.


Compilation speed is something we're always trumpeting, we better 
track it.

Re: hello world executable size

[rsw0x via Digitalmars-d]

On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/



looks like this commit more than doubled the size of hello world

https://github.com/D-Programming-Language/phobos/pull/3443

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 28 June 2015 at 10:06:20 UTC, Joakim wrote:
On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev 
wrote:

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote:
looks like this commit more than doubled the size of hello 
world


https://github.com/D-Programming-Language/phobos/pull/3443


Woah. Why would removing an import increase the filesize?


I didn't get that either, maybe he meant the PR that yours 
fixed is the one that doubled it?


No, he's right. Removing the import doubled the filesize of a 
helloworld binary.


On Sunday, 28 June 2015 at 09:58:35 UTC, Vladimir Panteleev 
wrote:

On Sunday, 28 June 2015 at 09:27:56 UTC, Joakim wrote:
Another check that would be more worthwhile but harder to 
measure would be speed of compilation of druntime/phobos, 
especially since speed of compilation is considered a key 
selling point of D.  Harder to measure because it depends on 
what else is going on on that machine, but with some care and 
enough samples, you could get something representative.


Compilation/linking time are measured for the sample programs.


Yeah, I saw that, but I was talking about adding a github check 
for D PRs and how they affect compilation speed, especially for 
dmd PRs.  Druntime/Phobos and eventually ddmd may not be the 
best way to check it, but it's the closest lamppost. ;)


Smaller binary size is nice to have, but not that important, 
especially since we've been neglecting it for some time now.


Compilation speed is something we're always trumpeting, we 
better track it.


It's not really possible to meaningfully track such an inaccurate 
statistic on a per-commit basis. See it yourself - select one of 
the time tests in AWSY and zoom in. It works in aggregate - when 
zoomed out, you see the medians and can get the general big 
picture. But when comparing any two commits directly, there is 
just too much error.

Re: hello world executable size

[Joakim via Digitalmars-d]

On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/


Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over the 
years. :) Anyway, I saw that viewer when you announced it before: 
any plans to add it to the github PR checks, along with your 
recent check for documentation info?


I used nm to try and find some of the symbols using the most 
space (command taken from SO):


http://thecybershadow.net/d/mapview/


Does it show sizes somewhere?  Here's the dependency list for my 
binary:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html

It also shows that the relevant setter calling GcPolicy.realloc 
isn't used anywhere:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html#_D3std3uni32__T8CowArrayTS3std3uni8GcPolicyZ8CowArray6lengthMFNaNbNdNekZv

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/

I used nm to try and find some of the symbols using the most 
space (command taken from SO):


http://thecybershadow.net/d/mapview/

hello world executable size

[Joakim via Digitalmars-d]

I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better and 
make them more selective:


https://github.com/D-Programming-Language/phobos/pulls?utf8=%E2%9C%93q=is%3Apr+author%3A9il+clean

Hello world (void main(){ import std.stdio; writefln(hello 
roboto); }) size went from 464 KB to 548 KB when going from 
2.066.1 to 2.067.1 on linux/x86, an increase of 18% (dmd -O 
-release main.d).  I used nm to try and find some of the symbols 
using the most space (command taken from SO):


nm -B -r --size-sort --print-size -t d main

I noticed that the symbol taking up the third-most space was 
_d_arraysetlengthT, which wasn't in the older executable 
generated by 2.066.1.  Disassembling the newer executable 
(objdump -rD main), it appears that it's called from exactly one 
function, std.uni.GcPolicy.realloc, which is in turn only called 
from one templated struct's member function, 
std.uni.CowArray.length.  That instantiated function isn't called 
from anywhere else in the binary.


The templated struct std.uni.CowArray is only instantiated by the 
templated struct std.uni.InversionList in the source, but I'm not 
sure why neither is instantiated in the older executable and a 
diff of the two versions of std.stdio doesn't produce anything 
that stands out.  None of this appears to be used when the binary 
is run, as having gdb break on _d_arraysetlengthT does nothing.


But std.uni isn't actually imported directly by std.stdio, where 
does it come from?  Nearest I can tell from adding the -v flag to 
dmd, std.stdio has a couple scoped, selective imports to some 
functions from std.utf.  std.utf has exactly _one_ scoped, 
selective import of std.string.format in its UTFException class, 
and std.string has several selective imports from std.uni, 
including one at module scope.


I tried commenting out that single selective import of 
std.string.format in std.utf and the same binary compiled and ran 
fine without any imports of std.string or std.uni, plus it was 
now 36 KB smaller. :)


I realize executable size may not be a priority, but this 
exploration shows how easy it is to get a bunch of template 
garbage pulled in to executables (I know this is not news for 
some).  Perhaps the binary would have been twice as big if not 
for Ilya's work!  Maybe this isn't considered something that 
should be fixed at the compiler level, but rather by properly 
working with the linker to remove these, as David did with 
--gc-sections for ldc.  Either way, some kind of dashboard that 
charts binary sizes for dmd PRs can't come soon enough, so we can 
keep better tabs on this.

Re: hello world executable size

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote:
On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote:
I was curious if binary sizes had decreased because of the 
changes Ilya had been making to try and scope imports better 
and make them more selective:


http://digger.k3.1azy.net/trend/


Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over the 
years. :) Anyway, I saw that viewer when you announced it 
before: any plans to add it to the github PR checks, along with 
your recent check for documentation info?


Would you believe me if I said that this obvious (in retrospect) 
idea hasn't crossed my mind yet?


Does it show sizes somewhere?  Here's the dependency list for 
my binary:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html


Try the treemap form (above the dependency explorer form).

Re: hello world executable size

[Joakim via Digitalmars-d]

On Thursday, 25 June 2015 at 12:04:26 UTC, Vladimir Panteleev 
wrote:

On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote:
Took 90 MiB of JSON to see it, but finally got it, funny how 
executable size swings wildly up to five times larger over the 
years. :) Anyway, I saw that viewer when you announced it 
before: any plans to add it to the github PR checks, along 
with your recent check for documentation info?


Would you believe me if I said that this obvious (in 
retrospect) idea hasn't crossed my mind yet?


I figured that's where you were going when you announced it. :)

Does it show sizes somewhere?  Here's the dependency list for 
my binary:


http://thecybershadow.net/d/mapview/data/558be3dfde121.html


Try the treemap form (above the dependency explorer form).


I didn't know how to generate the .map file, I now see it's 
mentioned on the wiki:


http://wiki.dlang.org/Development_tools#File_size_profiling

Looks nice:

http://thecybershadow.net/d/mapview/view.php?id=558bef76234eb

Surprising that core.* and gc.* are almost as large as std.*, but 
I guess hello world isn't going to exercise that much of 
phobos. :)

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9660

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

  Component|Optlink |tools

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599
Issue 14599 depends on issue 14539, which changed state.

Issue 14539 Summary: +508KB (684KB - 1191KB) filesize increase Hello, world 
binary
https://issues.dlang.org/show_bug.cgi?id=14539

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Vladimir Panteleev thecybersha...@gmail.com changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|issues.dl...@jmdavisprog.co
   ||m

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

--- Comment #1 from Jonathan M Davis issues.dl...@jmdavisprog.com ---
Lovely. This sort of thing makes it very annoying to add any functionality
that's even vaguely related to writeln, and we never organized the modules in
Phobos with the idea of minimizing what got pulled in in order to do

writeln(hello world);

Some work has been done to minimize how much the various pieces of Phobos
depend on each other, but to a great extent it's unfixable without breaking
existing code, and often, avoiding dependencies makes it a lot harder to add
new functionality. :|

--

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

 Depends on||14539

--

[Issue 14599] New: Re-add scratchFile after executable size regression has been fixed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14599

  Issue ID: 14599
   Summary: Re-add scratchFile after executable size regression
has been fixed
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: Phobos
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

See https://github.com/D-Programming-Language/phobos/pull/3273.

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #13 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/239394c6ea98a281c51f95977612cc41866f0b4f
Merge pull request #3778 from MartinNowak/fix13117

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #10 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f8bcda05a8193c4180815d067713cf4b6e7884bf
fix Issue 13117 - Executable size of hello world explodes from 472K to 2.7M

- This problem seems to stem from mixed writeable flags for the
  .deh/.minfo sections in PIC/non-PIC code. The ld.bfd linker would
  still try to bracket the sections, even though it previously mapped
  them to different segments, thereby creating one huge segment which
  contains all read-only and all writeable data plus the big hole in
  between them.

- fixed by always marking those sections as writeable

https://github.com/D-Programming-Language/dmd/commit/5f3a83a890a3e3f106e89d5423993eae9945dc3b
Merge pull request #3778 from MartinNowak/fix13117

fix Issue 13117 - Executable size of hello world explodes from 472K to 2.7M

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #11 from Martin Nowak c...@dawg.eu ---
The resolution of this bug implies that the libphobos2.a we're shipping is
build with -fPIC. See issue 13149.

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #12 from github-bugzi...@puremagic.com ---
Commit pushed to 2.066 at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/239394c6ea98a281c51f95977612cc41866f0b4f
Merge pull request #3778 from MartinNowak/fix13117

fix Issue 13117 - Executable size of hello world explodes from 472K to 2.7M

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #7 from Martin Nowak c...@dawg.eu ---
Doesn't happen with PIC code either.
dmd -fPIC main

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

   Keywords||pull

--- Comment #8 from Martin Nowak c...@dawg.eu ---
This problem seems to stem from mixed writeable flags for the
.deh/.minfo sections in PIC/non-PIC code. The ld.bfd linker would
still try to bracket the sections, even though it previously mapped
them to different segments, thereby creating one huge segment which
contains all read-only and all writeable data plus the big hole in
between them.

https://github.com/D-Programming-Language/dmd/pull/3778

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #9 from Martin Nowak c...@dawg.eu ---
Bug was introduced with https://github.com/D-Programming-Language/dmd/pull/3187
which fixed Issue 11171 - Text relocations in Phobos shared library.

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #6 from Martin Nowak c...@dawg.eu ---
Only happens with ld.bfd (my version is 2.23.2). For some reason the output
file contains a single RWE segment with .text and .bss.
This also only happens with the libphobos2.a of the distributed binary. I
cannot reproduce the issue when building libphobos2.a myself.

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #4 from dbr dbugrepor...@gmail.com ---
Ok here's more info then:

% uname -a
Linux laptop 3.11.0-20-generic #35-Ubuntu SMP Fri May 2 21:32:49 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux

% file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.24,
BuildID[sha1]=0x6dbff8d6e93645b94b809ad602141ecf49ed261c, not stripped

% objdump -h hello | egrep -v 'CONTENTS|ALLOC'

hello: file format elf64-x86-64

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .interp   001c  00400200  00400200  0200  2**0
  1 .note.ABI-tag 0020  0040021c  0040021c  021c  2**2
  2 .note.gnu.build-id 0024  0040023c  0040023c  023c 
2**2
  3 .gnu.hash 3574  00400260  00400260  0260  2**3
  4 .dynsym   b6a0  004037d8  004037d8  37d8  2**3
  5 .dynstr   0001eb0b  0040ee78  0040ee78  ee78  2**0
  6 .gnu.version  0f38  0042d984  0042d984  0002d984  2**1
  7 .gnu.version_r 0090  0042e8c0  0042e8c0  0002e8c0  2**3
  8 .rela.dyn 0168  0042e950  0042e950  0002e950  2**3
  9 .rela.plt 0648  0042eab8  0042eab8  0002eab8  2**3
 10 .init 001a  0042f100  0042f100  0002f100  2**2
 11 .plt  0440  0042f120  0042f120  0002f120  2**4
 12 .text 00026f12  0042f560  0042f560  0002f560  2**4
 13 .fini 0009  00456474  00456474  00056474  2**2
 14 .rodata   52b0  00456480  00456480  00056480  2**4
 15 .deh_eh   02d0  0045b730  0045b730  0005b730  2**3
 16 .minfo0108  0045ba00  0045ba00  0005ba00  2**3
 17 .eh_frame_hdr 003c  0045bb08  0045bb08  0005bb08  2**2
 18 .eh_frame 00e4  0045bb48  0045bb48  0005bb48  2**3
 19 .tdata0010  0065cbe0  0065cbe0  0025cbe0  2**4
 20 .tbss 0040  0065cbf0  0065cbf0  0025cbf0  2**4
 21 .init_array   0010  0065cbf0  0065cbf0  0025cbf0  2**3
 22 .fini_array   0020  0065cc00  0065cc00  0025cc00  2**3
 23 .jcr  0008  0065cc20  0065cc20  0025cc20  2**3
 24 .data.rel.ro  4170  0065cc30  0065cc30  0025cc30  2**4
 25 .dynamic  0200  00660da0  00660da0  00260da0  2**3
 26 .got  0060  00660fa0  00660fa0  00260fa0  2**3
 27 .got.plt  0230  00661000  00661000  00261000  2**3
 28 .data 6770  00661230  00661230  00261230  2**4
 29 .bss  0730  006679a0  006679a0  002679a0  2**4
 30 .comment  0071      002679a0  2**0

The sizes of all sections amount to 0x66fad which is only 421805 bytes. The
rest of the 2.7 megabytes seem to be between sections .eh_frame and .tdata.

What could be there?

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #5 from dbr dbugrepor...@gmail.com ---
Looked with xxd, there's nothing but a bunch of zeros between those sections.

--

[Issue 13117] New: Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

  Issue ID: 13117
   Summary: Executable size of hello world explodes from 472K to
2.7M
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: dbugrepor...@gmail.com

Compiled with dmd_2.066.0~b3-0_amd64 (or ~b2) hello world executable becomes
2.7 megabytes while with 2.065 it's 472 kilobytes.

import std.stdio;
void main() {
writeln(hello);
}

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #1 from Kenji Hara k.hara...@gmail.com ---
Issue does not occur in Windows platform.

-m32
With git head: 145,436 bytes
With 2.065:138,268 bytes

-m64
With git head: 259,584 bytes
With 2.065:257,536 bytes

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright bugzi...@digitalmars.com ---
Not again! Dammit, this should be tested for in the autotester suite.

--

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13117

--- Comment #3 from Walter Bright bugzi...@digitalmars.com ---
I just tried this, and am seeing 394,000 size executables. I cannot reproduce
your results.

--

[Issue 9660] New: [meta] Not able to debug on Windows starting from ~10 MiB executable size

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9660

   Summary: [meta] Not able to debug on Windows starting from ~10
MiB executable size
   Product: D
   Version: D2
  Platform: All
OS/Version: Windows
Status: NEW
  Severity: blocker
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
Depends on: 6144


--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-07 
15:09:10 MSK ---
Starting from ~10 MiB executable (with debug info included) OPTLINK Issue 6144
is triggered so one have to develop further without debug info which is really
pity expecially as it starts when the project is already has medium size.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9660



--- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-07 
15:10:12 MSK ---
Some magic like separating a part of the project into a library may or may not
help.

Eliminating use of templates often helps. E.g. one should always append
`.array()` after (finite) range based operations and then pass an array to a
regular (non-templated) function instead of passing Voldemort types to a
templated function.

Another workaround is temporary commenting out some functions which uses
templates (e.g. from `std.algorithm`) to debug other functions.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9660


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||andrej.mitrov...@gmail.com
 Resolution||INVALID


--- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-03-07 
18:33:01 PST ---
Why did you open this if it's about Issue 6144? Keep issues about actual bugs
and not discussions about other issues.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9660



--- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-08 
08:49:14 MSK ---
(In reply to comment #2)
 Why did you open this if it's about Issue 6144? Keep issues about actual bugs
 and not discussions about other issues.

IMHO it's a separate and valuable issue which will be fixed if Issue 6144 will
but may be (probably) fixed also in a different way.

Yes, fill free to mark it INVALID if you sure I'm obviously incorrect.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

Re: Executable size when compiling with GDC

[Andrea Fontana]

You can try upx too :)

Il giorno mar, 21/02/2012 alle 16.43 +0100, Mars ha scritto:

 On Tuesday, 21 February 2012 at 13:19:11 UTC, Andrea Fontana 
 wrote:
  Have you tried to strip executable using --strip or --strip-all?
 
 Down to 1 MB, a good start, thanks. I guess that's more bearable.

Re: Executable size when compiling with GDC

[Dmitry Olshansky]

On 21.02.2012 16:51, Mars wrote:

Hello everybody.

Today I've tested GDC (on Windows), and a simple Hello World program
results in a 5 MB exe file, while it's only about 200 KB with DMD. Is
this normal? What does GDC (GCC?) put in there, to make it so big, and why?

Mars


I recall debug builds with MinGW GCC on windows are also enormous. Try 
release vs debug.


--
Dmitry Olshansky

Executable size when compiling with GDC

[Mars]

Hello everybody.

Today I've tested GDC (on Windows), and a simple Hello World 
program results in a 5 MB exe file, while it's only about 200 KB 
with DMD. Is this normal? What does GDC (GCC?) put in there, to 
make it so big, and why?


Mars

Re: Executable size when compiling with GDC

[Andrea Fontana]

Have you tried to strip executable using --strip or --strip-all?



Il giorno mar, 21/02/2012 alle 13.51 +0100, Mars ha scritto:

 Hello everybody.
 
 Today I've tested GDC (on Windows), and a simple Hello World 
 program results in a 5 MB exe file, while it's only about 200 KB 
 with DMD. Is this normal? What does GDC (GCC?) put in there, to 
 make it so big, and why?
 
 Mars

Re: Executable size when compiling with GDC

[Mars]

On Tuesday, 21 February 2012 at 13:19:11 UTC, Andrea Fontana 
wrote:

Have you tried to strip executable using --strip or --strip-all?


Down to 1 MB, a good start, thanks. I guess that's more bearable.

Re: Executable size when compiling with GDC

[Trass3r]

Lots of symbols and stuff.
You can get it down with -ffunction-sections -fdata-sections  
-Wl,-s,--gc-sections
Phobos should also be compiled with -ffunction-sections -fdata-sections to  
get the whole effect though.

Re: What can be done to reduce executable size?

[Andrei Alexandrescu]

On 12/16/11 1:12 AM, Jonathan M Davis wrote:

Simply making it so that std.file is only imported in std.stdio with
version(unittest) cut off _that_ much?


Yah, but the matter is more complex. The issue is that std.file pulls 
std.datetime, which (a) has static this() code, and (b) pulls core.time, 
which in turn has static this() code.


The issue with that is as follows. Any file that transitively imports a 
module with constructors will have its own module info generated. When 
that happens, all vtables in that module will be instantiated, so all 
methods will be linked in. That in turn causes all functions they call 
to also be linked in.


That's why many programs using std are large.

We can attack this in two ways:

1. Revise and reduce all static this() uses in phobos and druntime;

2. Improve the compiler to do minimal linking when static this() does 
come about.



Andrei

Re: What can be done to reduce executable size?

[bearophile]

Andrei Alexandrescu:

 Right now an executable starts at around 218KB, which includes druntime 
 (gc, type info, the works). Importing std.stdio and using writeln() only 
 adds a couple of KBs.

Now using ulink the hello world exe becomes 129_564 bytes.

Bye,
bearophile

Re: What can be done to reduce executable size?

[Jonathan M Davis]

On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote:
 On 12/16/11 1:12 AM, Jonathan M Davis wrote:
  Simply making it so that std.file is only imported in std.stdio with
  version(unittest) cut off _that_ much?
 
 Yah, but the matter is more complex. The issue is that std.file pulls
 std.datetime, which (a) has static this() code, and (b) pulls core.time,
 which in turn has static this() code.
 
 The issue with that is as follows. Any file that transitively imports a
 module with constructors will have its own module info generated. When
 that happens, all vtables in that module will be instantiated, so all
 methods will be linked in. That in turn causes all functions they call
 to also be linked in.
 
 That's why many programs using std are large.
 
 We can attack this in two ways:
 
 1. Revise and reduce all static this() uses in phobos and druntime;
 
 2. Improve the compiler to do minimal linking when static this() does
 come about.

Well, both std.datetime and core.time need static this() and can't not have 
it. There may be other places in Phobos where module and class constructors 
can be avoided or removed, but aside from unit tests, when they're used, 
they're generally required. If some _can_ be removed though, that would be 
great, since their presence also risks circular dependencies, which is a far 
worse issue than the executable's size IMHO. But we can't get rid of them all. 
Any work that can be done in the compiler to reduce the executable's size due 
to static this would be great though.

- Jonathan M Davis

Re: What can be done to reduce executable size?

[Trass3r]

Am 16.12.2011, 10:15 Uhr, schrieb bearophile bearophileh...@lycos.com:


Andrei Alexandrescu:


Right now an executable starts at around 218KB, which includes druntime
(gc, type info, the works). Importing std.stdio and using writeln() only
adds a couple of KBs.


Now using ulink the hello world exe becomes 129_564 bytes.


What is its secret?

Re: What can be done to reduce executable size?

[Trass3r]

Am 16.12.2011, 14:52 Uhr, schrieb Trass3r u...@known.com:


Am 16.12.2011, 10:15 Uhr, schrieb bearophile bearophileh...@lycos.com:


Andrei Alexandrescu:


Right now an executable starts at around 218KB, which includes druntime
(gc, type info, the works). Importing std.stdio and using writeln()  
only

adds a couple of KBs.


Now using ulink the hello world exe becomes 129_564 bytes.


What is its secret?


Didn't it also compress the exe?

Re: What can be done to reduce executable size?

[Adam D. Ruppe]

On Friday, 16 December 2011 at 09:50:30 UTC, Jonathan M Davis 
wrote:
Well, both std.datetime and core.time need static this() and 
can't not have it.


Why are they necessary? It looks like it sets the time zone...
wouldn't it work to put that into DateTime's regular constructor?

Re: What can be done to reduce executable size?

[Adam D. Ruppe]

What I have in mind is if the timezone was something along
the lines of a singleton property, so it still works
the same way, except it is lazy loaded on first use.

(if this is indeed the right static constructor!)

Re: What can be done to reduce executable size?

[Jonathan M Davis]

On Friday, December 16, 2011 16:16:53 Adam D. Ruppe wrote:
 What I have in mind is if the timezone was something along
 the lines of a singleton property, so it still works
 the same way, except it is lazy loaded on first use.
 
 (if this is indeed the right static constructor!)

That would break purity, so no that doesn't work. The singletons are pure.

- Jonathan M Davis

Re: What can be done to reduce executable size?

[Adam D. Ruppe]

On Friday, 16 December 2011 at 16:35:27 UTC, Jonathan M Davis 
wrote:
That would break purity, so no that doesn't work. The 
singletons are pure.


I'm tempted to say just cast it away, since you aren't actually
breaking purity in any meaningful way; the return value is always
the same and it should have no other side effects (except on the
internal variable).


Lying around pure was a bit of a pain... but this seems to have
done the trick:

alias pure string function () hax;

private string impureConstructor() {
   static string cache;
   if(cache is null)
   cache = lol pure defeated;
   return cache;
}

private pure hax getPureConstructor() { return cast(hax) 
impureConstructor; }


public @system @property pure string test() {
   return getPureConstructor()();
}


// test now works

Re: What can be done to reduce executable size?

[Trass3r]

Am 16.12.2011, 04:40 Uhr, schrieb Andrei Alexandrescu  
seewebsiteforem...@erdani.org:

https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53


Yeah one could also use the new (function-)local imports.

However, this also shows another problem common to C and D: You don't get  
any warnings if an import is unused.
A tool that detects removable import declarations would be awesome. I wish  
dmd was designed modularly and as a library like Clang...

Re: What can be done to reduce executable size?

[bearophile]

Trass3r:

  Now using ulink the hello world exe becomes 129_564 bytes.
 
 What is its secret?

Linkers use grey magic, as you know.
And it doesn't use compression.

Bye,
bearophile

Re: What can be done to reduce executable size?

[Andrei Alexandrescu]

On 12/16/11 3:49 AM, Jonathan M Davis wrote:

On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote:

On 12/16/11 1:12 AM, Jonathan M Davis wrote:

Simply making it so that std.file is only imported in std.stdio with
version(unittest) cut off _that_ much?


Yah, but the matter is more complex. The issue is that std.file pulls
std.datetime, which (a) has static this() code, and (b) pulls core.time,
which in turn has static this() code.

The issue with that is as follows. Any file that transitively imports a
module with constructors will have its own module info generated. When
that happens, all vtables in that module will be instantiated, so all
methods will be linked in. That in turn causes all functions they call
to also be linked in.

That's why many programs using std are large.

We can attack this in two ways:

1. Revise and reduce all static this() uses in phobos and druntime;

2. Improve the compiler to do minimal linking when static this() does
come about.


Well, both std.datetime and core.time need static this() and can't not have
it.


I am pretty sure they don't need static this(). Only last night I 
removed static this() from core.time.


Andrei

Re: What can be done to reduce executable size?

[Jonathan M Davis]

On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
 On 12/16/11 3:49 AM, Jonathan M Davis wrote:
  On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote:
  On 12/16/11 1:12 AM, Jonathan M Davis wrote:
  Simply making it so that std.file is only imported in std.stdio with
  version(unittest) cut off _that_ much?
  
  Yah, but the matter is more complex. The issue is that std.file pulls
  std.datetime, which (a) has static this() code, and (b) pulls
  core.time,
  which in turn has static this() code.
  
  The issue with that is as follows. Any file that transitively imports
  a
  module with constructors will have its own module info generated. When
  that happens, all vtables in that module will be instantiated, so all
  methods will be linked in. That in turn causes all functions they call
  to also be linked in.
  
  That's why many programs using std are large.
  
  We can attack this in two ways:
  
  1. Revise and reduce all static this() uses in phobos and druntime;
  
  2. Improve the compiler to do minimal linking when static this() does
  come about.
  
  Well, both std.datetime and core.time need static this() and can't not
  have it.
 
 I am pretty sure they don't need static this(). Only last night I
 removed static this() from core.time.

I don't know how you could do that in core.time, since ticksPerSec and 
appOrigin are immutable and have to be set at runtime. How on earth can you do 
that without a static constructor?

std.datetime has the same problem with the added fun of having to avoid 
breaking purity, because the functions for getting the singletons are pure.

- Jonathan M Davis

Re: What can be done to reduce executable size?

[Sean Kelly]

On Dec 15, 2011, at 7:40 PM, Andrei Alexandrescu wrote:

 On 12/10/11 9:39 AM, Bane wrote:
 Short term and long term suggestions ? Anything we can do ? I heard it
 is some problem with linking dead code?
 
 
 
 import std.stdio;
 int main(){
 writefln(Hello Bloat!);
 return 0;
 }
 
 dmd -release -O hello.d
 
 On Windows:
 v1.071 = 339 Kb
 v2.056 = 1017 Kb
 
 It looks very ugly and might distract some people.
 
 In fact there was a low-hanging fruit, and I'm sure there are some more. This 
 diff reduces the size of hello, world (compiled with -O -release -inline and 
 after strip) from 700KB to 220 KB:
 
 https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53
 
 Right now an executable starts at around 218KB, which includes druntime (gc, 
 type info, the works). Importing std.stdio and using writeln() only adds a 
 couple of KBs.

So importing std.file adds 800K to a executable?

Re: What can be done to reduce executable size?

[Andrei Alexandrescu]

On 12/16/11 12:40 PM, Jonathan M Davis wrote:

On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:

I am pretty sure they don't need static this(). Only last night I
removed static this() from core.time.


I don't know how you could do that in core.time, since ticksPerSec and
appOrigin are immutable and have to be set at runtime. How on earth can you do
that without a static constructor?

std.datetime has the same problem with the added fun of having to avoid
breaking purity, because the functions for getting the singletons are pure.


This goes back to the issue of lazy initialization. Today you need a 
cast to do that. Here's my code:


static @trusted @property long ticksPerSec() pure nothrow
{
return (cast(immutable(long) function() pure nothrow) 
ticksPerSecImpl)();

}

static @property immutable(long) ticksPerSecImpl() nothrow
{
static long result;

if (result)
{
return result;
}

... initialization ...
return result;
}

The presence of the cast is unsightly but the code does something 
unusual (modifies what looks from the outside like a constant) so it is 
justifiable, particularly since we're talking about the language's core 
library.



Andrei

Re: What can be done to reduce executable size?

[Sean Kelly]

On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote:

 On 12/16/11 12:40 PM, Jonathan M Davis wrote:
 On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
 I am pretty sure they don't need static this(). Only last night I
 removed static this() from core.time.
 
 I don't know how you could do that in core.time, since ticksPerSec and
 appOrigin are immutable and have to be set at runtime. How on earth can you 
 do
 that without a static constructor?
 
 std.datetime has the same problem with the added fun of having to avoid
 breaking purity, because the functions for getting the singletons are pure.
 
 This goes back to the issue of lazy initialization. Today you need a cast to 
 do that. Here's my code:
 
static @trusted @property long ticksPerSec() pure nothrow
{
return (cast(immutable(long) function() pure nothrow) 
 ticksPerSecImpl)();
}

This is fine, but the whole point of static ctors in D is to eliminate all the 
stupid workarounds required to use statics in C++.  I'd much rather we find a 
way to make the use of static ctors more efficient than give up on the feature.

Re: What can be done to reduce executable size?

[Jonathan M Davis]

On Friday, December 16, 2011 11:07:14 Sean Kelly wrote:
 On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote:
  On 12/16/11 12:40 PM, Jonathan M Davis wrote:
  On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
  I am pretty sure they don't need static this(). Only last night I
  removed static this() from core.time.
  
  I don't know how you could do that in core.time, since ticksPerSec and
  appOrigin are immutable and have to be set at runtime. How on earth
  can you do that without a static constructor?
  
  std.datetime has the same problem with the added fun of having to
  avoid
  breaking purity, because the functions for getting the singletons are
  pure. 
  This goes back to the issue of lazy initialization. Today you need a cast 
to do that. Here's my code:
  static @trusted @property long ticksPerSec() pure nothrow
  {
  
  return (cast(immutable(long) function() pure nothrow)
  ticksPerSecImpl)(); 
  }
 
 This is fine, but the whole point of static ctors in D is to eliminate all
 the stupid workarounds required to use statics in C++. I'd much rather we
 find a way to make the use of static ctors more efficient than give up on
 the feature.

Agreed.

- Jonathan M Davis

Re: What can be done to reduce executable size?

[Andrei Alexandrescu]

On 12/16/11 1:07 PM, Sean Kelly wrote:

This is fine, but the whole point of static ctors in D is to
eliminate all the stupid workarounds required to use statics in C++.
I'd much rather we find a way to make the use of static ctors more
efficient than give up on the feature.


I agree, but then I think we have a design that's already there. This 
discusses working some kinks out of the implementation. Also, the 
context of the runtime/standard library is an appropriate place to take 
less usual measures for the benefit of many.


Andrei

Re: What can be done to reduce executable size?

[Sean Kelly]

On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote:

 On 12/16/11 1:07 PM, Sean Kelly wrote:
 This is fine, but the whole point of static ctors in D is to
 eliminate all the stupid workarounds required to use statics in C++.
 I'd much rather we find a way to make the use of static ctors more
 efficient than give up on the feature.
 
 I agree, but then I think we have a design that's already there. This 
 discusses working some kinks out of the implementation. Also, the context of 
 the runtime/standard library is an appropriate place to take less usual 
 measures for the benefit of many.

But at the same time, the standard library should be an example of how to do 
things the right way.  By preferring the C++ approach over static ctors in 
the standard library, we're suggesting that static ctors are not the right 
approach for the discriminating programmer.  I do agree that the design is 
already there, but perhaps the implementation needs refinement?

Re: What can be done to reduce executable size?

[Andrei Alexandrescu]

On 12/16/11 4:21 PM, Sean Kelly wrote:

On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote:


On 12/16/11 1:07 PM, Sean Kelly wrote:

This is fine, but the whole point of static ctors in D is to
eliminate all the stupid workarounds required to use statics in
C++. I'd much rather we find a way to make the use of static
ctors more efficient than give up on the feature.


I agree, but then I think we have a design that's already there.
This discusses working some kinks out of the implementation. Also,
the context of the runtime/standard library is an appropriate place
to take less usual measures for the benefit of many.


But at the same time, the standard library should be an example of
how to do things the right way.


More often, APIs and examples given in the docs are examples of how to 
do things the right way; the standard library's implementation has a bit 
of a different charter than most application code, and this is triply 
true for systems languages. This is emphatically true for e.g. C, C++, 
and Perl. I also remember I was surprised when I peeked inside a 
functional language's library implementation. (That's not how they 
teach them to write sort!)



By preferring the C++ approach
over static ctors in the standard library, we're suggesting that
static ctors are not the right approach for the discriminating
programmer.


And they may as well not be, subject to whatever unique constraints to 
overcome.



I do agree that the design is already there, but perhaps
the implementation needs refinement?


That's a given!


Andrei

Re: What can be done to reduce executable size?

[Sean Kelly]

On Dec 16, 2011, at 2:54 PM, Andrei Alexandrescu wrote:

 On 12/16/11 4:21 PM, Sean Kelly wrote:
 On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote:
 
 On 12/16/11 1:07 PM, Sean Kelly wrote:
 This is fine, but the whole point of static ctors in D is to
 eliminate all the stupid workarounds required to use statics in
 C++. I'd much rather we find a way to make the use of static
 ctors more efficient than give up on the feature.
 
 I agree, but then I think we have a design that's already there.
 This discusses working some kinks out of the implementation. Also,
 the context of the runtime/standard library is an appropriate place
 to take less usual measures for the benefit of many.
 
 But at the same time, the standard library should be an example of
 how to do things the right way.
 
 More often, APIs and examples given in the docs are examples of how to do 
 things the right way; the standard library's implementation has a bit of a 
 different charter than most application code, and this is triply true for 
 systems languages. This is emphatically true for e.g. C, C++, and Perl. I 
 also remember I was surprised when I peeked inside a functional language's 
 library implementation. (That's not how they teach them to write sort!)

Perhaps it's just that I come from a systems programming background and have 
books like Large Scale C++ Software Design sitting on the shelf next to me.  
I think the important distinction to be made is between sample code and real 
world code.  Or perhaps between code where performance is and is not an issue.  
You've historically derided the quicksort example for functional programs as 
useless because, while it's a very clean example of the algorithm, it's 
ridiculously inefficient.  So anyone who really cares about the efficiency of 
their code is going to end up writing stuff that looks nothing like what you'd 
find in a textbook.  In short, they're going to write code that looks like 
standard library code to whatever extent the skill of their programmers can 
achieve.  I really don't want the line between whether or not to use really 
useful language features like static ctors to be whether I'm writing sample 
code or professional code.

That said, I will grant that library code in general can't make any assumptions 
about how the code will be used, so this is the one case where premature 
optimization really is prudent.  Even performance-minded application code 
typically can't make the same claim because there is generally some idea of how 
that code will be run, and thus tuning can be done based on profiler data.  So 
I suppose I'll somewhat concede your point.

Re: What can be done to reduce executable size?

[Andrei Alexandrescu]

On 12/10/11 9:39 AM, Bane wrote:

Short term and long term suggestions ? Anything we can do ? I heard it
is some problem with linking dead code?



import std.stdio;
int main(){
writefln(Hello Bloat!);
return 0;
}

dmd -release -O hello.d

On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb

It looks very ugly and might distract some people.


In fact there was a low-hanging fruit, and I'm sure there are some more. 
This diff reduces the size of hello, world (compiled with -O -release 
-inline and after strip) from 700KB to 220 KB:


https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53

Right now an executable starts at around 218KB, which includes druntime 
(gc, type info, the works). Importing std.stdio and using writeln() only 
adds a couple of KBs.



Andrei

Re: What can be done to reduce executable size?

[Jonathan M Davis]

On Thursday, December 15, 2011 21:40:57 Andrei Alexandrescu wrote:
 On 12/10/11 9:39 AM, Bane wrote:
  Short term and long term suggestions ? Anything we can do ? I heard it
  is some problem with linking dead code?
  
  
  
  import std.stdio;
  int main(){
  writefln(Hello Bloat!);
  return 0;
  }
  
  dmd -release -O hello.d
  
  On Windows:
  v1.071 = 339 Kb
  v2.056 = 1017 Kb
  
  It looks very ugly and might distract some people.
 
 In fact there was a low-hanging fruit, and I'm sure there are some more.
 This diff reduces the size of hello, world (compiled with -O -release
 -inline and after strip) from 700KB to 220 KB:
 
 https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d
 48ea419e201bfc65ed53
 
 Right now an executable starts at around 218KB, which includes druntime
 (gc, type info, the works). Importing std.stdio and using writeln() only
 adds a couple of KBs.

Simply making it so that std.file is only imported in std.stdio with 
version(unittest) cut off _that_ much?

- Jonathan M Davis

Re: What can be done to reduce executable size?

[bearophile]

Martin Krejcirik:

 I don't know about D2, but for D1 it helps to recompile Phobos without
 -lib (use lib.exe, see win32.mak).

What are the effects/disadvantages of doing this?

Bye,
bearophile

Re: What can be done to reduce executable size?

[Jacob Carlborg]

On 2011-12-14 12:47, bearophile wrote:

Martin Krejcirik:


I don't know about D2, but for D1 it helps to recompile Phobos without
-lib (use lib.exe, see win32.mak).


What are the effects/disadvantages of doing this?

Bye,
bearophile


You need to explicitly invoke the tool that creates libraries on the 
given system (ar on Posix, lib on Windows) making it platform dependent.


--
/Jacob Carlborg

Re: What can be done to reduce executable size?

[Martin Krejcirik]

On 10.12.2011 16:39, Bane wrote:
 Short term and long term suggestions ? Anything we can do ? I heard it
 is some problem with linking dead code?

I don't know about D2, but for D1 it helps to recompile Phobos without
-lib (use lib.exe, see win32.mak).

Hello.d - 84k

I'm attaching my makefiles, the smaller one belongs to phobos/internal/gc

Martin
# Makefile to build D runtime library phobos.lib for Win32
# Designed to work with \dm\bin\make.exe
# Targets:
#   make
#   Same as make unittest
#   make phobos.lib
#   Build phobos.lib
#   make clean
#   Delete unneeded files created by build process
#   make unittest
#   Build phobos.lib, build and run unit tests
#   make html
#   Build documentation
# Notes:
#   This relies on LIB.EXE 8.00 or later, and MAKE.EXE 5.01 or later.

CP=cp
DIR=\programs\dm
PHOBOSSVN=\svnproj\phobos1

CFLAGS=-mn -6 -r
#CFLAGS=-g -mn -6 -r

DFLAGS=-O -release -nofloat -w
#DFLAGS=-nofloat -w
#DFLAGS=-unittest -g -w
#DFLAGS=-unittest -cov -g

CC=dmc

DMD=$(DIR)\bin\dmd
#DMD=..\dmd

DOC=..\..\html\d\phobos
#DOC=..\doc\phobos

.c.obj:
$(CC) -c $(CFLAGS) $*

.cpp.obj:
$(CC) -c $(CFLAGS) $*

.d.obj:
$(DMD) -c $(DFLAGS) $*

.asm.obj:
$(CC) -c $*

targets : phobos.lib gcstub.obj

test : test.exe

test.obj : test.d
$(DMD) -c test -g -unittest

test.exe : test.obj phobos.lib
$(DMD) test.obj -g -L/map

#Mart zakomentovano
#OBJS= deh.obj complex.obj gcstats.obj \
#   critical.obj object.obj monitor.obj \
#   crc32.obj \
#   Czlib.obj Dzlib.obj process.obj \
#   oldsyserror.obj \
#   errno.obj metastrings.obj

#   ti_bit.obj ti_Abit.obj

#Mart vytvoreno z vystupu standardni kompilace (na konci, kdy dela lib)
#odmazano: arrayfloat.obj arraydouble.obj arrayreal.obj arraybyte.obj 
arrayshort.obj arrayint.obj
#OBJS=math.obj stdio.obj dateparse.obj date.obj uni.obj string.obj base64.obj 
md5.obj regexp.obj compiler.obj \
#   cpuid.obj format.obj demangle.obj path.obj outbuffer.obj utf.obj 
uri.obj ctype.obj random.obj array.obj \
#   mmfile.obj asserterror.obj system.obj bitarray.obj signals.obj 
typetuple.obj traits.obj bind.obj switcherr.obj \
#   thread.obj moduleinit.obj boxer.obj stream.obj socket.obj 
socketstream.obj perf.obj openrj.obj conv.obj zip.obj \
#   cstream.obj loader.obj outofmemory.obj cover.obj file.obj math2.obj 
aaA.obj adi.obj aApply.obj aApplyR.obj \
#   memset.obj arraycast.obj arraycat.obj switch.obj qsort.obj 
invariant.obj dmain2.obj cast.obj obj.obj gamma.obj \
#   stdarg.obj com.obj stat.obj windows.obj winsock.obj charset.obj 
iunknown.obj registry.obj syserror.obj ti_ptr.obj \
#   ti_delegate.obj ti_void.obj ti_C.obj ti_byte.obj ti_ubyte.obj 
ti_short.obj ti_ushort.obj ti_int.obj ti_uint.obj \
#   ti_long.obj ti_ulong.obj ti_char.obj ti_wchar.obj ti_dchar.obj 
ti_cdouble.obj ti_double.obj ti_idouble.obj \
#   ti_cfloat.obj ti_float.obj ti_ifloat.obj ti_creal.obj ti_real.obj 
ti_ireal.obj ti_AC.obj ti_Ag.obj ti_Ashort.obj \
#   ti_Aint.obj ti_Along.obj ti_Afloat.obj ti_Adouble.obj ti_Areal.obj 
ti_Acfloat.obj ti_Acdouble.obj ti_Acreal.obj \
#   deh.obj complex.obj gcstats.obj critical.obj object.obj monitor.obj 
crc32.obj \
#   Czlib.obj Dzlib.obj process.obj oldsyserror.obj errno.obj 
metastrings.obj 

#odmazano: arrayfloat.obj arraydouble.obj arrayreal.obj arraybyte.obj 
arrayshort.obj arrayint.obj minit.obj
OBJS=math.obj stdio.obj dateparse.obj date.obj uni.obj string.obj base64.obj 
md5.obj regexp.obj compiler.obj cpuid.obj format.obj demangle.obj \
path.obj outbuffer.obj utf.obj uri.obj ctype.obj random.obj array.obj 
mmfile.obj asserterror.obj system.obj  bitarray.obj  signals.obj \
typetuple.obj traits.obj bind.obj switcherr.obj thread.obj thread_helper.obj 
moduleinit.obj boxer.obj stream.obj socket.obj \
socketstream.obj perf.obj openrj.obj conv.obj zip.obj cstream.obj loader.obj 
outofmemory.obj cover.obj file.obj math2.obj \
stdint.obj stdarg.obj aaA.obj adi.obj aApply.obj aApplyR.obj memset.obj 
arraycast.obj arraycat.obj switch.obj qsort.obj intrinsic.obj \
invariant.obj dmain2.obj cast.obj obj.obj gamma.obj math.obj stdarg.obj 
stddef.obj stdio.obj stdlib.obj string.obj com.obj stat.obj \
windows.obj winsock.obj charset.obj iunknown.obj registry.obj syserror.obj \
ti_ptr.obj ti_delegate.obj ti_void.obj ti_C.obj ti_byte.obj ti_ubyte.obj 
ti_short.obj ti_ushort.obj ti_int.obj ti_uint.obj ti_long.obj ti_ulong.obj \
ti_char.obj ti_wchar.obj ti_dchar.obj ti_cdouble.obj ti_double.obj 
ti_idouble.obj ti_cfloat.obj ti_float.obj ti_ifloat.obj ti_creal.obj 
ti_real.obj \
ti_ireal.obj ti_AC.obj ti_Ag.obj ti_Ashort.obj ti_Aint.obj ti_Along.obj 
ti_Afloat.obj ti_Adouble.obj ti_Areal.obj ti_Acfloat.obj \
ti_Acdouble.obj ti_Acreal.obj deh.obj complex.obj gcstats.obj critical.obj 
object.obj monitor.obj crc32.obj Czlib.obj Dzlib.obj \
process.obj oldsyserror.obj 

Re: What can be done to reduce executable size?

[Jacob Carlborg]

On 2011-12-11 23:55, Jonathan M Davis wrote:

On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote:

Jacob Carlborg Wrote:

As long as the runtime and standard library is statically linked the
executables will be bigger than the corresponding C/C++ executable.


I just want to say it's very important to me that static linking
still just works very easily even if we start to offer dynamic linking.


Most definitely. I consider dynamic linking to be a necessary evil which should
not be used unless you have to. I _much_ prefer having my programs completely
self-contained. The less that they rely on in terms of external libraries the
better. Sure, there are plenty of cases where dynamic libraries are necessary
(e.g. plugins), and the fact that they generally reduce disk space consumption
is useful, but it's _so_ nice to not have to worry about the exact versions of
everything else installed on the system.

- Jonathan M Davis


It is very nice to not have to think about external dependencies when 
installing a tool or library, but as you say for plugins it is 
important. I would hope that it is possible to have the application 
completely statically linked but at the same time provide plugins for 
the application.


--
/Jacob Carlborg

Re: What can be done to reduce executable size?

[Andrea Fontana]

You can try with upx :)

Il giorno lun, 12/12/2011 alle 14.42 +0100, Jacob Carlborg ha scritto:

 On 2011-12-11 23:55, Jonathan M Davis wrote:
  On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote:
  Jacob Carlborg Wrote:
  As long as the runtime and standard library is statically linked the
  executables will be bigger than the corresponding C/C++ executable.
 
  I just want to say it's very important to me that static linking
  still just works very easily even if we start to offer dynamic linking.
 
  Most definitely. I consider dynamic linking to be a necessary evil which 
  should
  not be used unless you have to. I _much_ prefer having my programs 
  completely
  self-contained. The less that they rely on in terms of external libraries 
  the
  better. Sure, there are plenty of cases where dynamic libraries are 
  necessary
  (e.g. plugins), and the fact that they generally reduce disk space 
  consumption
  is useful, but it's _so_ nice to not have to worry about the exact versions 
  of
  everything else installed on the system.
 
  - Jonathan M Davis
 
 It is very nice to not have to think about external dependencies when 
 installing a tool or library, but as you say for plugins it is 
 important. I would hope that it is possible to have the application 
 completely statically linked but at the same time provide plugins for 
 the application.
 

Re: What can be done to reduce executable size?

[Martin Nowak]

The symbol table.
Probably you also had debug infos for phobos?
By the way if I strip this, my executable is only 292K.

On Sat, 10 Dec 2011 20:16:54 +0100, Trass3r u...@known.com wrote:


import std.stdio;
int main(){
   writefln(Hello Bloat!);
   return 0;
}

dmd -release -O hello.d

On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb


$ dmd -release -O test.d
867K
$ strip -s test
572K

I don't know where the 300KB come from.
The map files are equal:
dmd -release -O -map test.d
dmd -release -O -L-s -map test.d


This is what Hello World looks like on x64 Linux:
http://thecybershadow.net/d/mapview/view.php?id=4ee3af86c32f2

Re: What can be done to reduce executable size?

[Trass3r]

Am 12.12.2011, 20:33 Uhr, schrieb Martin Nowak d...@dawgfoto.de:


The symbol table.
Probably you also had debug infos for phobos?

Possible.


By the way if I strip this, my executable is only 292K.


32bits?

Re: What can be done to reduce executable size?

[Nick Sabalausky]

Trass3r u...@known.com wrote in message news:op.v6ai1yjc3ncmek@enigma...
 Right, but my point is, I could work around (I've gotten within inches 
 of it!) it if simply Walter released a TINY part of snn.lib -- just a 
 handful of tiny source files regarding the TLS-related stuff, EXE 
 segment markers, and whatnot. (I've already raised this issue before, 
 and precisely what we would need, but it seemed to go completely 
 ignored.)

 Nag again and again :)

That's how we got -wi ;)

Re: What can be done to reduce executable size?

[Jacob Carlborg]

On 2011-12-10 16:39, Bane wrote:

Short term and long term suggestions ? Anything we can do ? I heard it
is some problem with linking dead code?



import std.stdio;
int main(){
writefln(Hello Bloat!);
return 0;
}

dmd -release -O hello.d

On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb

It looks very ugly and might distract some people.


As long as the runtime and standard library is statically linked the 
executables will be bigger than the corresponding C/C++ executable.


--
/Jacob Carlborg

Re: What can be done to reduce executable size?

[Adam Ruppe]

Jacob Carlborg Wrote:
 As long as the runtime and standard library is statically linked the 
 executables will be bigger than the corresponding C/C++ executable.

I just want to say it's very important to me that static linking
still just works very easily even if we start to offer dynamic linking.

Re: What can be done to reduce executable size?

[Jonathan M Davis]

On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote:
 Jacob Carlborg Wrote:
  As long as the runtime and standard library is statically linked the
  executables will be bigger than the corresponding C/C++ executable.
 
 I just want to say it's very important to me that static linking
 still just works very easily even if we start to offer dynamic linking.

Most definitely. I consider dynamic linking to be a necessary evil which should 
not be used unless you have to. I _much_ prefer having my programs completely 
self-contained. The less that they rely on in terms of external libraries the 
better. Sure, there are plenty of cases where dynamic libraries are necessary 
(e.g. plugins), and the fact that they generally reduce disk space consumption 
is useful, but it's _so_ nice to not have to worry about the exact versions of 
everything else installed on the system.

- Jonathan M Davis

Re: What can be done to reduce executable size?

[news.digitalmars.com]

Most definitely. I consider dynamic linking to be a necessary evil which 
should
not be used unless you have to. I _much_ prefer having my programs 
completely
self-contained. The less that they rely on in terms of external libraries 
the
better. Sure, there are plenty of cases where dynamic libraries are 
necessary
(e.g. plugins), and the fact that they generally reduce disk space 
consumption
is useful, but it's _so_ nice to not have to worry about the exact 
versions of

everything else installed on the system.

- Jonathan M Davis


Nobody cares about disk space this time. Imagine x00 applications run in 
memory with

exact copy of libc.

Oleg. 

What can be done to reduce executable size?

[Bane]

Short term and long term suggestions ? Anything we can do ? I heard it 
is some problem with linking dead code?




import std.stdio;
int main(){
  writefln(Hello Bloat!);
  return 0;
}

dmd -release -O hello.d

On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb

It looks very ugly and might distract some people.

Re: What can be done to reduce executable size?

[Mirko Pilger]

On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb


  v2.057b= 840 kb (upx --best = 151 kb)

Re: What can be done to reduce executable size?

[Bane]

Mirko Pilger Wrote:

  On Windows:
  v1.071 = 339 Kb
  v2.056 = 1017 Kb
 
v2.057b= 840 kb (upx --best = 151 kb)
 

That is improvement. 2.07 is not released yet ?
And I don't think UPX is solution. It makes things look even worse, like too 
much makeup on ugly chick.

Re: What can be done to reduce executable size?

[David Nadlinger]

On 12/10/11 4:55 PM, Bane wrote:

That is improvement. 2.07 is not released yet ?


Yeah, 2.057 is still in beta (expect a release during the next few days, 
though). It has some Phobos/druntime changes geared specifically towards 
reducing executable size.


David

Re: What can be done to reduce executable size?

[Bane]

I am dealing with scenario of large numbers of programs written in D placed on 
same host/1 installer, when it all sums up size does matters.

 Is it possible to move  phobos or runtime to shared lib ? It would reduces 
 code significantly.

Re: What can be done to reduce executable size?

[Bane]

Is it possible to move  phobos or runtime to shared lib ? It would reduces code 
significantly.

Re: What can be done to reduce executable size?

[Andrej Mitrovic]

Try using the unilink linker:

ftp://ftp.styx.cabel.net/pub/UniLink/

Get ulnb0329.zip

You have to configure ulink.cfg to this:
-zsnn.lib
-LC:\dmd\windows\lib
-LC:\dm\lib
-Go

-zkernel32;advapi32;user32;wsock32;shell32;snn.lib
-LC:\dmd2\windows\lib
-Go

Then linking is just: ulink file1.obj file2.obj lib.obj etc..

Re: What can be done to reduce executable size?

[Trass3r]

Am 10.12.2011, 17:17 Uhr, schrieb Bane branimir.milosavlje...@gmail.com:

Is it possible to move  phobos or runtime to shared lib ? It would  
reduces code significantly.


Theoretically but there are some hurdles (esp. regarding the runtime/gc).
Some people have already tried this (on Linux of course), I'm not sure  
what the current status is.