JDK-6190855 : nsk.jvmpi.endisgc001 fails due to changes in RFE CR#5101236
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-11-04
  • Updated: 2012-10-01
  • Resolved: 2004-11-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b14Fixed
Related Reports
Relates :  
JDK-6186200 - RFE: Stall allocation requests while heap is full and GC locker is held
Description
This bug affects the following NSK test:

    nsk/jvmpi/EnableDisableGC/endisgc001
###@###.### 11/4/04 19:02 GMT
Comments
WORK AROUND Don't Disable GC. ###@###.### 11/5/04 00:09 GMT
05-11-2004
SUGGESTED FIX ------- collectorPolicy.cpp ------- *** /tmp/sccs.1WaypB Thu Nov 4 16:05:17 2004 --- collectorPolicy.cpp Thu Nov 4 16:04:34 2004 *************** *** 167,172 **** --- 167,173 ---- // Loop until the allocation is satisified, // or unsatisfied after GC. for (int try_count = 1; /* return or throw */; try_count += 1) { + HandleMark hm; // discard any handles allocated in each iteration // First allocation attempt is lock-free. Generation *gen0 = gch->get_gen(0); *************** *** 201,216 **** return result; } ! // XXX FIX ME !!! ! // The following line has implicit knowledge of TLAB allocation ! // policy and needs to be suitably factored out. It's currently ! // as it is to avoid the safepoint GC attempt further below ! // when GC locker is active. We might decide to allow TLAB ! // allocation in older gens in the future, in which case ! // the following 3 lines of code will have become a no-op ! // because the previous attempt_allocation would return ! // TLAB storage from the older generation. ! if (is_tlab && GC_locker::is_active_and_needs_gc()) { return NULL; } --- 202,213 ---- return result; } ! // Irrespective of whether this is a TLAB allocation ! // or not, if we are unable to satisfy this request ! // and a GC is not allowed at this point, we will ! // return a NULL. This may signal an OOM to the ! // allocating thread; see RFE 6186200. ! if (GC_locker::is_active_and_needs_gc()) { return NULL; } ###@###.### 11/5/04 00:08 GMT The fix has been putback to (Mustang) gc_baseline: Event: putback-to Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline (jano.sfbay:/export/disk05/hotspot/ws/main/gc_baseline) Child workspace: /prt-workspaces/20041108162135.ysr.MT/workspace (prt-web:/prt-workspaces/20041108162135.ysr.MT/workspace) User: ysr Comment: --------------------------------------------------------- Original workspace: neeraja:/net/spot/scratch/ysr/MT Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2004/20041108162135.ysr.MT/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2004/20041108162135.ysr.MT/workspace/webrevs/webrev-2004.11.08/index.html Fixed 6190855: nsk.jvmpi.endisgc001 fails due to changes in RFE CR#5101236 Webrev: http://analemma.sfbay/net/spot/scratch/ysr/MT/webrev.6190855 The regression was inadvertently introduced with my putback for 5101236: it would cause unsatisfied allocation requests to stall until gc locker was vacated. With this change we revert back to the old behaviour of returning an OOM in such an event. (The parallel gc collector was already doing the intended thing.) CR#6186200 will investigate the possibility of the alternative behaviour, at least while jni critical sections have locked out gc. Reviewed by: john.coomes Fix Verified: y Verification Testing: nsk/jvmpi/EnableDisableGC/endisgc001 (tested with the serial collector, aka the jvmpi collector, as well as with the non-jvmpi collectors -XX:-JVMPICheckGCCompatibility) Other testing: spec, PRT, Mingyao's jni locker test Files: update: src/share/vm/includeDB_core update: src/share/vm/memory/collectorPolicy.cpp Examined files: 3191 Contents Summary: 2 update 3189 no action (unchanged) ###@###.### 2004-11-09 18:58:35 GMT
05-11-2004
EVALUATION The regression is related to the changes in 5101236. The regression also points out a potential C-heap leak that preceded the changes in 5101236 but required these changes to unmask that leak. ###@###.### 11/4/04 19:02 GMT
04-11-2004