Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of gshimansky@gmail.com
 designates 64.233.184.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=DQv66qdDTx7wlWq1jIDV3hSZFnNk9OCwbjUrG/jcEBGE0gc+Tt3MtxZNXtvmcwBxZ/5r7AO/2anEfXc6jhpVRJuijrH58FdIk3tvQbOZURzKhTV5tMksQsgIGMepegqPnl20EyUno2ag4imdrrYWjVE20o+bO2EzNm7KTzOHKYU=
Message-ID: <47594F9B.5010106@apache.org>
Date: Fri, 07 Dec 2007 16:50:19 +0300
From: Gregory Shimansky <gshimansky@apache.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [drlvm] linking with runtime libraries on windows
References: <f944d83d0710162355y6dd2d6f9g3d66e3d0e09b92eb@mail.gmail.com>
	 <4715B99D.5000506@apache.org>
	 <f944d83d0710170152j1ffad8d9sd1f4d55efe7b7e62@mail.gmail.com>
	 <f944d83d0710190019k7a3b8350nf46f921342bb7d3a@mail.gmail.com>
	 <47187AD0.7080701@apache.org>
 <f944d83d0712070459l3395fafana0eaea1aa66b330@mail.gmail.com>
In-Reply-To: <f944d83d0712070459l3395fafana0eaea1aa66b330@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: Gregory Shimansky <gshimansky@gmail.com>

Alexey Varlamov пишет:
> Good news here.
> A couple of memory corruption bugs were resolved recently, so I was
> able to integrate the fix at r602080.
> As a bonus, total size of drlvm dlls become less for ~4M on Win32 and
> ~12M on Win64. Not bad IMO ;)

This is really good news. Thank you Alexey!

> PS Beware to do clean rebuild of drlvm.
> --
> Regards,
> Alexey
> 
> 2007/10/19, Gregory Shimansky <gshimansky@apache.org>:
>> Alexey Varlamov wrote:
>>> Guys, I've filed HARMONY-4973 with workable patch.
>>> Bad news is that there are spurious errors in gc_gen shutdown (see the
>>> JIRA for details), most possibly corrupted heap :(. BTW,  I possibly
>>> found mismatching "delete" vs "free" usage:
>>> vm/gc_gen/src/thread/marker.cpp:143:  delete marker->trace_stack;
>>> vm/gc_gen/src/thread/collector.cpp:223:  delete collector->trace_stack;
>>>
>>> But those are not the rootcause. Any help or ideas will be appreciated...
>> There was a reported problem with recent updates that some tests crash
>> on shutdown with diagnostics about corrupted C heap. There is a JIRA
>> that might help with it (HARMONY-4960). I am currently testing it and
>> I'll report whether it fixes corrupted heap on interpreter. Maybe heap
>> is actually corrupted in JIT mode as well, but MSVC checks don't detect
>> it when VM is built without your patch.
>>
>>> 2007/10/17, Alexey Varlamov <alexey.v.varlamov@gmail.com>:
>>>> A kind of roadblock here is the initial issue of debug vs release
>>>> runtime DLLs. It is desirable to have fully redistributable debug
>>>> build, isn't it? So it would be nice to avoid MSVCR71D.DLL dependency.
>>>> Actually the sole thing which requires debug runtime is the
>>>> disable_assert_dialogs() feature, which may affect release build as
>>>> well - e.g. if we compile release but w/o NDEBUG to leave asserts
>>>> enabled. I'll try to dig if it can be workarounded.
>>>>
>>>> --
>>>> Alexey
>>>>
>>>>
>>>> 2007/10/17, Gregory Shimansky <gshimansky@apache.org>:
>>>>> Alexey Varlamov wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Looking on HARMONY-3964 "[drlvm][build] missing MSVCR71D.DLL
>>>>>> dependency for debug builds", I'm surprised to realize that only GC
>>>>>> dlls in VM ever depend on MSVCR*.DLL, no matter release or debug.
>>>>>> All the rest of VM is linked against static LIBCMTD.LIB so every dll
>>>>>> carries it's own copy of C runtime, with independent heaps and static
>>>>>> data! Now it explains all that troubles with bad frees in
>>>>>> HARMONY-3772, and why each dll has to disable assert dialog
>>>>>> individually (HARMONY-4715). I've just tried fully dynamic build and
>>>>>> indeed all these problems are gone.
>>>>>>
>>>>>> I guess why it was done so, and the only reason I could think of is
>>>>>> historycal. Does anyone knows other explanation? Otherwise I believe
>>>>>> the build must be fixed to link with MSVCRxx.DLL always. Especially as
>>>>>> we already redistribute them with classlib.
>>>>> I agree very much that dynamic build would be much better. The only
>>>>> reason why it wasn't done I think is that it just wasn't easy to do this
>>>>> in the current ant based build system. If you can do it please go ahead
>>>>> and commit!
>>>>>
>>>>> BTW don't forget about windows x86_64.
>>>>>
>>>>> --
>>>>> Gregory
>>>>>
>>>>>
>>
>> --
>> Gregory
>>
>>