LGTM++ and trivial.
Thanks,
Serguei
On 5/11/20 21:38, Igor Ignatyev wrote:
LGTM
-- Igor
On May 11, 2020, at 9:28 PM, David Holmes wrote:
This test recently starting running with -Xcheck:jni applied and is failing, so
we want to problem-list it until the issue can be investigated
diff -r
Thanks Igor!
David
On 12/05/2020 2:38 pm, Igor Ignatyev wrote:
LGTM
-- Igor
On May 11, 2020, at 9:28 PM, David Holmes wrote:
This test recently starting running with -Xcheck:jni applied and is failing, so
we want to problem-list it until the issue can be investigated
diff -r bbdcc6741915
LGTM
-- Igor
> On May 11, 2020, at 9:28 PM, David Holmes wrote:
>
> This test recently starting running with -Xcheck:jni applied and is failing,
> so we want to problem-list it until the issue can be investigated
>
> diff -r bbdcc6741915 test/hotspot/jtreg/ProblemList.txt
> ---
This test recently starting running with -Xcheck:jni applied and is
failing, so we want to problem-list it until the issue can be investigated
diff -r bbdcc6741915 test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt
+++ b/test/hotspot/jtreg/ProblemList.txt
@@ -108,6
On 05/11/2020 17:21, serguei.spit...@oracle.com wrote:
On 5/11/20 17:17, Alex Menkov wrote:
On 05/11/2020 17:08, Yasumasa Suenaga wrote:
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a
thread "_thread_blocked" VM does
On 5/11/20 17:33, Yasumasa Suenaga wrote:
On 2020/05/12 9:17, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
On 5/11/20 17:08, Yasumasa Suenaga wrote:
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a
thread
Hi Alex,
On 2020/05/12 9:17, Alex Menkov wrote:
On 05/11/2020 17:08, Yasumasa Suenaga wrote:
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a thread
"_thread_blocked" VM does not need to suspend it at safepoint.
I think
On 2020/05/12 9:17, serguei.spit...@oracle.com wrote:
Hi Yasumasa,
On 5/11/20 17:08, Yasumasa Suenaga wrote:
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a thread
"_thread_blocked" VM does not need to suspend it at
On 05/11/2020 17:08, Yasumasa Suenaga wrote:
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a
thread "_thread_blocked" VM does not need to suspend it at safepoint.
I think so, but if state would be transit to the other
On 5/11/20 17:17, Alex Menkov wrote:
On 05/11/2020 17:08, Yasumasa Suenaga wrote:
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a
thread "_thread_blocked" VM does not need to suspend it at safepoint.
I think so, but if
Hi Yasumasa,
On 5/11/20 17:08, Yasumasa Suenaga wrote:
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a
thread "_thread_blocked" VM does not need to suspend it at safepoint.
I think so, but if state would be transit to
Updated webrev:
http://cr.openjdk.java.net/~amenkov/jdk15/RemovingUnixDomainSocket/webrev.3/
--alex
On 05/11/2020 14:12, Alex Menkov wrote:
Please hold on with the review.
webrev.2 causes LingeredApp crash.
Looks like need to decrease ThreadBlockInVM scope.
Will send new version after
On 2020/05/12 9:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a thread
"_thread_blocked" VM does not need to suspend it at safepoint.
I think so, but if state would be transit to the other in is_init_trigger(), it
might be affect to
Hi Alex,
I see the point, thanks.
Serguei
On 5/11/20 17:01, Alex Menkov wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a
thread "_thread_blocked" VM does not need to suspend it at safepoint.
--alex
On 05/11/2020 15:36, serguei.spit...@oracle.com wrote:
Hi Serguei,
If I understand correctly, this also should work - when we mark a thread
"_thread_blocked" VM does not need to suspend it at safepoint.
--alex
On 05/11/2020 15:36, serguei.spit...@oracle.com wrote:
Hi Alex,
I'm not sure this update suggested by Yasumasa is right:
536 // avoid
Hi Alex,
I'm not sure this update suggested by Yasumasa is right:
536 // avoid deadlock if AttachListener thread is blocked at safepoint
537 ThreadBlockInVM tbivm(JavaThread::current());
538 while (AttachListener::transit_state(AL_INITIALIZING,
539
Hi Alex,
LGTM
Thank you for the update!
Serguei
On 5/11/20 14:14, Alex Menkov wrote:
Hi Serguei, Alan,
Updated webrev:
http://cr.openjdk.java.net/~amenkov/jdk15/java_instrument_spec/webrev.2/
--alex
On 05/11/2020 11:52, Alan Bateman wrote:
On 11/05/2020 19:21, serguei.spit...@oracle.com
Hi Serguei, Alan,
Updated webrev:
http://cr.openjdk.java.net/~amenkov/jdk15/java_instrument_spec/webrev.2/
--alex
On 05/11/2020 11:52, Alan Bateman wrote:
On 11/05/2020 19:21, serguei.spit...@oracle.com wrote:
Hi Alex,
There is no need to repeat this:
"deploy applications thatpackage an
Please hold on with the review.
webrev.2 causes LingeredApp crash.
Looks like need to decrease ThreadBlockInVM scope.
Will send new version after completing test run.
On 05/11/2020 13:52, Chris Plummer wrote:
228 // If the app hangs, we don't want to wait for the to
test
228 // If the app hangs, we don't want to wait for the to
test timeout.
Sorry, there was a typo in my suggestion. Should be "test to", not "to
test".
thanks,
Chris
On 5/11/20 12:53 PM, Alex Menkov wrote:
Hi Yasumasa, Serguei, Chris,
Thank you for the feedback
updated
BTW, I just found out that due to a fix for JDK-8220295 early last year,
the jdk/sun/tools tests are not run in parallel, so at least atm are not
contributing to any host memory related issues. Still it is best to fix
them now.
Chris
On 5/11/20 10:54 AM, Chris Plummer wrote:
Hi Daniil,
Hi Yasumasa, Serguei, Chris,
Thank you for the feedback
updated webrev (all suggestions are applied):
http://cr.openjdk.java.net/~amenkov/jdk15/RemovingUnixDomainSocket/webrev.2/
On 05/11/2020 00:31, serguei.spit...@oracle.com wrote:
Hi Alex,
It looks good in general.
I have a couple of minor
Hi Daniil,
In the grand scheme of things, could servicability use the signature
parsing support in HotSpot?
Thanks, Roger
On 5/9/20 12:29 PM, Daniil Titov wrote:
Please review a change[1] that centralizes the signature processing in
serviceability tools to make it capable of being easily
I do not see my message reached the
serviceability-dev mailing list.
Resending...
On 5/11/20 00:31, serguei.spit...@oracle.com wrote:
Hi Alex,
It looks good in general.
I have a couple of minor comments.
On 11/05/2020 19:21, serguei.spit...@oracle.com wrote:
Hi Alex,
There is no need to repeat this:
"deploy applications thatpackage an agent with the application,
or use tools that load agents into a running application"
I'd suggest to rephrase it to something like:
"Agents can transform
Hi Daniil,
It looks pretty good in general.
A couple of nits below.
http://cr.openjdk.java.net/~dtitov/8241080/webrev.01/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c.udiff.html
+void *cursor;
+jbyte argumentTag;
+jint argIndex = 0;
+
Hi Alex,
There is no need to repeat this:
"deploy applications that package an agent with the application,
or use tools that load agents into a
running
application"
I'd suggest to rephrase it to something like:
> On May 8, 2020, at 12:48 PM, Daniel D. Daugherty
> wrote:
>
> On 5/7/20 1:35 AM, Mikael Vidstedt wrote:
>> New webrev here:
>>
>> webrev:
>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/hotspot/open/webrev/
>
> This pretty much says it all:
>
> > Summary of changes:
Hi Daniil,
Overall looks good. Just one minor thing. In ClassTypeImpl.c and
ObjectReferenceImpl.c I think the following would be more readable with
an if/else:
79 return JNI_FUNC_PTR(env,ExceptionOccurred)(env) ?
AGENT_ERROR_JNI_EXCEPTION
80 : JVMTI_ERROR_NONE;
Hi Daniil,
Looks good.
thanks,
Chris
On 5/11/20 9:43 AM, Daniil Titov wrote:
Hi Chris,
Please review a new version of the fix[1] that also updates jdk/sun/tools
tests.
Testing: Mach5 tier1-tier7 tests successfully passed.
[1] http://cr.openjdk.java.net/~dtitov/8242009/webrev.03/
[2] ]
Hi Alex,
228 // if for a reason the app hangs, we don't want to
wait test timeout
229 if
(!appProcess.waitFor(Utils.adjustTimeout(appWaitTime), TimeUnit.SECONDS)) {
Can you fix the comment. Maybe:
228 // If the app hangs, we don't want to wait for the
Hi Chris,
Please review a new version of the fix[1] that also updates jdk/sun/tools
tests.
Testing: Mach5 tier1-tier7 tests successfully passed.
[1] http://cr.openjdk.java.net/~dtitov/8242009/webrev.03/
[2] ] https://bugs.openjdk.java.net/browse/JDK-8242009
Thank you,
Daniil
On 5/8/20,
Hi,
I think it would be very convenient for app developers if JVM were able to
create intermediate directories to gc.log file if they do not exist.
I.e.
$ if [ -f logs/gc.log ]; then echo "log file exists"; else echo "log file
does not exist"; fi
log file does not exist
$ if [ -d logs ];
Hi Alex,
It looks good in general.
I have a couple of minor comments.
http://cr.openjdk.java.net/~amenkov/jdk15/RemovingUnixDomainSocket/webrev/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html
+// if for a reason the app hangs, we don't
34 matches
Mail list logo
