Enabling unit-at-a-time by default for Java

Enabling unit-at-a-time by default for Java

[Jan Hubicka]

Hi,
as discussed earlier, I would like to enable unit-at-a-time by default
for Java.  This will allow to drop non-unit-at-a-time for gcc 4.5 and
also avoid hitting latent bugs since Java is now only user of
non-unit-at-a-time.

I've fixed some related problems related to memory usage and compilation
time, so libjava now builds resonably (fater than before).  Two
remaining issues I know of are:

 1) Testcase jonas.jar now requires about 9GB of ram instead of 3GB of
 ram to compile.  I've looked into it and it is all actual gimple memory
 usage.  About 4GB for gimple representation of program and other 5GB
 for other datastructures.  

 SSA operand caches are particularly
 ineffective for small functions, so some improvement can be done here.
 Tuples ought to help here, but last time I tried the tuples branch
 actually needed more RAM than mainline.  They should trim out something
 out of the 4GB of Gimple usage.

 2) I get libjava.lang/StackTrace2 failure at -O3.  This testcase tests
 that unwind info reports proper name of function doing non-call EH
 (at least in my understnading of Java).  Inlining of the throwing
 function naturally changes its name in unwind info, yet I don't see how
 inliner can work out that inlining is not supposed to happen.

 I guess StackFrame feature is not really compatible with inlining, but
 I might be missing something.  It is definitly latent problem and
 probably minor one.

OK for mainline?
Honza

	* java/lang.c (java_init_options): Enable unit-at-a-time by default.
Index: java/lang.c
===================================================================
--- java/lang.c	(revision 137752)
+++ java/lang.c	(working copy)
@@ -521,10 +521,6 @@ java_init_options (unsigned int argc ATT
   /* Java requires left-to-right evaluation of subexpressions.  */
   flag_evaluation_order = 1;
 
-  /* Unit at a time is disabled for Java because it is considered
-     too expensive.  */
-  no_unit_at_a_time_default = 1;
-
   jcf_path_init ();
 
   return CL_Java;

Re: Enabling unit-at-a-time by default for Java

[Andrew Haley]

Jan Hubicka wrote:
> Hi,
> as discussed earlier, I would like to enable unit-at-a-time by default
> for Java.  This will allow to drop non-unit-at-a-time for gcc 4.5 and
> also avoid hitting latent bugs since Java is now only user of
> non-unit-at-a-time.
> 
> I've fixed some related problems related to memory usage and compilation
> time, so libjava now builds resonably (fater than before).  Two
> remaining issues I know of are:
> 
>  1) Testcase jonas.jar now requires about 9GB of ram instead of 3GB of
>  ram to compile.  I've looked into it and it is all actual gimple memory
>  usage.  About 4GB for gimple representation of program and other 5GB
>  for other datastructures.  
> 
>  SSA operand caches are particularly
>  ineffective for small functions, so some improvement can be done here.
>  Tuples ought to help here, but last time I tried the tuples branch
>  actually needed more RAM than mainline.  They should trim out something
>  out of the 4GB of Gimple usage.
> 
>  2) I get libjava.lang/StackTrace2 failure at -O3.  This testcase tests
>  that unwind info reports proper name of function doing non-call EH
>  (at least in my understnading of Java).  Inlining of the throwing
>  function naturally changes its name in unwind info, yet I don't see how
>  inliner can work out that inlining is not supposed to happen.
> 
>  I guess StackFrame feature is not really compatible with inlining, but
>  I might be missing something.  It is definitly latent problem and
>  probably minor one.
> 
> OK for mainline?

OK, thanks.  I'll fix the StackTrace2 problem.

Andrew.

Re: Enabling unit-at-a-time by default for Java

[Andrew Haley]

Andrew Haley wrote:
> Jan Hubicka wrote:

>>  2) I get libjava.lang/StackTrace2 failure at -O3.  This testcase tests
>>  that unwind info reports proper name of function doing non-call EH
>>  (at least in my understnading of Java).  Inlining of the throwing
>>  function naturally changes its name in unwind info, yet I don't see how
>>  inliner can work out that inlining is not supposed to happen.
>>
>>  I guess StackFrame feature is not really compatible with inlining, but
>>  I might be missing something.  It is definitly latent problem and
>>  probably minor one.
>>
>> OK for mainline?
> 
> OK, thanks.  I'll fix the StackTrace2 problem.

The only way to fix that test case is to disable all inlining in gcj.
I'm not prepared to do that.  When the gcj user asks for functions to be
inlined, they want gcj to obey them.  It is much more valuable to have
inlining where possible than perfect stack traces.

I fixed the test case by replacing all inlinable calls with non-inlinable
ones.

Andrew.


2008-08-07  Andrew Haley  <aph@redhat.com>

	* testsuite/libjava.lang/StackTrace2.java: Rewrite to prevent
	spurious failure when some methods are inlined.

Index: StackTrace2.out
===================================================================
--- StackTrace2.out	(revision 138796)
+++ StackTrace2.out	(working copy)
@@ -1,5 +1,5 @@
 Trace length = 4
 StackTrace2$Inner.doCrash:OK
-StackTrace2$Inner.<init>:OK
+StackTrace2$Inner.foo:OK
 StackTrace2.a:OK
 StackTrace2.main:OK
Index: StackTrace2.java
===================================================================
--- StackTrace2.java	(revision 138796)
+++ StackTrace2.java	(working copy)
@@ -7,7 +7,7 @@
   {
     try
     {
-      a();
+      new StackTrace2().a();
     }
     catch (Exception x)
     {
@@ -16,14 +16,14 @@
     }
   }

-  static void a()
+  void a()
   {
-    new Inner();
+    new Inner().foo();
   }

-  static class Inner
+  class Inner
   {
-    public Inner()
+    public void foo()
     {
       doCrash(null);
     }
@@ -38,7 +38,7 @@
   {
     System.out.println("Trace length = " + trace.length);
     checkLine(trace[0], "StackTrace2$Inner", "doCrash", 33);
-    checkLine(trace[1], "StackTrace2$Inner", "<init>", 28);
+    checkLine(trace[1], "StackTrace2$Inner", "foo", 28);
     checkLine(trace[2], "StackTrace2", "a", 21);
     checkLine(trace[3], "StackTrace2", "main", 10);
   }