RMI DGC questions
peter.jones at sun.com
Tue Oct 28 19:40:25 UTC 2008
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:
(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.
More information about the core-libs-dev