public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Patch: FYI: gcj3.1 status update
       [not found] <87vgbpkdq9.fsf@creche.redhat.com>
@ 2002-03-21 11:59 ` Rainer Orth
  2002-03-22 11:27   ` Tom Tromey
  0 siblings, 1 reply; 18+ messages in thread
From: Rainer Orth @ 2002-03-21 11:59 UTC (permalink / raw)
  To: tromey; +Cc: Java Patch List, java

Tom Tromey <tromey@redhat.com> writes:

> Daily status update.

A few corrections:

* i386-pc-solaris2.8 is ok since your patch for PR bootstrap/5948 has now
  been checked in:

  http://gcc.gnu.org/ml/java/2002-03/msg00389.html

  although testsuite results could be improved if the use of
  -fcheck-references to avoid a couple of failures wouldn't introduce
  different ones

  http://gcc.gnu.org/ml/java/2002-03/msg00478.html

  Unfortunately, there have been no suggestions what to do about this
  issue: is it expected that -fcheck-references introduces new testsuite
  failures or even bootstrap failures?

* alpha-dec-osf4.0f is ok:

  http://gcc.gnu.org/ml/java/2002-03/msg00478.html

  The same issue about -fcheck-references applies here, too.

* alpha-dec-osf5.1 bootstraps, but shows many EH failures:

  http://gcc.gnu.org/ml/java/2002-03/msg00456.html

  I'm trying to find out what to do about those EH failures (PR
  target/5966). 

	Rainer

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-03-21 11:59 ` Patch: FYI: gcj3.1 status update Rainer Orth
@ 2002-03-22 11:27   ` Tom Tromey
  2002-03-27 12:19     ` Rainer Orth
  0 siblings, 1 reply; 18+ messages in thread
From: Tom Tromey @ 2002-03-22 11:27 UTC (permalink / raw)
  To: Rainer Orth; +Cc: Java Patch List, java

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Tom> Daily status update.

Rainer> A few corrections:

Thanks.  You've done this a couple times and I've neglected to mention
how helpful it has been.  It's very helpful.

Rainer>   Unfortunately, there have been no suggestions what to do
Rainer>   about this issue: is it expected that -fcheck-references
Rainer>   introduces new testsuite failures or even bootstrap
Rainer>   failures?

Nope.  This will be fixed soon.

Rainer> * alpha-dec-osf5.1 bootstraps, but shows many EH failures:
Rainer>   http://gcc.gnu.org/ml/java/2002-03/msg00456.html
Rainer>   I'm trying to find out what to do about those EH failures (PR
Rainer>   target/5966). 

I'll add this PR to the list.
I don't know what to do about the failures either.

Tom

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-03-22 11:27   ` Tom Tromey
@ 2002-03-27 12:19     ` Rainer Orth
  2002-03-27 15:48       ` Tom Tromey
  0 siblings, 1 reply; 18+ messages in thread
From: Rainer Orth @ 2002-03-27 12:19 UTC (permalink / raw)
  To: tromey; +Cc: java

Tom Tromey writes:

> Rainer>   Unfortunately, there have been no suggestions what to do
> Rainer>   about this issue: is it expected that -fcheck-references
> Rainer>   introduces new testsuite failures or even bootstrap
> Rainer>   failures?
> 
> Nope.  This will be fixed soon.

Bootstraps on alpha-dec-osf5.1, sparc-sun-solaris2.8 and i386-pc-solaris2.8
with -fcheck-references enabled are now in progress.

> Rainer> * alpha-dec-osf5.1 bootstraps, but shows many EH failures:
> Rainer>   http://gcc.gnu.org/ml/java/2002-03/msg00456.html
> Rainer>   I'm trying to find out what to do about those EH failures (PR
> Rainer>   target/5966). 
> 
> I'll add this PR to the list.
> I don't know what to do about the failures either.

While this has since been fixed, the status for alpha-dec-osf4.0f is
incorrect: it is in good shape as well, as can be seen from

	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00490.html

Thus my proposed patch to enable libgcj on alpha*-dec-osf* by default.

	Rainer

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-03-27 12:19     ` Rainer Orth
@ 2002-03-27 15:48       ` Tom Tromey
  2002-03-27 15:52         ` Rainer Orth
  0 siblings, 1 reply; 18+ messages in thread
From: Tom Tromey @ 2002-03-27 15:48 UTC (permalink / raw)
  To: Rainer Orth; +Cc: java

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer> Bootstraps on alpha-dec-osf5.1, sparc-sun-solaris2.8 and
Rainer> i386-pc-solaris2.8 with -fcheck-references enabled are now in
Rainer> progress.

Thanks.  If this results in improvements, we should make this change.
I think Irix needs it too.

As has been discussed at length, this isn't a panacea.  In fact it is
more of a stopgap until we have better support for these platforms.

Rainer> While this has since been fixed, the status for
Rainer> alpha-dec-osf4.0f is incorrect: it is in good shape as well,
Rainer> as can be seen from
Rainer> 	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00490.html

I've marked this `ok'

Rainer> Thus my proposed patch to enable libgcj on alpha*-dec-osf* by
Rainer> default.

Awesome.

Tom

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-03-27 15:48       ` Tom Tromey
@ 2002-03-27 15:52         ` Rainer Orth
  2002-03-28  5:11           ` Rainer Orth
  2002-04-02 19:04           ` Tom Tromey
  0 siblings, 2 replies; 18+ messages in thread
From: Rainer Orth @ 2002-03-27 15:52 UTC (permalink / raw)
  To: tromey; +Cc: java

Tom Tromey writes:

> >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> 
> Rainer> Bootstraps on alpha-dec-osf5.1, sparc-sun-solaris2.8 and
> Rainer> i386-pc-solaris2.8 with -fcheck-references enabled are now in
> Rainer> progress.
> 
> Thanks.  If this results in improvements, we should make this change.
> I think Irix needs it too.

Indeed, but my IRIX 6.5 host is dead slow (full bootstrap and N32/N64 make
check takes about 4 days).  Perhaps someone else can try a bootstrap on
mips-sgi-irix6.[25] with my patch (included below for reference)?

> Rainer> While this has since been fixed, the status for
> Rainer> alpha-dec-osf4.0f is incorrect: it is in good shape as well,
> Rainer> as can be seen from
> Rainer> 	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00490.html
> 
> I've marked this `ok'

Fine, thanks.

> Rainer> Thus my proposed patch to enable libgcj on alpha*-dec-osf* by
> Rainer> default.
> 
> Awesome.

It's in now.

	Rainer


Mon Mar 18 19:18:14 2002  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>

	* configure.host: Introduce host_cpu and host_os switches, moving
	cpu- or os-only sections here.
	Sort host switch.
	(solaris2*, alpha*-dec-osf*, mips-sgi-irix6*): Use
	-fcheck-references for CHECKREFSPEC. 
	(i?86-*-solaris2*): Keep default DIVIDESPEC.

Index: libjava/configure.host
===================================================================
RCS file: /cvs/gcc/gcc/libjava/configure.host,v
retrieving revision 1.23.2.4
diff -u -p -r1.23.2.4 configure.host
--- configure.host	2002/03/27 16:40:25	1.23.2.4
+++ configure.host	2002/03/27 19:29:25
@@ -1,7 +1,7 @@
 # configure.host
 
 # This shell script handles all host based configuration for libgcj.
-# It sets various shell variables based on the the host and the
+# It sets various shell variables based on the host and the
 # configuration options.  You can modify this shell script without
 # needing to rerun autoconf.
 
@@ -12,6 +12,7 @@
 # It uses the following shell variables:
 #   host		The configuration host
 #   host_cpu		The configuration host CPU
+#   host_os             The configuration host OS
 #   target_optspace	--enable-target-optspace ("yes", "no", "")
 
 # It sets the following shell variables:
@@ -51,27 +52,21 @@ esac
 
 AM_RUNTESTFLAGS= 
 
-# Set any host dependent compiler flags.
-# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
-
 echo "$target"
 
 DIVIDESPEC=-fuse-divide-subroutine
 EXCEPTIONSPEC=-fnon-call-exceptions
 CHECKREFSPEC=
 
-case "${host}" in
-  mips-tx39-*|mipstx39-unknown-*)
-	libgcj_flags="${libgcj_flags} -G 0"
-	LDFLAGS="$LDFLAGS -Tjmr3904dram.ld"
-	AM_RUNTESTFLAGS="--target_board=jmr3904-sim"	
-	# Use "Ecos" processes since they are a no-op.
-	PROCESS=Ecos
-	FILE=Posix
- 	enable_java_net_default=no
- 	enable_getenv_properties_default=no
+# Set any CPU dependent comphost# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
+case "${host_cpu}" in
+  alpha*)
+	sysdeps_dir=alpha
+	libgcj_flags="${libgcj_flags} -mieee"
+	libgcj_interpreter=yes
+	enable_hash_synchronization_default=yes
 	;;
-  i686-*|i586-*|i486-*|i386-*)
+  i[3456]6)
 	sysdeps_dir=i386
 	libgcj_flags="${libgcj_flags} -ffloat-store"
 	libgcj_interpreter=yes
@@ -81,29 +76,54 @@ case "${host}" in
 	enable_hash_synchronization_default=yes
 	slow_pthread_self=yes
 	;;
-  alpha*-*)
-	sysdeps_dir=alpha
-	libgcj_flags="${libgcj_flags} -mieee"
+  ia64)
+	sysdeps_dir=ia64
+        libgcj_flags="${libgcj_flags} -funwind-tables"
 	libgcj_interpreter=yes
 	enable_hash_synchronization_default=yes
 	;;
-  powerpc*-linux*)
-	sysdeps_dir=powerpc
-	libgcj_interpreter=yes
-	enable_hash_synchronization_default=yes
-	slow_pthread_self=yes
+esac
+
+# Set any OS dependent compiler flags.
+# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
+case "${host_os}" in
+  solaris2*)
+	CHECKREFSPEC=-fcheck-references
 	;;
+esac
+
+# Set any flags dependent on the full host triplet.
+# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
+case "${host}" in
+  alpha*-dec-osf*)
+	CHECKREFSPEC=-fcheck-references
+	;;
+  i?86-*-solaris2*)
+	# override i?86 default
+	DIVIDESPEC=-fuse-divide-subroutine
+	;;
+  mips-sgi-irix6*)
+	CHECKREFSPEC=-fcheck-references
+	;;
+  mips-tx39-*|mipstx39-unknown-*)
+	libgcj_flags="${libgcj_flags} -G 0"
+	LDFLAGS="$LDFLAGS -Tjmr3904dram.ld"
+	AM_RUNTESTFLAGS="--target_board=jmr3904-sim"	
+	# Use "Ecos" processes since they are a no-op.
+	PROCESS=Ecos
+	FILE=Posix
+ 	enable_java_net_default=no
+ 	enable_getenv_properties_default=no
+	;;
   powerpc*-darwin*)
 	sysdeps_dir=powerpc
         libgcj_interpreter=yes
 	;;
-  sparc-*)
-        ;;
-  ia64-*)
-	sysdeps_dir=ia64
-        libgcj_flags="${libgcj_flags} -funwind-tables"
+  powerpc*-linux*)
+	sysdeps_dir=powerpc
 	libgcj_interpreter=yes
 	enable_hash_synchronization_default=yes
+	slow_pthread_self=yes
 	;;
   xscale*-elf)
 	with_libffi_default=no

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-03-27 15:52         ` Rainer Orth
@ 2002-03-28  5:11           ` Rainer Orth
  2002-04-02 18:53             ` Tom Tromey
  2002-04-02 19:04           ` Tom Tromey
  1 sibling, 1 reply; 18+ messages in thread
From: Rainer Orth @ 2002-03-28  5:11 UTC (permalink / raw)
  To: tromey; +Cc: java

Rainer Orth writes:

> Tom Tromey writes:
> 
> > >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> > 
> > Rainer> Bootstraps on alpha-dec-osf5.1, sparc-sun-solaris2.8 and
> > Rainer> i386-pc-solaris2.8 with -fcheck-references enabled are now in
> > Rainer> progress.
> > 
> > Thanks.  If this results in improvements, we should make this change.
> > I think Irix needs it too.
> 
> Indeed, but my IRIX 6.5 host is dead slow (full bootstrap and N32/N64 make
> check takes about 4 days).  Perhaps someone else can try a bootstrap on
> mips-sgi-irix6.[25] with my patch (included below for reference)?

Testsuite results are below, the patch results mostly in an improvement:

* sparc-sun-solaris2.8:

	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00729.html

-FAIL: Invoke_1 execution from source compiled test
-FAIL: Invoke_1 execution from bytecode->native test
-FAIL: Invoke_1 -O execution from source compiled test
-FAIL: Invoke_1 -O execution from bytecode->native test

+FAIL: FileHandleGcTest execution from source compiled test
+FAIL: FileHandleGcTest execution from bytecode->native test
+FAIL: FileHandleGcTest -O execution from source compiled test
+FAIL: FileHandleGcTest -O execution from bytecode->native test

* i386-pc-solaris2.8:

	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00730.html

-FAIL: Divide_1 execution from source compiled test
-FAIL: Divide_1 execution from bytecode->native test
-FAIL: Divide_1 -O execution from source compiled test
-FAIL: Divide_1 -O execution from bytecode->native test
-FAIL: Invoke_1 execution from source compiled test
-FAIL: Invoke_1 execution from bytecode->native test
-FAIL: Invoke_1 -O execution from source compiled test
-FAIL: Invoke_1 -O execution from bytecode->native test
-FAIL: PR218 execution from source compiled test
-FAIL: PR218 execution from bytecode->native test
-FAIL: PR218 -O execution from source compiled test
-FAIL: PR218 -O execution from bytecode->native test
-FAIL: SyncTest execution from bytecode->native test
-FAIL: SyncTest -O execution from bytecode->native test
-FAIL: Array_3 execution from source compiled test
-FAIL: Array_3 execution from bytecode->native test
-FAIL: Array_3 -O execution from source compiled test
-FAIL: Array_3 -O execution from bytecode->native test

* alpha-dec-osf5.1:

	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00728.html

-FAIL: Invoke_1 execution from source compiled test
-FAIL: Invoke_1 execution from bytecode->native test
-FAIL: Invoke_1 -O execution from source compiled test
-FAIL: Invoke_1 -O execution from bytecode->native test
-FAIL: PR218 execution from source compiled test
-FAIL: PR218 execution from bytecode->native test
-FAIL: PR218 -O execution from source compiled test
-FAIL: PR218 -O execution from bytecode->native test
-FAIL: Array_3 execution from source compiled test
-FAIL: Array_3 execution from bytecode->native test
-FAIL: Array_3 -O execution from source compiled test
-FAIL: Array_3 -O execution from bytecode->native test

The only problem is that building libgcj.so with -fcheck-references breaks
FileHandleGcTest on Solaris.  It doesn't make a diffeence whether or not
the test itself is built with this flag.  Tru64 UNIX is unaffected.

What shall we do about this?

	Rainer

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-03-28  5:11           ` Rainer Orth
@ 2002-04-02 18:53             ` Tom Tromey
  2002-04-03 11:27               ` Andrew Haley
  0 siblings, 1 reply; 18+ messages in thread
From: Tom Tromey @ 2002-04-02 18:53 UTC (permalink / raw)
  To: Rainer Orth; +Cc: java

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer> Testsuite results are below, the patch results mostly in an
Rainer> improvement:

Great.

Rainer> The only problem is that building libgcj.so with
Rainer> -fcheck-references breaks FileHandleGcTest on Solaris.  It
Rainer> doesn't make a diffeence whether or not the test itself is
Rainer> built with this flag.  Tru64 UNIX is unaffected.

Rainer> What shall we do about this?

Sorry I didn't reply to this sooner.
How does the test fail?  I'm surprised this happens.

Tom

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-03-27 15:52         ` Rainer Orth
  2002-03-28  5:11           ` Rainer Orth
@ 2002-04-02 19:04           ` Tom Tromey
  1 sibling, 0 replies; 18+ messages in thread
From: Tom Tromey @ 2002-04-02 19:04 UTC (permalink / raw)
  To: Rainer Orth; +Cc: java

>>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:

Rainer> Mon Mar 18 19:18:14 2002  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>
Rainer> 	* configure.host: Introduce host_cpu and host_os switches, moving
Rainer> 	cpu- or os-only sections here.
Rainer> 	Sort host switch.
Rainer> 	(solaris2*, alpha*-dec-osf*, mips-sgi-irix6*): Use
Rainer> 	-fcheck-references for CHECKREFSPEC. 
Rainer> 	(i?86-*-solaris2*): Keep default DIVIDESPEC.

Sorry for the delay in looking at this.

I think this patch is fine.  Please check it in to the trunk and the
branch.  Thanks for doing this.

Tom

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-02 18:53             ` Tom Tromey
@ 2002-04-03 11:27               ` Andrew Haley
  2002-04-05  7:57                 ` Andrew Haley
  0 siblings, 1 reply; 18+ messages in thread
From: Andrew Haley @ 2002-04-03 11:27 UTC (permalink / raw)
  To: tromey; +Cc: Rainer Orth, java

Tom Tromey writes:
 > >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
 > 
 > Rainer> Testsuite results are below, the patch results mostly in an
 > Rainer> improvement:
 > 
 > Great.
 > 
 > Rainer> The only problem is that building libgcj.so with
 > Rainer> -fcheck-references breaks FileHandleGcTest on Solaris.  It
 > Rainer> doesn't make a diffeence whether or not the test itself is
 > Rainer> built with this flag.  Tru64 UNIX is unaffected.
 > 
 > Rainer> What shall we do about this?
 > 
 > Sorry I didn't reply to this sooner.
 > How does the test fail?  I'm surprised this happens.

Me too.  I should give this a whirl myself.

Andrew.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-03 11:27               ` Andrew Haley
@ 2002-04-05  7:57                 ` Andrew Haley
  2002-04-05  8:02                   ` Jeff Sturm
                                     ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Andrew Haley @ 2002-04-05  7:57 UTC (permalink / raw)
  To: tromey, Rainer Orth, java

Andrew Haley writes:
 > Tom Tromey writes:
 >  > >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
 >  > 
 >  > Rainer> Testsuite results are below, the patch results mostly in an
 >  > Rainer> improvement:
 >  > 
 >  > Great.
 >  > 
 >  > Rainer> The only problem is that building libgcj.so with
 >  > Rainer> -fcheck-references breaks FileHandleGcTest on Solaris.  It
 >  > Rainer> doesn't make a diffeence whether or not the test itself is
 >  > Rainer> built with this flag.  Tru64 UNIX is unaffected.
 >  > 
 >  > Rainer> What shall we do about this?
 >  > 
 >  > Sorry I didn't reply to this sooner.
 >  > How does the test fail?  I'm surprised this happens.
 > 
 > Me too.  I should give this a whirl myself.

I did, and it failed in the way I expected: it ran out of file
handles.  This is because our implementation of System.gc() doesn't
actually work.  Well, that's not true -- it does work eventually, but
it returns before garbage collection is complete.  When
natFileDescriptorPosix.cc (java::io::FileDescriptor::open) does this:

  if (fd == -1 && errno == EMFILE)
    {
      // Because finalize () calls close () we might be able to continue.
      java::lang::System::gc ();
      java::lang::System::runFinalization ();
      fd = ::open (buf, flags, mode);
    }
 
it fails.  We could fix this by spinning in this routine for a while
waiting for a file handle.

Better though to fix System.gc() so that it doesn't return until a
grabage collection cycle has really happned.  There are deadlock
problems with this, as I mentioned before.  I guess we could work
around that problem with a fairly short timeout.

This is a pretty important bug to fix, in my opinion, because it
critically affects web servers.

Andrew.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-05  7:57                 ` Andrew Haley
@ 2002-04-05  8:02                   ` Jeff Sturm
  2002-04-05  9:27                     ` Andrew Haley
  2002-04-05 20:20                   ` Bryce McKinlay
  2002-04-08 13:18                   ` Tom Tromey
  2 siblings, 1 reply; 18+ messages in thread
From: Jeff Sturm @ 2002-04-05  8:02 UTC (permalink / raw)
  To: Andrew Haley; +Cc: tromey, Rainer Orth, java

On Fri, 5 Apr 2002, Andrew Haley wrote:
> I did, and it failed in the way I expected: it ran out of file
> handles.  This is because our implementation of System.gc() doesn't
> actually work.  Well, that's not true -- it does work eventually, but
> it returns before garbage collection is complete.

Same with runFinalization BTW, all it does it notify the finalizer thread,
not guarantee it has completed.

> This is a pretty important bug to fix, in my opinion, because it
> critically affects web servers.

That surprises me, to be honest.  The server code I've worked with seems
to rely on explicit close for all fd's.  The reason has to do with more
than resource reclamation: it flushes the buffers and the socket close is
often part of the protocol handshake (e.g. HTTP response with no content
length nor transfer encoding).

Jeff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-05  8:02                   ` Jeff Sturm
@ 2002-04-05  9:27                     ` Andrew Haley
  2002-04-05 10:01                       ` Jeff Sturm
  0 siblings, 1 reply; 18+ messages in thread
From: Andrew Haley @ 2002-04-05  9:27 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: tromey, Rainer Orth, java

Jeff Sturm writes:
 > On Fri, 5 Apr 2002, Andrew Haley wrote:
 > > I did, and it failed in the way I expected: it ran out of file
 > > handles.  This is because our implementation of System.gc() doesn't
 > > actually work.  Well, that's not true -- it does work eventually, but
 > > it returns before garbage collection is complete.
 > 
 > Same with runFinalization BTW, all it does it notify the finalizer thread,
 > not guarantee it has completed.
 > 
 > > This is a pretty important bug to fix, in my opinion, because it
 > > critically affects web servers.
 > 
 > That surprises me, to be honest.

I'm pretty sure that it is an issue, because the Linux kernel
engineers told me that they'd had to increase the number of available
file handles "because of Java servers."  Now, I'm guessing that this
is the cause, but it looks like a good candidate.

 > The server code I've worked with seems to rely on explicit close
 > for all fd's.  The reason has to do with more than resource
 > reclamation: it flushes the buffers and the socket close is often
 > part of the protocol handshake (e.g. HTTP response with no content
 > length nor transfer encoding).

Sure, but you also have to close local files as well as sockets.  I
take your point though.

I think I'll submit a patch for this.

Andrew.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-05  9:27                     ` Andrew Haley
@ 2002-04-05 10:01                       ` Jeff Sturm
  2002-04-05 10:19                         ` Andrew Haley
  0 siblings, 1 reply; 18+ messages in thread
From: Jeff Sturm @ 2002-04-05 10:01 UTC (permalink / raw)
  To: Andrew Haley; +Cc: tromey, Rainer Orth, java

On Fri, 5 Apr 2002, Andrew Haley wrote:
> I'm pretty sure that it is an issue, because the Linux kernel
> engineers told me that they'd had to increase the number of available
> file handles "because of Java servers."  Now, I'm guessing that this
> is the cause, but it looks like a good candidate.

They must be talking about per-process, not system-wide handles.

It just so happens that few people attempted to run multithreaded servers
on Linux before java came along.  And then there are artificial benchmarks
like VolanoMark.

We've had to run our servers with "ulimit -n 1024".  Empirically, that
seems to be plenty for us, even with high transaction volumes.

Come to think of it... why couldn't the FileDescriptor::open code in
libgcj attempt to call setrlimit as well as run finalizers before it gives
up?

Jeff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-05 10:01                       ` Jeff Sturm
@ 2002-04-05 10:19                         ` Andrew Haley
  0 siblings, 0 replies; 18+ messages in thread
From: Andrew Haley @ 2002-04-05 10:19 UTC (permalink / raw)
  To: Jeff Sturm; +Cc: tromey, Rainer Orth, java

Jeff Sturm writes:
 > On Fri, 5 Apr 2002, Andrew Haley wrote:
 > > I'm pretty sure that it is an issue, because the Linux kernel
 > > engineers told me that they'd had to increase the number of available
 > > file handles "because of Java servers."  Now, I'm guessing that this
 > > is the cause, but it looks like a good candidate.
 > 
 > They must be talking about per-process, not system-wide handles.

Right.

 > It just so happens that few people attempted to run multithreaded servers
 > on Linux before java came along.  And then there are artificial benchmarks
 > like VolanoMark.
 > 
 > We've had to run our servers with "ulimit -n 1024".  Empirically, that
 > seems to be plenty for us, even with high transaction volumes.

Okay, but not all unices support this.

 > Come to think of it... why couldn't the FileDescriptor::open code
 > in libgcj attempt to call setrlimit as well as run finalizers
 > before it gives up?

I don't suppose it would hurt, but it's not portable.

Andrew.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-05  7:57                 ` Andrew Haley
  2002-04-05  8:02                   ` Jeff Sturm
@ 2002-04-05 20:20                   ` Bryce McKinlay
  2002-04-08 13:18                   ` Tom Tromey
  2 siblings, 0 replies; 18+ messages in thread
From: Bryce McKinlay @ 2002-04-05 20:20 UTC (permalink / raw)
  To: Andrew Haley; +Cc: tromey, Rainer Orth, java

Andrew Haley wrote:

>Better though to fix System.gc() so that it doesn't return until a
>grabage collection cycle has really happned.  There are deadlock
>problems with this, as I mentioned before.  I guess we could work
>around that problem with a fairly short timeout.
>

I don't think there is any deadlock danger with System.gc(), only 
runFinalization(). So, a solution might be to use the java.util.ref 
stuff to keep track of what FileDescriptor objects are reachable. If we 
run out of descriptors in open, it should call System.gc() (which can 
wait until a full collection has been completed, but not run finalizers) 
and then close the unreachable ones if we run out.

I do agree with Jeff that this is probibly not really that bad, however. 
Well written code that is opening a lot of files/sockets ought to call 
close() explicitly.

regards

Bryce.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Patch: FYI: gcj3.1 status update
  2002-04-05  7:57                 ` Andrew Haley
  2002-04-05  8:02                   ` Jeff Sturm
  2002-04-05 20:20                   ` Bryce McKinlay
@ 2002-04-08 13:18                   ` Tom Tromey
  2 siblings, 0 replies; 18+ messages in thread
From: Tom Tromey @ 2002-04-08 13:18 UTC (permalink / raw)
  To: Andrew Haley; +Cc: Rainer Orth, java

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> Better though to fix System.gc() so that it doesn't return
Andrew> until a grabage collection cycle has really happned.  There
Andrew> are deadlock problems with this, as I mentioned before.  I
Andrew> guess we could work around that problem with a fairly short
Andrew> timeout.

Could you submit a PR for this, so we can track it in the future?  I
agree that these things (System.gc and .runFinalization) should be
synchronous.

I'm not too concerned about these for 3.1.  I see the "GC on open()
failure" thing as more a whim of mine than a real requirement.

Tom

^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: Patch: FYI: gcj3.1 status update
@ 2002-03-28 16:21 Billinghurst, David (CRTS)
  0 siblings, 0 replies; 18+ messages in thread
From: Billinghurst, David (CRTS) @ 2002-03-28 16:21 UTC (permalink / raw)
  To: Rainer Orth; +Cc: java

I see no change in libjava tests on irix6.5 with your configure.hosts patch.  It didn't apply cleanly in my 3.1 tree.  I had to finish by hand, which can lead to mistakes.  


^ permalink raw reply	[flat|nested] 18+ messages in thread

* RE: Patch: FYI: gcj3.1 status update
@ 2002-03-27 16:06 Billinghurst, David (CRTS)
  0 siblings, 0 replies; 18+ messages in thread
From: Billinghurst, David (CRTS) @ 2002-03-27 16:06 UTC (permalink / raw)
  To: Rainer Orth; +Cc: java

I will try and run this overnight on irix6.5.

-----Original Message-----
From: Rainer Orth [mailto:ro@TechFak.Uni-Bielefeld.DE]
Sent: Thursday, 28 March 2002 10:53 
To: tromey@redhat.com
Cc: java@gcc.gnu.org
Subject: Re: Patch: FYI: gcj3.1 status update


Tom Tromey writes:

> >>>>> "Rainer" == Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> writes:
> 
> Rainer> Bootstraps on alpha-dec-osf5.1, sparc-sun-solaris2.8 and
> Rainer> i386-pc-solaris2.8 with -fcheck-references enabled are now in
> Rainer> progress.
> 
> Thanks.  If this results in improvements, we should make this change.
> I think Irix needs it too.

Indeed, but my IRIX 6.5 host is dead slow (full bootstrap and N32/N64 make
check takes about 4 days).  Perhaps someone else can try a bootstrap on
mips-sgi-irix6.[25] with my patch (included below for reference)?

> Rainer> While this has since been fixed, the status for
> Rainer> alpha-dec-osf4.0f is incorrect: it is in good shape as well,
> Rainer> as can be seen from
> Rainer> 	http://gcc.gnu.org/ml/gcc-testresults/2002-03/msg00490.html
> 
> I've marked this `ok'

Fine, thanks.

> Rainer> Thus my proposed patch to enable libgcj on alpha*-dec-osf* by
> Rainer> default.
> 
> Awesome.

It's in now.

	Rainer


Mon Mar 18 19:18:14 2002  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>

	* configure.host: Introduce host_cpu and host_os switches, moving
	cpu- or os-only sections here.
	Sort host switch.
	(solaris2*, alpha*-dec-osf*, mips-sgi-irix6*): Use
	-fcheck-references for CHECKREFSPEC. 
	(i?86-*-solaris2*): Keep default DIVIDESPEC.

Index: libjava/configure.host
===================================================================
RCS file: /cvs/gcc/gcc/libjava/configure.host,v
retrieving revision 1.23.2.4
diff -u -p -r1.23.2.4 configure.host
--- configure.host	2002/03/27 16:40:25	1.23.2.4
+++ configure.host	2002/03/27 19:29:25
@@ -1,7 +1,7 @@
 # configure.host
 
 # This shell script handles all host based configuration for libgcj.
-# It sets various shell variables based on the the host and the
+# It sets various shell variables based on the host and the
 # configuration options.  You can modify this shell script without
 # needing to rerun autoconf.
 
@@ -12,6 +12,7 @@
 # It uses the following shell variables:
 #   host		The configuration host
 #   host_cpu		The configuration host CPU
+#   host_os             The configuration host OS
 #   target_optspace	--enable-target-optspace ("yes", "no", "")
 
 # It sets the following shell variables:
@@ -51,27 +52,21 @@ esac
 
 AM_RUNTESTFLAGS= 
 
-# Set any host dependent compiler flags.
-# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
-
 echo "$target"
 
 DIVIDESPEC=-fuse-divide-subroutine
 EXCEPTIONSPEC=-fnon-call-exceptions
 CHECKREFSPEC=
 
-case "${host}" in
-  mips-tx39-*|mipstx39-unknown-*)
-	libgcj_flags="${libgcj_flags} -G 0"
-	LDFLAGS="$LDFLAGS -Tjmr3904dram.ld"
-	AM_RUNTESTFLAGS="--target_board=jmr3904-sim"	
-	# Use "Ecos" processes since they are a no-op.
-	PROCESS=Ecos
-	FILE=Posix
- 	enable_java_net_default=no
- 	enable_getenv_properties_default=no
+# Set any CPU dependent comphost# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
+case "${host_cpu}" in
+  alpha*)
+	sysdeps_dir=alpha
+	libgcj_flags="${libgcj_flags} -mieee"
+	libgcj_interpreter=yes
+	enable_hash_synchronization_default=yes
 	;;
-  i686-*|i586-*|i486-*|i386-*)
+  i[3456]6)
 	sysdeps_dir=i386
 	libgcj_flags="${libgcj_flags} -ffloat-store"
 	libgcj_interpreter=yes
@@ -81,29 +76,54 @@ case "${host}" in
 	enable_hash_synchronization_default=yes
 	slow_pthread_self=yes
 	;;
-  alpha*-*)
-	sysdeps_dir=alpha
-	libgcj_flags="${libgcj_flags} -mieee"
+  ia64)
+	sysdeps_dir=ia64
+        libgcj_flags="${libgcj_flags} -funwind-tables"
 	libgcj_interpreter=yes
 	enable_hash_synchronization_default=yes
 	;;
-  powerpc*-linux*)
-	sysdeps_dir=powerpc
-	libgcj_interpreter=yes
-	enable_hash_synchronization_default=yes
-	slow_pthread_self=yes
+esac
+
+# Set any OS dependent compiler flags.
+# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
+case "${host_os}" in
+  solaris2*)
+	CHECKREFSPEC=-fcheck-references
 	;;
+esac
+
+# Set any flags dependent on the full host triplet.
+# THIS TABLE IS SORTED.  KEEP IT THAT WAY.
+case "${host}" in
+  alpha*-dec-osf*)
+	CHECKREFSPEC=-fcheck-references
+	;;
+  i?86-*-solaris2*)
+	# override i?86 default
+	DIVIDESPEC=-fuse-divide-subroutine
+	;;
+  mips-sgi-irix6*)
+	CHECKREFSPEC=-fcheck-references
+	;;
+  mips-tx39-*|mipstx39-unknown-*)
+	libgcj_flags="${libgcj_flags} -G 0"
+	LDFLAGS="$LDFLAGS -Tjmr3904dram.ld"
+	AM_RUNTESTFLAGS="--target_board=jmr3904-sim"	
+	# Use "Ecos" processes since they are a no-op.
+	PROCESS=Ecos
+	FILE=Posix
+ 	enable_java_net_default=no
+ 	enable_getenv_properties_default=no
+	;;
   powerpc*-darwin*)
 	sysdeps_dir=powerpc
         libgcj_interpreter=yes
 	;;
-  sparc-*)
-        ;;
-  ia64-*)
-	sysdeps_dir=ia64
-        libgcj_flags="${libgcj_flags} -funwind-tables"
+  powerpc*-linux*)
+	sysdeps_dir=powerpc
 	libgcj_interpreter=yes
 	enable_hash_synchronization_default=yes
+	slow_pthread_self=yes
 	;;
   xscale*-elf)
 	with_libffi_default=no

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2002-04-08 20:17 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <87vgbpkdq9.fsf@creche.redhat.com>
2002-03-21 11:59 ` Patch: FYI: gcj3.1 status update Rainer Orth
2002-03-22 11:27   ` Tom Tromey
2002-03-27 12:19     ` Rainer Orth
2002-03-27 15:48       ` Tom Tromey
2002-03-27 15:52         ` Rainer Orth
2002-03-28  5:11           ` Rainer Orth
2002-04-02 18:53             ` Tom Tromey
2002-04-03 11:27               ` Andrew Haley
2002-04-05  7:57                 ` Andrew Haley
2002-04-05  8:02                   ` Jeff Sturm
2002-04-05  9:27                     ` Andrew Haley
2002-04-05 10:01                       ` Jeff Sturm
2002-04-05 10:19                         ` Andrew Haley
2002-04-05 20:20                   ` Bryce McKinlay
2002-04-08 13:18                   ` Tom Tromey
2002-04-02 19:04           ` Tom Tromey
2002-03-27 16:06 Billinghurst, David (CRTS)
2002-03-28 16:21 Billinghurst, David (CRTS)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).