On Mon, 2 Nov 2020 22:11:48 GMT, Chris Plummer wrote:
> Remove code that retries if RawMonitorEnter is interrupted since that can't
> happen:
>
> https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#RawMonitorEnter
Marked as reviewed by alanb (Reviewer).
-
PR:
On Tue, 20 Oct 2020 09:27:45 GMT, Nick Gasson wrote:
> When using the Linux "perf" tool to do system profiling, symbol names of
> running Java methods cannot be decoded, resulting in unhelpful output
> such as:
>
> 10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
>
> Perf can read a simple
Remove code that retries if RawMonitorEnter is interrupted since that can't
happen:
https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#RawMonitorEnter
-
Commit messages:
- RawMonitorEnter will never return JVMTI_ERROR_INTERRUPT, so don't check for
it.
Changes:
On Mon, 2 Nov 2020 17:52:58 GMT, Erik Österlund wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 1570:
>>
>>> 1568: // return a flag when a method terminates by throwing an exception
>>> 1569: // i.e. if an exception is thrown and it's not caught by the
>>> current method
>>> 1570:
On Mon, 2 Nov 2020 16:20:09 GMT, Coleen Phillimore wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Coleen CR1: Refactoring
>
> This looks better. Just to have the JRT_BLOCK be unconditional is an
>
On Fri, 30 Oct 2020 21:11:09 GMT, Chris Plummer wrote:
> Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls. See CR for
> details.
This pull request has now been integrated.
Changeset: c7747416
Author:Chris Plummer
URL: https://git.openjdk.java.net/jdk/commit/c7747416
On Fri, 30 Oct 2020 20:42:24 GMT, Chris Plummer wrote:
> This RFR removes the debug agent's canSuspendResumeThreadLists() function and
> code that depends on it. Please see the CR for a description of why this is
> being done.
This pull request has now been integrated.
Changeset: ceba2f85
On Fri, 30 Oct 2020 20:30:49 GMT, Chris Plummer wrote:
> The debug agent needs to deallocate memory that is allocated by calls to
> GetAllThreads. There were two places were this was not being done, resulting
> in a memory leak.
This pull request has now been integrated.
Changeset: a250716a
On Fri, 30 Oct 2020 21:11:09 GMT, Chris Plummer wrote:
> Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls. See CR for
> details.
Marked as reviewed by amenkov (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/971
> The debug agent needs to deallocate memory that is allocated by calls to
> GetAllThreads. There were two places were this was not being done, resulting
> in a memory leak.
Chris Plummer has updated the pull request incrementally with one additional
commit since the last revision:
Remove
On Sat, 31 Oct 2020 08:12:50 GMT, Serguei Spitsyn wrote:
>> Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls. See CR for
>> details.
>
> Looks good.
> Thanks,
> Serguei
Ping! I could use one more review. The changes are pretty trivial. Thanks!
-
PR:
On Mon, 2 Nov 2020 16:19:59 GMT, Coleen Phillimore wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Coleen CR1: Refactoring
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1570:
>
>> 1568: // return a flag
On Mon, 2 Nov 2020 16:52:02 GMT, Coleen Phillimore wrote:
>> I thought that we didn't load the archived heap from CDS, if JVMTI heap
>> walker capabilities are in place, as we didn't want this kind of
>> interactions. But maybe I'm missing something, since you said having this if
>> statement
On Mon, 2 Nov 2020 15:45:18 GMT, Erik Österlund wrote:
>> Because it crashed with my changes and didn't without. I cannot recollect
>> why.
>
> I thought that we didn't load the archived heap from CDS, if JVMTI heap
> walker capabilities are in place, as we didn't want this kind of
>
On Mon, 2 Nov 2020 15:18:43 GMT, Erik Österlund wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comments from StefanK.
>
>
On Mon, 2 Nov 2020 11:14:10 GMT, Erik Österlund wrote:
>> The imasm::remove_activation() call does not deal with safepoints very well.
>> However, when the MethodExit JVMTI event is being called, we call into the
>> runtime in the middle of remove_activation(). If the value being returned is
On Mon, 2 Nov 2020 12:50:23 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 954:
>>
>>> 952: o->klass()->external_name());
>>> 953: return;
>>> 954: }
>>
>> Why is this done as a part of this RFE? Is this a bug fix that should be
>>
On Mon, 2 Nov 2020 15:58:15 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote:
> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
> experimental feature. We shipped Graal as an experimental JIT compiler in JDK
> 10. We haven't seen much use of these features, and the effort required to
>
On Mon, 2 Nov 2020 15:58:15 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
> table to follow oops and then to rehash the table, this table
On Fri, 30 Oct 2020 20:46:31 GMT, Erik Joelsson wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote:
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
>
On Mon, 2 Nov 2020 08:08:53 GMT, Stefan Karlsson wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Mon, 2 Nov 2020 08:34:17 GMT, Stefan Karlsson wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 126:
>>
>>> 124: // concurrent GCs. So fix it here once we have a lock or are
>>> 125: // at a safepoint.
>>> 126: // SetTag and GetTag should not post events!
>>
>> I think it would
On Fri, 30 Oct 2020 17:40:51 GMT, Vladimir Kozlov wrote:
> We shipped Ahead-of-Time compilation (the jaotc tool) in JDK 9, as an
> experimental feature. We shipped Graal as an experimental JIT compiler in JDK
> 10. We haven't seen much use of these features, and the effort required to
>
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote:
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
>
On Mon, 2 Nov 2020 08:25:28 GMT, Stefan Karlsson wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore wrote:
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
>
On Sat, 31 Oct 2020 09:54:09 GMT, Serguei Spitsyn wrote:
> Hi Erik,
>
> Nice discovery! Indeed, this is a long standing issue. It looks good in
> general.
> I agree with Coleen, it would be nice if there is an elegant way to move the
> oop_result saving/restoring code to
On Fri, 30 Oct 2020 14:09:46 GMT, Erik Österlund wrote:
>> Oh that's actually horrible. I wonder if it's possible to hoist saving the
>> result oop into the InterpreterRuntime entry. And pass the Handle into
>> JvmtiExport::post_method_exit().
>
> I tried that first, and ended up with a
On Sat, 31 Oct 2020 09:54:09 GMT, Serguei Spitsyn wrote:
>> Erik Österlund has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Coleen CR1: Refactoring
>
> Hi Erik,
>
> Nice discovery! Indeed, this is a long standing issue. It looks good in
> The imasm::remove_activation() call does not deal with safepoints very well.
> However, when the MethodExit JVMTI event is being called, we call into the
> runtime in the middle of remove_activation(). If the value being returned is
> an object type, then the top-of-stack contains the oop.
On Tue, 27 Oct 2020 04:21:33 GMT, Nick Gasson wrote:
>> When using the Linux "perf" tool to do system profiling, symbol names of
>> running Java methods cannot be decoded, resulting in unhelpful output
>> such as:
>>
>> 10.52% [JIT] tid 236748 [.] 0x7f6fdb75d223
>>
>> Perf can read a
34 matches
Mail list logo
