A test fails with following logic:
1) launch VM with -XX:-UseCodeCacheFlushing -XX:-MethodFlushing -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:+SegmentedCodeCache -XX:CompileCommand=compileonly,null::* -XX:CodeCacheSegmentSize=1024
2) get MemoryPoolMXBean for non-profiled nmethods cache
3) get cache usage from bean (getUsage().getUsed())
4) make few small allocations (for example, 1000 bytes)
5) get cache usage from bean (getUsage().getUsed()). This usage will be larger than previous one by 4*CodeCacheSegmentSize, which is unexpected.
note: such behaviour is not reproduced on large(>4096 bytes) allocations
note2: reproducible on different CodeCacheSegmentSize.
(use solaris-sparc latest hs-comp fastdebug build)
Example jtreg hotspot test is attached
1) launch VM with -XX:-UseCodeCacheFlushing -XX:-MethodFlushing -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:+SegmentedCodeCache -XX:CompileCommand=compileonly,null::* -XX:CodeCacheSegmentSize=1024
2) get MemoryPoolMXBean for non-profiled nmethods cache
3) get cache usage from bean (getUsage().getUsed())
4) make few small allocations (for example, 1000 bytes)
5) get cache usage from bean (getUsage().getUsed()). This usage will be larger than previous one by 4*CodeCacheSegmentSize, which is unexpected.
note: such behaviour is not reproduced on large(>4096 bytes) allocations
note2: reproducible on different CodeCacheSegmentSize.
(use solaris-sparc latest hs-comp fastdebug build)
Example jtreg hotspot test is attached