RFR: 8191333: Zero variant broken after 8189941 (original) (raw)
coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Thu Nov 16 19:48:04 UTC 2017
- Previous message: RFR: 8191333: Zero variant broken after 8189941
- Next message: Request for review JDK-8187819 gc/TestFullGCALot.java fails on jdk10 started with "-XX:-UseCompressedOops" option
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 11/16/17 5:14 AM, John Paul Adrian Glaubitz wrote:
On 11/16/2017 10:12 AM, Severin Gehwolf wrote:
Add to that, that most basic tests usually expect a client/server JVM for which Zero is an odd ball. Also, due to it's weaker performance many tests time out and fail rather than conditionally setting longer timeout values. It's a rather large and cumbersome process to make the whole test suite Zero compatible. Thanks for the explanation!
It's more of a case of going through every test one by one and figuring out whether a "failure" is a test issue, a Zero issue, or an environmental issue. So, after all the helpful input from everyone, I have modified my change to kill the handles unconditionally as previously suggested [1]. I would like to have the change applied as in [1] if everyone agrees and if I run into future issues with Zero, I will report them here anyway.
Okay, this looks fine. I just had a look at HandleMarkCleaner and this seems to be what the code expects to be able to do at this point.
This makes me really want to remove the whole HandleMark mechanism and make Handles have destructors.
Thanks, Coleen
Thanks for all the input! Adrian
- Previous message: RFR: 8191333: Zero variant broken after 8189941
- Next message: Request for review JDK-8187819 gc/TestFullGCALot.java fails on jdk10 started with "-XX:-UseCompressedOops" option
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]