On Mon, 2 Nov 2020 16:22:57 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 345:
>>
>>> 343:
>>> 344: // Check if we have to process for concurrent GCs.
>>> 345: check_hashmap(false);
>>
>> Maybe add a comment stating the parameter name, as was done in other
On Mon, 2 Nov 2020 12:58:49 GMT, Coleen Phillimore wrote:
> GC callers shouldn't really have to know what processing we're doing here.
I completely disagree with this. It's extremely important that the GC and
Runtime code agrees on what this code does and where the GC *must* call it.
Knowing
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
>> ta
On Tue, 3 Nov 2020 10:22:09 GMT, Erik Österlund wrote:
>> Ok, will I run afoul of the ZGC people putting the parameter name after the
>> parameter and the rest of the code, it is before?
>
> ZGC people passionately place the comment after the argument value.
I see that but in the non-zgc code i
On Tue, 3 Nov 2020 10:36:21 GMT, Stefan Karlsson wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comments from StefanK.
>
> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 185:
>
>> 183: // Seri
On Tue, 3 Nov 2020 10:33:16 GMT, Stefan Karlsson wrote:
>> Since I went back and forth about what this function did (it posted events
>> at one time), I thought the generic _processing name would be better. GC
>> callers shouldn't really have to know what processing we're doing here.
>> Hope
On Tue, 20 Oct 2020 21:53:10 GMT, Richard Reingruber wrote:
> The following test cases try to provoke VMOutOfMemoryException during object
> reallocation because of JVMTI PopFrame / ForceEarlyReturn:
>
> EAPopFrameNotInlinedReallocFailure
> EAPopInlinedMethodWithScalarReplacedObjectsReallocFail
> 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 poin
On Tue, 3 Nov 2020 11:22:50 GMT, Aleksey Shipilev wrote:
> Zero interpreter has two modes: with JVMTI built-in, and without. But we
> cannot test it properly, because the build fails without JVMTI in shared
> code. Mostly due to JDK-8147388.
>
> Additional testing:
> - [x] Linux x86_64 Zero f
On Tue, 3 Nov 2020 12:58:22 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
>> ta
> 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. How
On Mon, 2 Nov 2020 21:00:23 GMT, Serguei Spitsyn wrote:
> Erik,
>
> Thank you for the update! It looks more elegant.
>
> One concern is that after the move of this fragment to the
> post_method_exit_inner:
>
> ```
> 1614 if (state == NULL || !state->is_interp_only_mode()) {
> 1615 // fo
On Tue, 3 Nov 2020 13:04:08 GMT, Coleen Phillimore wrote:
>> Zero interpreter has two modes: with JVMTI built-in, and without. But we
>> cannot test it properly, because the build fails without JVMTI in shared
>> code. Mostly due to JDK-8147388.
>>
>> Additional testing:
>> - [x] Linux x86_64
On Tue, 3 Nov 2020 13:58:36 GMT, Aleksey Shipilev wrote:
>> Looks good.
>
> Thanks @coleenp! Would you say it is trivial?
Yes, trivial!
-
PR: https://git.openjdk.java.net/jdk/pull/1036
> 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 poin
On Tue, 3 Nov 2020 14:43:52 GMT, Coleen Phillimore wrote:
>> Thanks @coleenp! Would you say it is trivial?
>
> Yes, trivial!
Thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/1036
On Tue, 3 Nov 2020 11:22:50 GMT, Aleksey Shipilev wrote:
> Zero interpreter has two modes: with JVMTI built-in, and without. But we
> cannot test it properly, because the build fails without JVMTI in shared
> code. Mostly due to JDK-8147388.
>
> Additional testing:
> - [x] Linux x86_64 Zero f
On Tue, 3 Nov 2020 13:52:24 GMT, Erik Österlund wrote:
>> Erik,
>>
>> Thank you for the update! It looks more elegant.
>>
>> One concern is that after the move of this fragment to the
>> post_method_exit_inner:
>> 1614 if (state == NULL || !state->is_interp_only_mode()) {
>> 1615 // for
On Tue, 3 Nov 2020 14:53:12 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
>> ta
On Tue, 3 Nov 2020 12:58:22 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
>> ta
On Tue, 3 Nov 2020 14:47:35 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
>>
On Tue, 3 Nov 2020 14:53:12 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
>> ta
On 11/2/20 8:22 AM, Coleen Phillimore wrote:
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 eve
On Mon, 2 Nov 2020 13:19:08 GMT, Coleen Phillimore wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-ta
On Tue, 3 Nov 2020 14:50:36 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
>>
On Tue, 3 Nov 2020 16:12:21 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
>>
On Tue, 3 Nov 2020 16:17:58 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
>>
On Mon, 2 Nov 2020 13:19:08 GMT, Coleen Phillimore wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-ta
On Tue, 3 Nov 2020 13:43:32 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More review comments from Stefan and ErikO
>
> src/hotspot/share/gc/shared/weakProcessorPhases.hpp line 41:
>
>> 39
On Tue, 3 Nov 2020 13:45:57 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More review comments from Stefan and ErikO
>
> src/hotspot/share/gc/shared/weakProcessorPhases.hpp line 50:
>
>> 48
On Tue, 3 Nov 2020 21:41:55 GMT, Coleen Phillimore wrote:
> > @coleenp - please make sure you hear from someone on the Serviceability team
> > for this PR...
>
> I've asked @sspitsyn to review this.
Yes, I'm reviewing this. Still need another pass.
-
PR: https://git.openjdk.java.n
- Fixed synchronization logic in resexhausted001;
- On Windows JVM cannot produce OOM caused by thread creation failure. Massive
thread creation causes big system (not VM) memory consumption, as a result test
host dramatically slows down up to hang. Specifying small heap size we can get
RESOURCE
On Tue, 3 Nov 2020 21:47:24 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/gc/shared/weakProcessorPhases.hpp line 50:
>>
>>> 48: };
>>> 49:
>>> 50: typedef uint WeakProcessorPhase;
>>
>> This was originally written with the idea that WeakProcessorPhases::Phase
>> (and WeakProcessorPhase)
On Tue, 3 Nov 2020 21:12:49 GMT, Albert Mingkun Yang wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-
On Tue, 3 Nov 2020 23:16:50 GMT, Alex Menkov wrote:
> - Fixed synchronization logic in resexhausted001;
> - On Windows JVM cannot produce OOM caused by thread creation failure.
> Massive thread creation causes big system (not VM) memory consumption, as a
> result test host dramatically slows do
> 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 poin
Simple change to add a `name` field to `ThreadNode` to aide when debugging the
debug agent. It's off by default. You need to add a `#define DEBUG_THREADNAME`
to enable it.
-
Commit messages:
- Add support for tracking a thread's name.
Changes: https://git.openjdk.java.net/jdk/pull
On Wed, 4 Nov 2020 00:08:10 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
>> ta
On Tue, 3 Nov 2020 23:30:38 GMT, Chris Plummer wrote:
> Simple change to add a `name` field to `ThreadNode` to aide when debugging
> the debug agent. It's off by default. You need to add a `#define
> DEBUG_THREADNAME` to enable it.
Chris,
It looks good.
Thanks,
Serguei
-
Marked a
On Wed, 4 Nov 2020 02:15:52 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comments from Kim and Albert.
>
> Hi Coleen,
>
> Wow, there are a lot of simplifications and code r
40 matches
Mail list logo
