EVALUATION
###@###.### 2002-06-24
unpacked attachments in .../GammaBase/Bugs/4707386
the directories that dbx is trying to access and the method names in stack trace
indicate this problem is occurring with compiler1.
[17] cMGraphBuilderYbuild_transitive_closure
....
[22] cLCompilationJbuild_hir
-----
This is probably an OutOfMemoryError propagating into the CI. We would like to
look at the core file to confirm this. In this case the workaround is to
increase the heap size; the OutOfMemoryError would have probably hit another
portion of their application anyway. In this case it's likely to be the
permanent generation filling up so the customer should specify e.g.,
-XX:MaxPermSize=128m (default is 32m, increased to 64m in later releases.)
Otherwise -Xmx can be used.
###@###.### 2002-06-25
We looked at the core file and this is definitely what's happening. Updated the
workaround. We'll make more systematic changes to fix this problem in 1.4.2.
###@###.### 2002-06-25
The set of changes for this bug fix were begun by
###@###.###. In general the approach taken has been to
return values in certain circumstances which will not crash the
compiler but will allow it to either bail out or to continue the
compile as best as possible. A bailout flag has been added to the
ciEnv so there is no possibility that machine code will be registered
during a compile where an OutOfMemoryError occurred. Two new
non-product flags, CIFireOOMAt and CIFireOOMAtDelay, have been added
to stress the system. CIFireOOMAt specifies a per-compile number of
accesses through the CI before OutOfMemoryErrors begin to be thrown
manually from a few key places in the CI's implementation.
CIFireOOMAtDelay supplies a global delay before these OOMs begin to be
fired. The latter allows C2 to generate its stubs before stressing the
bailouts in the compiler.
Currently CTW runs with C1 look fairly clean (have only run to ~15000
compiles). Thanks mostly to help from ###@###.###, C2 is
handling these OOMs reasonably well at this point and hundreds of
compiles with dozens of bailouts can be run. There are still some
assertion failures seen, some of which are related to fetching of
intrinsics (which I don't understand) and others which are caused by
the incorrect typing of some of the error values returned by the CI.
We'll spend more time after code freeze looking into the remaining
assertion failures seen during stress testing.
###@###.### 2002-11-01
removed 1.4.1_03 from the commit list as part of clean-up.
###@###.### 2004-09-16
|
Java