On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote:
> Recent test regression after adding new cases in the test. Without compressed
> oops, ~1G elements `Object[]` array takes >8G of memory, which fails the
> test. The fix cuts it down to 512M when reference size is 8 bytes.
> Additional
On Wed, 26 Jan 2022 20:15:59 GMT, Chris Plummer wrote:
> This test is failing in the loom repo when using -Xcomp. The reason is
> because loom introduced doing a full GC in the codecache sweeper, which
> causes some of the Objects referenced by ObjectMonitors to be GC'd. The fix
> is to check
On Wed, 26 Jan 2022 20:15:59 GMT, Chris Plummer wrote:
> This test is failing in the loom repo when using -Xcomp. The reason is
> because loom introduced doing a full GC in the codecache sweeper, which
> causes some of the Objects referenced by ObjectMonitors to be GC'd. The fix
> is to check
On Fri, 28 Jan 2022 12:54:37 GMT, David Holmes wrote:
> How are the thread id's determined such that they can change on each attach?
This is all I could find:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/controlling-threads-and-processes
I speculated about it a bit in the
Recent test regression after adding new cases in the test. Without compressed
oops, ~1G elements `Object[]` array takes >8G of memory, which fails the test.
The fix cuts it down to 512M when reference size is 8 bytes. Additionally,
`ObjectAlignmentInBytes=32` is excessive for new test configs.
On Fri, 28 Jan 2022 04:07:40 GMT, Chris Plummer wrote:
>> It's possible for an address to be in the codecache but not in any CodeBlob.
>> Don't assert in this case.
>>
>> Also I ran into a couple of other asserts listed below. It looks like since
>> dumping the threadcontext can result in usin
On Wed, 22 Dec 2021 18:14:43 GMT, Kevin Walls wrote:
> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
>
> Also we can undo the property-setting Launcher.gmk change from: 8279007:
> jstatd fails to start because SecurityManager is disabled
> ..
On Fri, 28 Jan 2022 07:34:21 GMT, Chris Plummer wrote:
> The test does a "threadcontext -v -a", and from the following output
> determines the threadID of the SteadyStateThread:
>
> `Thread "SteadyStateThread" id=23 Address=0x01dc51749420`
>
> It then tries threadcontext on this id, but
> Remove the use of Security Manager from jstatd.
> Add use of an ObjectInputFilter to restrict RMI.
>
> Also we can undo the property-setting Launcher.gmk change from: 8279007:
> jstatd fails to start because SecurityManager is disabled
> ..as that is no longer needed.
>
> Docs/man page update
On Fri, 28 Jan 2022 07:46:40 GMT, Chris Plummer wrote:
>> This test is failing in the loom repo when using -Xcomp. The reason is
>> because loom introduced doing a full GC in the codecache sweeper, which
>> causes the large array that the test allocates to be GC'd before the heap
>> dump is do
10 matches
Mail list logo
