Trying to understand why LO seems freezed for some seconds when a module is started

[Stephan Bergmann]

On 02/11/2012 07:24 PM, julien2412 wrote:
> On master branch (not on 3.5 branch), each time I start a module Calc,
> Writer or Impress (I didn't test on others), when I begin to type something,
> it seems to freeze for some seconds (about 10 secs) then everything seems
> ok.
> So I runned valgrind by using this :
> valgrind --tool=memcheck --num-callers=50 --trace-children=yes ./soffice.bin
> 2>&1 | tee /tmp/valgrind.log

If you suspect the cause for the delay to be unnecessary large amounts 
of code being executed, you should run valgrind with --tool=callgrind.

> With this, I can't start LO at all because there are too much errors. By
> taking a look, 98% of them are like this :
> ==4110== Invalid write of size 4
> ==4110==    at 0x2E7BE641: ???
> ==4110==    by 0x2E7AF437: ???
> ==4110==    by 0x2DA518CE: JavaCalls::call_helper(JavaValue*, methodHandle*,
> JavaCallArguments*, Thread*) (in
> /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
[...]

JVMs are notorious for producing false positives from valgrind.  I once 
improved that somewhat, by forcing the JVM into interpreted mode when 
run under valgrind (see "forceInterpreted" in 
jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx), but even the 
non-JITed code still produces noise (which I was able to silence at 
least on a Fedora 16 with trunk valgrind via a

> {
>  java-1
>  Memcheck:Addr4
>  ...
>  obj:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
> }
> {
>  java-2
>  Memcheck:Addr8
>  fun:_wordcopy_fwd_dest_aligned
>   # (in /lib64/libc-2.14.so)
>  fun:__GI_memmove
>   # (in /lib64/libc-2.14.so)
>  fun:realpath@@GLIBC_2.3
>   # (in /lib64/libc-2.14.so)
>  obj:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so
>  fun:Java_java_io_UnixFileSystem_canonicalize0
>   # (in /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/libjava.so)
> }
> {
>  java-3
>  Memcheck:Cond
>  obj:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server/libjvm.so
> }

valgrind suppressions file).

> I noticed these lines too :
>     700 #ifdef MACOSX
>      701     vm_args.version= JNI_VERSION_1_4; // issue 88987
>      702 #else
>      703     vm_args.version= JNI_VERSION_1_2;
>      704 #endif
> If we support jdk 1.4 min, we could use JNI version 1.4 according to this
> http://docs.oracle.com/javase/1.4.2/docs/guide/jni/jni-14.html, no ? (or
> perhaps it would need lots of changes to use it except for MacOS where it's
> already used)

Yes, we could probably simplify the code by always using 
JNI_VERSION_1_4.  But it should probably not make a difference (note 
that the example at 
<http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html#wp16334> 
still uses 1_2, and only states that it must be at least 1_2, but not 
that setting it to a higher value has any special effect), and who knows 
what would break with all those varied JVM implementations out there.

Stephan