[concurrency-interest] Why not J2SE 5?

Gregg Wonderly gregg.wonderly@pobox.com
Mon, 06 Dec 2004 09:19:16 -0600

Doug Lea wrote:
> And maybe it takes time to install/deploy new JVMs across all
> machines etc. But is there some more fundamental reason that I'm
> overlooking?

I am trying to move to J2SE5.0 on linux.  One of the problems that we 
say up front was that it was still possible to crash the JVM in native 
code.  There are numerous bug reports about this type of problem in the 
bug parade.  My application is large, consisting of over 1000 class 
files, and when it crashes, bug reports are met with a request for a 
sample test case that reproduces the problem.  This is a fine question 
to ask, but in my case, I can't see the real problem due to the way the 
JVM expresses the problem.  The GC logging and the general interfaces to 
the GC activity still don't tell you near what they should with explicit 
information about the situation at death.

So, in our case, we are deploying the same software into a new 
application where we have no compatibility issues to deal with (if they 
actually exist).  But, because of the crashes, we can't tell whether its 
the JVM that has problem, or our GC configuration parameters.  So, I get 
pressure from my management to go back to 1.4.2.  Because of the 
difference in JVMs and GCs, it's possible that just this change alone 
will eliminate border cases for GC configuration parameters.

I believe that what the GC should do instead, by default is grow any 
area that it needs, and use a WARNING level log entry to indicate it is 
changing configuration, and output the 'current' set of parameters that 
would be needed to configure the GC to operate in that configuration. 
Then a -XX:nogcautoconfig parameter should be available to shut this 
down, if I really have an environment where code is randomly injected 
and I do need to keep the JVM from taking over the machine.

I'm not a GC configuration expert, so maybe this is possible and I've 
missed that documentation.  But, memory use and crashing JVMs because of 
misconfigured GC parameters is the biggest pain that I have to deal with 
on a regular basis, and the obscurity of these crashes is problematic.

And a related issue is the fact that there is not a built in JVMDI 
module that will trace the number of allocations of each and every type 
of Object in the JVM.  The forsale tools that do this already are too 
pricey because there is no competition in this area.  I also need 
operational interfaces to such tools that use either JMX or Jini (I 
prefer an RMI interface that I can plug JERI into for real security) so 
that I can perform remote, automated inspection and control to the