Running SunOne appserver on build 21 of 1.4.2, the parallel gc goes into an infinite loop. Here's what the stack of the infinite loop looks like:

=>[1] ConstantPoolCacheEntry::follow_contents(0xf5a4c570, 0x0, 0x97281978, 0x7745c4, 0x43d6ac, 0xfe1604b8), at 0xfe0cabc8
  [2] constantPoolCacheKlass::oop_follow_contents(0xf5400c90, 0xf5a4c4b0, 0x97281548, 0x0, 0x1, 0xabbd379), at 0xfe121030
  [3] MarkSweep::follow_stack(0xfe5be6c4, 0x11a, 0x0, 0x1, 0x2a6c0, 0x0), at 0xfe47a4e8
  [4] PSMarkSweep::mark_sweep_phase1(0x97281914, 0x0, 0x1, 0x42bc, 0x8c928, 0xf1620000), at 0xfe4aff54
  [5] PSMarkSweep::invoke_no_policy(0xfe5b9230, 0x0, 0xfe5c221c, 0xfe5c2224, 0x951f1088, 0xfe5c6968), at 0xfe4af718
  [6] PSScavenge::invoke(0x951f1088, 0xf9fc8cc0, 0xf9800000, 0x6, 0x1f233, 0xfe147120), at 0xfe4b4ab4
  [7] ParallelScavengeHeap::failed_mem_allocate(0x29f78, 0x951f1088, 0x6, 0x0, 0x0, 0x6), at 0xfe4a1b10
  [8] VM_ParallelGCFailedAllocation::doit(0x951f106c, 0xf9c09cc0, 0x1, 0xfe57a000, 0xf9800000, 0x6), at 0xfe4f6ce4
  [9] VM_Operation::evaluate(0x951f106c, 0x4400, 0xfe57a000, 0x2e6e8, 0x4affb0, 0xfe1e31a4), at 0xfe22f7a0
  [10] VMThread::evaluate_operation(0x13caf8, 0x951f106c, 0x5000, 0x5084, 0x5000, 0x0), at 0xfe22f1c0
  [11] VMThread::loop(0x4400, 0x4000, 0x42cc, 0x4000, 0x4258, 0x3800), at 0xfe2f34d8
  [12] VMThread::run(0x13caf8, 0xd, 0x40, 0x0, 0xc, 0xff37e000), at 0xfe2f2fe0
  [13] _start(0x13caf8, 0xff37f688, 0x1, 0x1, 0xff37e000, 0x0), at 0xfe266b04

Although the loop itself is not in the leaf method here, as here's another stack snapshot:

=>[1] instanceKlass::oop_follow_contents(0xf54c5e38, 0x997038b0, 0x97281548, 0x0, 0x1, 0xabbd379), at 0xfe0c7a18
  [2] MarkSweep::follow_stack(0xfe5be6c4, 0x11a, 0x0, 0x1, 0x2a6c0, 0x0), at 0xfe47a4e8
  [3] PSMarkSweep::mark_sweep_phase1(0x97281914, 0x0, 0x1, 0x42bc, 0x8c928, 0xf1620000), at 0xfe4aff54
  [4] PSMarkSweep::invoke_no_policy(0xfe5b9230, 0x0, 0xfe5c221c, 0xfe5c2224, 0x92691308, 0xfe5c6968), at 0xfe4af718
  [5] PSScavenge::invoke(0x92691308, 0xf9834680, 0xf9800000, 0x6, 0xd1a, 0xfe147120), at 0xfe4b4ab4
  [6] ParallelScavengeHeap::failed_mem_allocate(0x29f78, 0x92691308, 0x14, 0x0, 0x0, 0x6), at 0xfe4a1b10
  [7] VM_ParallelGCFailedAllocation::doit(0x926912ec, 0xf9ea3f00, 0x1, 0xfe57a000, 0xf9800000, 0x6), at 0xfe4f6ce4
  [8] VM_Operation::evaluate(0x926912ec, 0x4400, 0xfe57a000, 0x2e6e8, 0x4affb0, 0xfe1e31a4), at 0xfe22f7a0
  [9] VMThread::evaluate_operation(0x13caf8, 0x926912ec, 0x5000, 0x5084, 0x5000, 0x0), at 0xfe22f1c0
  [10] VMThread::loop(0x4400, 0x4000, 0x42cc, 0x4000, 0x4258, 0x3800), at 0xfe2f34d8
  [11] VMThread::run(0x13caf8, 0xd, 0x40, 0x0, 0xc, 0xff37e000), at 0xfe2f2fe0
  [12] _start(0x13caf8, 0xff37f688, 0x1, 0x1, 0xff37e000, 0x0), at 0xfe266b04

My best guess is that the loop is in MarkSweep::follow_stack; that's the common element I've seen in all the stack snapshots I've done.

The VM is being run with these arguments:
-server -XX:+AggressiveHeap -Xmx1500m -Xms1500m -Xss128k -XX:+DisableExplicitGC

I can only reproduce this bug running SPECjAppServer, which is fairly complex to setup. Contact me for access to an existing setup on which to debug.