Greetings,

An off-thread e-mail conversation with Mikael G revealed that Ron
missed deleting a now unused static global and I missed that fact
during my code review.

$ diff -C 5 src/share/vm/utilities/debug.cpp.cr0 src/share/vm/utilities/debug.cpp
*** src/share/vm/utilities/debug.cpp.cr0        Tue Feb 19 13:44:46 2013
--- src/share/vm/utilities/debug.cpp    Wed Feb 20 06:36:42 2013
***************
*** 226,238 ****
  void report_fatal(const char* file, int line, const char* message)
  {
    report_vm_error(file, line, "fatal error", message);
  }

- // Used by report_vm_out_of_memory to detect recursion.
- static jint _exiting_out_of_mem = 0;
-
  void report_vm_out_of_memory(const char* file, int line, size_t size,
                               const char* message) {
    if (Debugging) return;

    Thread* thread = ThreadLocalStorage::get_thread_slow();
--- 226,235 ----

Since this is a simple unused variable delete, we're hoping to avoid
sending a new webrev. However, if Code Review Round 0 motivates other
changes, then the above change will be included in a new webrev.

Dan


On 2/19/13 4:48 PM, Daniel D. Daugherty wrote:
Greetings,

I'm sponsoring this code review request from Ron Durbin. This change
is targeted at JDK8/HSX-25 in the RT_Baseline repo.

Dan


I have a proposed fix for the following bug:

6799919 Recursive calls to report_vm_out_of_memory are handled incorrectly
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6799919
    https://jbs.oracle.com/bugs/browse/JDK-6799919

This is one of those bug fixes where the commit message nicely describes
the change:

6799919: Recursive calls to report_vm_out_of_memory are handled incorrectly Summary: report_vm_out_of_memory() should allow VMError.report_and_die() to handle multiple out of native memory errors.
Reviewed-by: dcubed, <other-reviewers>
Contributed-by ron.dur...@oracle.com

Here is the webrev URL:

http://cr.openjdk.java.net/~dcubed/for_rdurbin/6799919-webrev/0-hsx25

Testing:
- See the READ_ME file attached to the JDK-6799919 for the gory details
     of the testing needed to reproduce this failure and verify the fix
   - regular JPRT test job is in process

Comments, questions and suggestions are welcome.

Ron


Reply via email to