[concurrency-interest] Why not J2SE 5?
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
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