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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
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
