Java6 vs Java5

[Shaun Hennessy]

A few quick questions I'm hoping someone can help me with...
(I'm running Java6u12)

1) Is there any plans for the new option 
CMSInitiatingPermOccupancyFraction (CR 6634032)
to put into Java6?  (The fixed in listed as hs13(b01) - I'm not sure 
what this is - Java7?)

2) Was there a change in the default CMS initiating occupancy from Java5 
to Java6 (68% to 92%)
when using CMS?

3a) If using the Throughput GC -- our old-gen will be triggered when 
it's full right? There's no need
to have it go earlier as we're going to stop-the-world....   Nothing 
would be different java5 vs java6?

3b) - If I am going to the throughput collector, is there anyway to 
force the application to keep
a certain amount of the heap free (ie -Xms=Xms=256M --) I always want to 
get say 100M free
so once the free heap drop to that level trigger a GC?  (Basically I 
want a CmsInitiatingOccupancyFraction
but for the throughput collector)


(answers would be great, but if anyone wants to know background or why 
on earth I'd want 3b...read on)
I got 2 problem; Problem1 - Application 1 - trying to eliminate 
concurrent mode failures which having more of since
upgrading  to java6 (because of 1) I think), solution is to lower 
setting back, but then I run into continous GC's due to
Perm Space because it sits above 68% than I now manually set.    
Problem2 - Application2 -- we've got a lovely
"workaround" to another problem such we are now going to check the free 
heap and if we go below a threshold we'll
change our application behavior.   I don't know if we now hitting this 
now because of switch to java6 or just
because of changes to our application ( and yes I know the real solution 
is to get rid of this idiotic check but I'm just
the tester now not the designer anymore....) --- we used to use the 
throughput collector but to try and get this
behavior (and the CmsInitiatingOccupancyFraction) I'm switching to CMS 
--- but now I'm getting out of heap
messages (at the same time we did also drop from 512->256 on Xmx) -- so 
I'm not sure it's fragmentation on CMS
or if 256M really isn't enough -- jcsonsole showed we were 195M used out 
of 230M on old gen before we hit out of mem.

thanks,
Shaun