|
From: <sv...@va...> - 2005-10-06 18:58:40
|
Author: njn Date: 2005-10-06 19:58:33 +0100 (Thu, 06 Oct 2005) New Revision: 4883 Log: Added an FAQ about Java. Modified: trunk/docs/xml/FAQ.xml Modified: trunk/docs/xml/FAQ.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- trunk/docs/xml/FAQ.xml 2005-10-06 14:49:21 UTC (rev 4882) +++ trunk/docs/xml/FAQ.xml 2005-10-06 18:58:33 UTC (rev 4883) @@ -181,6 +181,24 @@ </answer> </qandaentry> =20 +<qandaentry id=3D"faq.java"> + <question> + <para>I tried running a Java program under Valgrind but Valgrind abort= ed. + Does Valgrind handle Java programs, dynamically generated code, etc? + </para> + </question> + <answer> + <para>Valgrind handles dynamically generated code without a problem. + In theory, Valgrind can run any Java program just fine, even those t= hat + use JNI and are partially implemented in other languages like C and = C++. + In practice, Java implementations tend to do nasty things that most + programs do not, and Valgrind sometimes falls over these corner + cases.</para> + <para>If your Java programs do not run under Valgrind, please file a + bug report and hopefully we'll be able to fix the problem.</para> + </answer> +</qandaentry> + </qandaset> </sect1> =20 |
|
From: Julian S. <js...@ac...> - 2005-10-06 19:10:36
|
> + <para>Valgrind handles dynamically generated code without a problem. But only until such time as the Java implementation or whatever starts throwing away code it made and overwriting the area with new code. Then V will have stale translations of it. In general dealing with dynamically generated code in an uncooperative environment (x86,amd64) requires --smc-check=all, no? (On ppc32 V naturally observes the icbi insns that should be issued by the Java JIT and so it should Just Work (tm)). J |
|
From: Nicholas N. <nj...@cs...> - 2005-10-06 19:14:59
|
On Thu, 6 Oct 2005, Julian Seward wrote: >> + <para>Valgrind handles dynamically generated code without a problem. > > But only until such time as the Java implementation or whatever starts > throwing away code it made and overwriting the area with new code. Then > V will have stale translations of it. In general dealing with dynamically > generated code in an uncooperative environment (x86,amd64) requires > --smc-check=all, no? (On ppc32 V naturally observes the icbi insns > that should be issued by the Java JIT and so it should Just Work (tm)). Ah crap, you're right. N |
|
From: Nicholas N. <nj...@cs...> - 2005-10-06 19:31:42
|
On Thu, 6 Oct 2005, Nicholas Nethercote wrote: >>> + <para>Valgrind handles dynamically generated code without a problem. >> >> But only until such time as the Java implementation or whatever starts >> throwing away code it made and overwriting the area with new code. Then >> V will have stale translations of it. In general dealing with dynamically >> generated code in an uncooperative environment (x86,amd64) requires >> --smc-check=all, no? (On ppc32 V naturally observes the icbi insns >> that should be issued by the Java JIT and so it should Just Work (tm)). > > Ah crap, you're right. And I guess we need to use --smc-check=all when self-hosting unless we're confident the code cache won't get full. Nick |