RMI DGC questions

[Robert DiFalco]

Right, that is the RFE. Thanks for the info Peter. This is a pretty
large issue for use as those threads cause servers with many client
calls and call backs to run out of memory unnecessarily. 

I notice there are a few subtleties that I can see (class loading,
timing, multiple modifiers to the pending list, etc) but I'm sure there
are others I can't. It's unfortunate that the test coverage is weak. 

A simple approach (that would have less unintended consequences) would
be a shared reference queue with a single thread but still spawn a
thread per usual if there is actual LiveRef DGC and Lease work to be
done (keeping the processing code in the polling loop essentially the
same). But still, it would be difficult to ensure I wasn't changing
(possibly undocumented) behavior that people have relied on. A property
setting to switch between the old and new behavior could mitigate some
of the risk around that.

Are you familiar enough with (or remember enough about) the code to
verify that this is a good approach to take? 

-----Original Message-----
From: Peter Jones [mailto:peter.jones at sun.com] 
Sent: Tuesday, October 28, 2008 12:40 PM
To: Robert DiFalco
Cc: core-libs-dev at openjdk.java.net
Subject: Re: RMI DGC questions

On Sat, Oct 25, 2008 at 09:37:35AM -0700, Robert DiFalco wrote:
> I'm thinking of making a change but wanted to gather some background 
> first. I would like to change DGC so that all sockets will uses a 
> single thread and reference queue. When there is work to be done, only

> then will that work be sent to a thread pool.
> 
> My big question is, why hasn't this been done before? It appears to be

> a relatively simple change to make that would result in saving a 
> thread per connection? People are always complaining about these renew

> clean threads and they really cut down on scalability, so I want to 
> find out what has prevented people from making this change in the past

> to make sure I am not overlooking something.

It sounds like you want to implement this RFE:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5053529

(Note that the word "object" has been inappropriately replaced by
"customer" in the public version of that bug report.)

It would certainly be great to have this done.  I would say that it has
been an issue of engineering resources rather than technical impediment.
It may seem like a relatively simple change-- involving only one class,
sun.rmi.transport.DGCClient-- but it's not entirely trivial either,
there are some subtleties to that class.  Moreover, I think that there
is currently negligible test coverage of the code in that class, so a
concern is that such a rework of its concurrency is risky without
improving its test coverage as well.

> Also, is there a straight forward soup to nuts article on downloading,

> modifying code, building, testing, and submitting the change for the 
> core libraries? Do I have to build everything or is there a way to 
> just build my effected jars and use binary plugs so that I don't have 
> to rebuild native code? Can I just copy that rebuilt jar over to my 
> JRE in order to test?

Have you looked at the links under "Hack on the JDK itself" at
http://openjdk.java.net/ ?  Others might have additional pointers.  As
far as building a subset, personally I would typically just build the
whole "jdk" repository (as opposed to "hotspot", etc.) for core library
changes, but that still involves building native code.

-- Peter