On Wed, 9 Jan 2002, Dan Ingalls wrote:

> 4606LessFullGCs-ar -- Andreas Raab -- 12 December 2001 Remove the need
> for garbage collections in two cases.

> Case #2: Socket creation required a full GC if the creation failed.
> This can only happen if the number of open sockets is above a critical
> threshold (and therefore exceed OS resources) and some sockets are
> dangling (and could be used to free up resources). A registry
> threshold can prevent execution of a full GC until we have at least a
> certain number of sockets open.

This changeset appears to be incomplete.

There are changes to 'Socket class', to add a class variable and methods
to initialize, read, and write it, but no changes to any methods in Socket
that use any of the new functionality.

The origional changeset on Dec12th
   'RE: Full garbage collection throughtout the system'
includes those extra bits. (I have not tested it.)

--

Also, along this vein, there are two other things to consider.

On, Dec 13th, I posted a message with a subject of:
   ``[ENH] Remove fullGC's throughout the image.'' that removes/reduces
quite a few other instances of full GC in the image.

And finally, Andraas Raab's patch I forwarded on Dec 9th
   `[VM] [FIX] [ENH] RE: GC root table overflow ' which makes a root table
overflow a lot cheaper (I estimate about 70x, assuming default VM
paramaters and an 10mb free space). There are 20-30 root table overflows
during a typical macroBenchmarks, consuming 5% of the overall runtime.
(The root table overflows occur in #2, #3.)

--

Anyone try running with all of these changes? Can you run a
macrobenchmarks with no fullGC's at all?

Soon, I'll be rebuilding a new image and VM and I'll do these tests. (I'm
curious as to the total cumulative impact of all of this VM work.)

Scott