1)We used latest jre8b88 with  Mac OS 10.8.2/x64/FF20/set2u config,The pogo games are passed

2)We used latest jre8b88 winvista-sp2/x86/IE9/set1u config ,The pogo games are passed

3)We used latest jre7u25b10 with solaris11/x86/FF19/set1u config,The pogo games are passed

4)We used latest jre7u25b10 withwin8/x86/IE10/set3u config,The pogo games are passed except one pogo case excluded(set3/pogo_HighStakesPool.html)..

5)We used latest jre7u25b10 with Mac OS 10.7.5/x64/FF20/set2uconfig ,The pogo games are passed

                                     

How about testing on Chrome Browser? Pogo had reported some games hangs, and Java crashes, but browser itself does not crash.
                                     

Chrome configure has been part of test coverage.    What applet(s) did Pogo have the issue with?
                                     

Testsuite name:Applet 
OS:solaris10u11-sparc
Browser:FF19
build:6u51b03
workspace is  downloaded from http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/8/applet

set3/pogo_HighStakesPool.html
set3/pogo_JungleGin.html
set3/pogo_Lottso.html
set3/pogo_PoppaZoppa.html
set3/pogo_ShowbizSlots.html
set3/pogo_Spades.html
set3/pogo_StellarSweeper.html
set3/pogo_TriPeaksSolitaire.html
set3/pogo_WordSearch.html
set3/pogo_WorldClassSolitaire.html

For HighStakesPool game above mentioned can not load alway call cripes and get lost connect issue.refer to HighStakesPool.jpg
others games just can not load at the end .
As for applet suite for set3u some pogo cases are pass,but during downloading is very slow.

                                     

Testsuite name:Applet
OS:solaris10u11 x86
Browser:FF3.5.19
build:5u51b03
workspace is downloaded from http://sqe-hg.us.oracle.com/hg/index.cgi/testbase/javase/functional/8/applet

set2/pogo_Risk
set2/pogo_Scrabble

The two applets cannot be loaded.
                                     

EVALUATION

to allow 7u6 to load the risk applet, pogo needs to either increase heap size to workaround; or make their applet do not depend on re-using the same JVM.

Please note that tuning the heap size is just a workaround.  Solution is to stop relying on reuse of the same JVM for multiple applets.

We can not guarantee it will not start failing again if they will stick to existing approach on relying on reuse of the same JVM for multiple applets.
                                     

SUGGESTED FIX

http://closedjdk.us.oracle.com/jdk8/deploy/deploy/rev/cb818e7c83ea
                                     

EVALUATION

problem:  pogo risk game applet fail to load with 7u6 builds.  we suspect it because we launch new jvm to run applet for the following cases, and their applets depend on all applets running in same jvm.

1.  PluginMain.java, StartAppletListener appletSSVValidation, we have this code:

if (selectedVersion.equals(runningVersion)) {

with beta builds, for example, we compare between 1.8.0 and 1.8.0-ea,  so we try to fire un-necessary jvm relaunch because of this.

2.  JVMHealthData.java, isHealthy, when we make sure available heap size is okay:

getAvailableHeapSize(): 25886008 HEALTHY_AVAILABLE_HEAP_SIZE: 33554432

then we try to kill the unhealthy jvm and relaunch:    Relaunch due to unhealthy JVM: { healthy: false, ageSeconds: 34, availableHeapKB: 14799, appletThreads: 21 }

fix:   For 1, we ignore anything after '-' in the java.version value.
For 2 - we think it's better to ask pogo to increase their max heap setting to 256 instead (from 128 now).