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.
Marked as reviewed by amenkov (Reviewer).
-
PR:
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.
Marked as reviewed by amenkov (Reviewer).
-
PR:
Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls. See CR for details.
-
Commit messages:
- Use JVMTI_FUNC_PTR instead of FUNC_PTR for most JVMTI calls so they are
logged.
Changes: https://git.openjdk.java.net/jdk/pull/971/files
Webrev:
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.
The copyright for threadControl.c will be updated by
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
>
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.
-
Commit messages:
- Remove canSuspendResumeThreadLists().
Changes:
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.
-
Commit messages:
- Make sure to deallocate jthread array allocated by GetAllThreads.
Changes:
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 points to
On Thu, 29 Oct 2020 12:44:58 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 Fri, 30 Oct 2020 16:38:40 GMT, Erik Österlund wrote:
> I think what you are saying is true. Note though that the return value of
> ForceEarlyReturn is installed with a handshake. The handshake polls of the
> interpreter are emitted in loop backedges and returns
Yes right, I wasn't really
On Fri, 30 Oct 2020 17:39:05 GMT, Ioi Lam wrote:
>> Claes Redestad has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 11 additional
>> commits
On Tue, 27 Oct 2020 14:00:34 GMT, Claes Redestad wrote:
> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM
> bootstrap to an overhead of ~67k instructions (linux-x64). By turning the
> initialization into a constexpr, we can precalculate the helper table at
> compile
On Fri, 30 Oct 2020 17:52:09 GMT, Igor Ignatyev 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 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
>
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
support and enhance them is significant. We therefore intend to disable
On Fri, 30 Oct 2020 15:24:17 GMT, Claes Redestad wrote:
>> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM
>> bootstrap to an overhead of ~67k instructions (linux-x64). By turning the
>> initialization into a constexpr, we can precalculate the helper table at
>>
On Fri, 30 Oct 2020 16:02:41 GMT, Erik Österlund wrote:
> > Hi Erik,
> > is it possible for GC to mistake a primitive value for a reference when
> > posting the exit event?
> > My understanding is: we are at a random bci of a method that is forced to
> > return early. The expression stack is
On Fri, 30 Oct 2020 14:20:42 GMT, Erik Österlund wrote:
>> Marked as reviewed by dlong (Reviewer).
>
>> I think you've discovered JDK-6449023. And you fix looks like the workaround
>> I tried:
>>
On Thu, 29 Oct 2020 20:04:11 GMT, Ioi Lam wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add explicit include of logging
>> - Add const, fix copyright
>
> Marked as reviewed by iklam (Reviewer).
@iklam: I
> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM
> bootstrap to an overhead of ~67k instructions (linux-x64). By turning the
> initialization into a constexpr, we can precalculate the helper table at
> compile time, which trades a runtime overhead for a small, 8kb,
On Fri, 30 Oct 2020 08:49:08 GMT, Dean Long 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 Fri, 30 Oct 2020 00:58:06 GMT, Coleen Phillimore wrote:
>> Thanks for having a look coleen. In fact, not doing the JRT_BLOCK for the
>> exception entry is intentional, because that entry goes through a different
>> JRT_ENTRY (not JRT_BLOCK_ENTRY), that already transitions. So if I do the
On Thu, 29 Oct 2020 22:34:30 GMT, Erik Österlund wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 1600:
>>
>>> 1598:
>>> 1599: if (exception_exit) {
>>> 1600: post_method_exit_inner(thread, mh, state, exception_exit,
>>> current_frame, result, value);
>>
>> I think for exception
On Thu, 29 Oct 2020 15:34:58 GMT, Vladimir Kozlov wrote:
> Good
Thanks for reviewing. Will integrate beginning of next week.
-
PR: https://git.openjdk.java.net/jdk/pull/775
On Thu, 29 Oct 2020 12:44:58 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 Fri, 30 Oct 2020 06:56:13 GMT, Richard Reingruber wrote:
>> Changes requested by coleenp (Reviewer).
>
> Hi Erik,
>
> is it possible for GC to mistake a primitive value for a reference when
> posting the exit event?
>
> My understanding is: we are at a random bci of a method that is forced
On Thu, 29 Oct 2020 21:23:21 GMT, Coleen Phillimore 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
27 matches
Mail list logo
