> Hi, Please review
>
> When debugging for other test case which uses jcmd to attach LingeredApp
> process, found there is no error information logged when the app started with
> function 'startAppExactJvmOpts' exits due to some reason. This is not
> convenient for trace what is the app failur
On Tue, 23 Feb 2021 03:43:41 GMT, Chris Plummer wrote:
>> It seems error prone to have to call finishApp() manually in order to see
>> the error log. Since LingeredApp.startApp calls finishApp() on exceptions,
>> shouldn't startAppExactJvmOpts do the same thing?
>
> Although you have a point, y
On Tue, 23 Feb 2021 03:08:16 GMT, Ioi Lam wrote:
>> test/lib/jdk/test/lib/apps/LingeredApp.java line 419:
>>
>>> 417: theApp.waitAppReady();
>>> 418: } catch (Exception ex) {
>>> 419: theApp.finishApp();
>>
>> I'm worried about the output appearing twice in some
On Tue, 23 Feb 2021 02:55:01 GMT, Chris Plummer wrote:
>> Hi, Please review
>>
>> When debugging for other test case which uses jcmd to attach LingeredApp
>> process, found there is no error information logged when the app started
>> with function 'startAppExactJvmOpts' exits due to some reas
On Mon, 22 Feb 2021 22:26:50 GMT, Yumin Qi wrote:
> Hi, Please review
>
> When debugging for other test case which uses jcmd to attach LingeredApp
> process, found there is no error information logged when the app started with
> function 'startAppExactJvmOpts' exits due to some reason. This i
On Tue, 16 Feb 2021 07:28:45 GMT, Chris Plummer wrote:
> See CR for details. In brief, fixed the `inspect` command to remove duplicate
> output:
>
> hsdb> inspect 0x0007fef00770
> instance of Oop for java/lang/Class @ 0x0007fef00770 @ 0x0007fef00770
> (size = 160)
> in: Oop for jav
On Mon, 22 Feb 2021 12:05:20 GMT, Kevin Walls wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Put replicated strings into a local variable.
>
> Marked as reviewed by kevinw (Committer).
Thanks Serguei and Kevin!
> The fix also partially fixes JdwpAttachTest failures (JDK-8253940).
> The failures are caused by network configuration changes during test
> execution ("global" IPv6 addresses disappears from interface).
> To minimize chances of intermittent failures like this java.net tests use
> only link-loc
On Mon, 22 Feb 2021 17:34:03 GMT, Daniel Fuchs wrote:
>
>
> I don't see any specific issue with the proposed change but I don't know the
> JDWP tests enough to provide more feedback than that. Do you have special
> test cases for the IPv6 loopback? AFAIU this code here will filter it out?
Go
Adding serviceability-dev@... to this email thread since JVM/TI
is maintained by the Serviceability Team...
Dan
On 2/22/21 3:29 AM, kalinshi(施慧) wrote:
Hi hotspot experts,
Would you help on my question about JvmtiExport::can_walk_any_space() check?
Question is why JvmtiExport::can_walk_any_sp
On Thu, 18 Feb 2021 21:43:00 GMT, Alex Menkov wrote:
> The fix also partially fixes JdwpAttachTest failures (JDK-8253940).
> The failures are caused by network configuration changes during test
> execution ("global" IPv6 addresses disappears from interface).
> To minimize chances of intermittent
On Thu, 18 Feb 2021 06:43:04 GMT, Chris Plummer wrote:
>> It looks good to me.
>> One side comment about the test. It is not easy to read the code with the
>> same pattern (e.g. "Oop for java/io/BufferedInputStream") repeated several
>> times. I understand, you prefer to make it more explicit b
On Thu, 18 Feb 2021 06:43:01 GMT, Chris Plummer wrote:
>> See CR for details. In brief, fixed the `inspect` command to remove
>> duplicate output:
>>
>> hsdb> inspect 0x0007fef00770
>> instance of Oop for java/lang/Class @ 0x0007fef00770 @
>> 0x0007fef00770 (size = 160)
>> in: Oop
13 matches
Mail list logo
