RFR: 8158412: [TESTBUG] TestIHOPErgo and TestStressG1Humongous should not be executed when JFR is enabled
dmitry.fazunenko at oracle.com
Tue Jun 14 13:23:31 UTC 2016
On 14.06.2016 15:22, Thomas Schatzl wrote:
> Hi Mikael,
> On Wed, 2016-06-08 at 16:49 +0300, 8038818: Test nsk/jvmti/GetOwnedMonitorInfo/ownmoninf001 fails with wrong number of monitors
> 8071659: Name change for functionality exposed as "Loaded Modules" to prepare for Jigsaw ("Modules")
> 8138705: Kitchen sink stress test fails
> 8150737: jdk.vm.cds.CacheManager should throw NPE when given null loader
> 8152239: hotspot/test/gc/TestSmallHeap.java failed in jdk9
> 8152404: Stabilize PackageEntry::package_exports_do
> 8154750: Add missing OrderAccess operations to ClassLoaderData lock-free data structures
> 8155009: [TESTBUG] jstack subtest of BasicLauncherTest should not be executed under OS X
> 8155936: Boolean value should be set 1/0 or true/false via VM.set_flag jcmd
> 8156537: Tools using MonitoredVmUtil do not parse module in cmdline correctly
> 8156923: [ppc] Implement "JEP 270: Reserved Stack Areas for Critical Sections".
> 8157189: 'iload_w' in shared class is not interpreted correctly.
> 8157836: A test to verify the default FlightRecorderListener.recordingStateChanged method implementation
> 8157954: [TESTBUG] G1 tests fail with defined MaxGCPauseMillis
> 8158240: A test for Recording.copy() JFR public API
> 8158397: Crash: assert(save_resolved_method == resolved_method()) failed: does this change?
> 8158570: missed space in vm options in ATR configuration
> 8158579: hs-promotion-l2 task-definition doesn't use different flagsChernov wrote:
>> Could I have a reviews for this small fix? The fix adds new custom
>> setting for @requires tag - vm.FlightRecorder. New setting is used
>> all updated tests. Tests will be exclude if JFR is enabled.
>> Testing - RBT.
> seems okay, however the syntax to use vm.FlightRecorder seems
> awkward, i.e.
> "vm.FlighRecorder != true"
> Isn't there a way to make it something more common like
> Not insisting on this, just asking.
Yes, there is no need to use vm.xxx != true anymore, for those
properties which are set by our plugin (VMProps).
All such properties will never be set to 'null', as it's possible for
vm.opt.xxx, which are set by jtreg.
So, using !vm.FlightRecored is safe.
More information about the hotspot-gc-dev