On Mon, 16 Nov 2020 23:10:21 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
On Wed, 18 Nov 2020 19:31:44 GMT, Serguei Spitsyn wrote:
> There is a double-check for _needs_cleaning, so the one at line 136 can be
> removed:
I want to leave _needs_cleaning at 136 because even though the boolean is
checked twice, it doesn't hurt performance and it has a nice symmetry in th
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request with a new tar
On Thu, 19 Nov 2020 10:10:06 GMT, Serguei Spitsyn wrote:
>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp:
>>>
>>> The change below is not needed as the call to
>>> nsk_jvmti_aod_disableEventAndFinish() does exactly the same:
>>>
>>> ```
>>> -nsk_jv
On Thu, 19 Nov 2020 12:36:46 GMT, Coleen Phillimore wrote:
>> @kimbarrett
>> Okay, thank you for explanation.
>> I agree, it'd make sense to improve the comment a little bit.
>> Thanks,
>> Serguei
>
> So should nsk_jvmti_aod_disableEventAndFinish pas
On Thu, 19 Nov 2020 12:51:11 GMT, Coleen Phillimore wrote:
>> So should nsk_jvmti_aod_disableEventAndFinish pass the address of success
>> instead? Why didn't it fail before this change?
>> Ok, with this change, it's not posted yet and the success variable for
>
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with o
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with one
On Thu, 19 Nov 2020 12:54:23 GMT, Coleen Phillimore wrote:
>> /* Flush any pending ObjectFree events, which will set global success
>> variable to 1
>>for any pending ObjectFree events. */
>> How about this? The word 'global' helps me.
>
> Wit
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
On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Sun, 24 Jan 2021 15:32:59 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the
On Mon, 25 Jan 2021 14:40:09 GMT, Coleen Phillimore wrote:
>> Anton Kozlov has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Address feedback for signature generators
>> - Enable -Wformat-nonliteral back
On Mon, 25 Jan 2021 15:01:25 GMT, Anton Kozlov wrote:
>> src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 87:
>>
>>> 85: JavaThread* jt = JavaThread::thread_from_jni_environment(jni_env);
>>> 86: DEBUG_ONLY(JfrJavaSupport::check_java_thread_in_native(jt));;
>>> 87: Thread::WXWr
On Tue, 26 Jan 2021 11:31:18 GMT, Anton Kozlov wrote:
>> This could be a follow-up RFE.
>
> I assume a WXVerifier class that tracks W^X mode in debug mode and does
> nothing in release mode. I've considered to do this, it's relates to small
> inefficiencies, while this patch brings zero overhea
On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov wrote:
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Ahead-of-Time Compiler from JDK:
>
> - `jdk.aot` module — the `jaotc` tool
> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
> -
On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Ahead-of-Time Compiler from JDK:
>>
>> - `jdk.aot` module — the `jaotc` tool
>> - `src/hotspot/share/aot` — loads AoT compiled code into VM for execution
On Thu, 8 Apr 2021 20:28:27 GMT, Igor Ignatyev wrote:
>> Vladimir Kozlov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove exports from Graal module to jdk.aot
>
> Test changes look good to me.
There's a comment above
void VM_Redef
On Fri, 30 Apr 2021 09:19:57 GMT, David Holmes wrote:
> The existing logic does:
>
> build system -> java.lang.VersionProps -> VM thread.cpp fixed-size static
> buffers -> JDK_Version class
>
> we can simply do:
>
> build system -> JDK_Version class
>
> reduces footprint, loc and startup tim
On 10/26/17 2:47 PM, mandy chung wrote:
On 10/26/17 2:57 AM, Magnus Ihse Bursie wrote:
A third option is to remove the support for link-time-opt entirely,
if it's not really used.
* src/java.base/unix/native/include/jvm_md.h and
src/java.base/windows/native/include/jvm_md.h:
These files
Hi Magnus,
Thank you for reviewing this. I have a new version that takes out the
hack in globalDefinitions.hpp and adds casts to
src/hotspot/share/opto/type.cpp instead.
Also some fixes from Martin at SAP.
open webrev at http://cr.openjdk.java.net/~coleenp/8189610.02/webrev
see below.
O
Thank you for reviewing this, Mandy!
Coleen
On 10/26/17 5:27 PM, mandy chung wrote:
On 10/26/17 1:34 PM, coleen.phillim...@oracle.com wrote:
On 10/26/17 2:47 PM, mandy chung wrote:
On 10/26/17 2:57 AM, Magnus Ihse Bursie wrote:
A third option is to remove the support for link-time-opt en
On 10/27/17 3:23 AM, David Holmes wrote:
Hi Coleen,
Thanks for tackling this.
Summary: removed hotspot version of jvm*h and jni*h files
Can you update the bug synopsis to show it covers both sets of files
please.
I hate to start with this (and it took me quite a while to realize it)
bu
On 10/27/17 7:44 AM, Magnus Ihse Bursie wrote:
On 2017-10-26 22:44, coleen.phillim...@oracle.com wrote:
Hi Magnus,
Thank you for reviewing this. I have a new version that takes out
the hack in globalDefinitions.hpp and adds casts to
src/hotspot/share/opto/type.cpp instead.
Also some f
On 10/27/17 9:37 AM, David Holmes wrote:
On 27/10/2017 10:13 PM, coleen.phillim...@oracle.com wrote:
On 10/27/17 3:23 AM, David Holmes wrote:
Hi Coleen,
Thanks for tackling this.
Summary: removed hotspot version of jvm*h and jni*h files
Can you update the bug synopsis to show it covers
On 10/27/17 9:37 AM, David Holmes wrote:
src/hotspot/share/c1/c1_LinearScan.cpp
ConstantIntValue((jint)0);
why is this cast needed? what causes the ambiguity? (If this was a
template I'd understand ;-) ). Also didn't you change that
constructor to take an int anyway - not that I think it s
On 10/27/17 1:47 PM, mandy chung wrote:
On 10/27/17 7:08 AM, coleen.phillim...@oracle.com wrote:
On 10/27/17 9:37 AM, David Holmes wrote:
The one file that is needed is a hotspot file - jvm.h defines the
interface that hotspot exports via jvm.cpp.
If you leave jvm.h in hotspot/prims t
On 10/28/17 3:46 AM, David Holmes wrote:
On 28/10/2017 3:47 AM, mandy chung wrote:
On 10/27/17 7:08 AM, coleen.phillim...@oracle.com wrote:
On 10/27/17 9:37 AM, David Holmes wrote:
The one file that is needed is a hotspot file - jvm.h defines the
interface that hotspot exports via jvm.cp
On 10/28/17 3:50 AM, David Holmes wrote:
Hi Coleen,
I've commented on the file location in response to Mandy's email.
The only issue I'm still concerned about is the JVM_MAXPATHLEN issue.
I think it is a bug to define a JVM_MAXPATHLEN that is bigger than the
platform MAXPATHLEN. I also woul
On 10/30/17 8:17 AM, David Holmes wrote:
On 30/10/2017 10:13 PM, coleen.phillim...@oracle.com wrote:
On 10/28/17 3:50 AM, David Holmes wrote:
Hi Coleen,
I've commented on the file location in response to Mandy's email.
The only issue I'm still concerned about is the JVM_MAXPATHLEN
issue. I
On 11/1/17 12:51 PM, Daniel D. Daugherty wrote:
Just one comment about the location of "jvm.h".
On 10/30/17 8:07 AM, coleen.phillim...@oracle.com wrote:
On 10/28/17 3:46 AM, David Holmes wrote:
On 28/10/2017 3:47 AM, mandy chung wrote:
On 10/27/17 7:08 AM, coleen.phillim...@oracle.com wr
On 11/1/17 2:41 PM, mandy chung wrote:
On 11/1/17 11:09 AM, coleen.phillim...@oracle.com wrote:
So, we have a variety of opinions. Please open another ticket to
discuss this.
https://bugs.openjdk.java.net/browse/JDK-8190484
Mandy
Thanks Mandy! There were arguments for and against th
Hi, I looked at the runtime changes, which are very few, since you've
upstreamed most of the runtime dependent changes already.
They look good to me.
Thanks,
Coleen
(trying again with all the lists).
On 11/30/18 4:00 PM, Roman Kennke wrote:
Hi all,
here comes round 4 of Shenandoah upstreaming
http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/05/shenandoah-gc/src/hotspot/share/gc/shenandoah/vm_operations_shenandoah.cpp.html
Can you rename these to shenandoahVMOperations.hpp/cpp to match the
newly agreed upon naming convention for this?
See 8214791: Consistently name gc files
Including build-dev.
On 6/23/20 12:17 AM, David Holmes wrote:
Hi Coleen,
Cleanup is looking good but a few comments:
- if the bytecodeInterpreter is also zero-only can we rename its files
too? (I really find it hard to figure out which files are really
needed/used for a given build.)
You
Thanks, Magnus.
Coleen
On 6/23/20 7:04 PM, Magnus Ihse Bursie wrote:
On 2020-06-23 22:35, coleen.phillim...@oracle.com wrote:
Including build-dev.
On 6/23/20 12:17 AM, David Holmes wrote:
Hi Coleen,
Cleanup is looking good but a few comments:
- if the bytecodeInterpreter is also zero-o
Thank you, David!
Coleen
On 6/24/20 12:13 AM, David Holmes wrote:
I thoroughly applaud the introduction of interpreter/zero directory!
Thank you. :)
Updates look good to me.
Thanks,
David
On 24/06/2020 6:35 am, coleen.phillim...@oracle.com wrote:
Including build-dev.
On 6/23/20 12:17 AM,
Hi Chris,
Thank you for replying!
I was going to wait for Adrian but it's a big enough change that it
would bit rot if I waited too long, and I didn't know how long it would
be. We can fix anything that is disagreeable with a future patch, I
think. So I pushed it today.
Thanks,
Coleen
On
Hi Adrian, Thank you for replying and having a look. I hope you like
the patch, but if not, we'll fix it.
Sorry for rushing the push. I was sitting on too many changed files.
Thanks,
Coleen
On 6/24/20 4:03 PM, John Paul Adrian Glaubitz wrote:
Hi Coleen!
On 6/24/20 8:42 PM, coleen.philli
On Thu, 8 Oct 2020 13:59:20 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the
>> API in 3 main ways:
>> * firs
On Thu, 15 Oct 2020 17:08:28 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the first incubation round
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory
>> access support (see JEP 393
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
W
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
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 be
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
>> tabl
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
>> table
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with one
a
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.
>
> test/hotspot/jtreg/vmTestbase/nsk/j
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
> interact
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
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/jvmtiTagMa
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
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with one
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request with a new target base du
On Tue, 3 Nov 2020 17:40:38 GMT, Coleen Phillimore wrote:
>> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c
>>
>> This removes the reported warning.
>>
>> Note that the _LP64 macro was not being propagated to the benchmark native
>> l
On Mon, 2 Nov 2020 18:36:32 GMT, Jorn Vernee wrote:
> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c
>
> This removes the reported warning.
>
> Note that the _LP64 macro was not being propagated to the benchmark native
> libraries on Windows. The comment says that this is due to p
On Tue, 3 Nov 2020 20:37:07 GMT, Jorn Vernee wrote:
>> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c
>>
>> This removes the reported warning.
>>
>> Note that the _LP64 macro was not being propagated to the benchmark native
>> libraries on Windows. The comment says that this is du
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
>>
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
>>
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
>>
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/w
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
>>
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
>
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/w
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 Wea
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
>
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with one
On Wed, 4 Nov 2020 05:37:00 GMT, Serguei Spitsyn wrote:
>> Hi Coleen,
>>
>> Wow, there are a lot of simplifications and code removal with this fix!
>> It looks great in general, just some nits below.
>> I also wanted to suggest renaming the 'set_needs_processing' to
>> 'set_needs_rehashing'. :)
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementall
On Wed, 4 Nov 2020 10:05:29 GMT, Kim Barrett wrote:
>> The comment is trying to describe the situation like:
>> 1. mark-end pause (WeakHandle.peek() returns NULL because object A is
>> unmarked)
>> 2. safepoint for heap walk
>>2a. Need to post ObjectFree event for object A before the heap wa
On Wed, 4 Nov 2020 08:56:54 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comments from Kim and Albert.
>
> src/hotspot/share/prims/jvmtiTagMapTabl
On Wed, 4 Nov 2020 07:42:36 GMT, Kim Barrett wrote:
>>> Ok, so I'm not sure what to do with this:
>>>
>>> enum Phase {
>>> // Serial phase.
>>> JVMTI_ONLY(jvmti)
>>> // Additional implicit phase values follow for oopstorages.
>>> `};`
>>>
>>> I've removed the only thing in this enum.
>>
>> Enu
On Wed, 4 Nov 2020 09:27:39 GMT, Kim Barrett wrote:
>> I didn't say it "doesn't work for shenandoah", I said it wouldn't have
>> worked with the old shenandoah barriers without additional work, like adding
>> calls to resolve. I understand the design intent of notifying the table
>> managemen
On Wed, 4 Nov 2020 22:09:21 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add back WeakProcessorPhases::Phase enum.
>> - Serguei 1.
>
> Thank you
On Wed, 4 Nov 2020 13:19:21 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMapTable.hpp line 36:
>>
>>> 34: class JvmtiTagMapEntryClosure;
>>> 35:
>>> 36: class JvmtiTagMapEntry : public HashtableEntry>> mtServiceability> {
&g
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request with a new target bas
On Thu, 5 Nov 2020 12:42:40 GMT, Coleen Phillimore wrote:
>> Thank you for the update, Coleen!
>> I leave it for you to decide to refactor the gc_notification or not.
>> Thanks,
>> Serguei
>
> Thanks @sspitsyn . I'm going to leave the gc_notification code be
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with one
a
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with t
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request with a new target base
On Mon, 9 Nov 2020 20:39:40 GMT, Coleen Phillimore wrote:
>> Thanks @sspitsyn . I'm going to leave the gc_notification code because
>> structurally the two sides of the if statement are different and it's not a
>> long function. Thank you for reviewing the change.
On Thu, 5 Nov 2020 14:36:44 GMT, Erik Österlund wrote:
>> Ok, so there were many test failures with other approaches. Having GC
>> trigger the posting was the most reliable way to post the events when the
>> tests (and presumably the jvmti customers) expected the events to be posted.
>> We c
the
> weakProcessor, ZGC and Shenandoah. The GCs have been stress tested with
> jvmti code.
>
> It has also been tested with tier1-6.
>
> Thank you to Stefan, Erik and Kim for their help with this change.
Coleen Phillimore has updated the pull request incrementally with one
Hi,
Does anyone know how to build this on a linux x64 system with the 32 bit
libraries installed?
Ie. the magic flags to 'configure' etc? I fail this in JPRT and want to
locally figure out why.
thanks,
Coleen
available, or if your forest has been updated to use
the new devkit version, gcc4.9.2-OEL6.4.
/Erik
On 2015-10-21 17:43, Coleen Phillimore wrote:
Hi,
Does anyone know how to build this on a linux x64 system with the 32
bit libraries installed?
Ie. the magic flags to 'configure' etc? I
On 2/5/16 7:12 AM, Magnus Ihse Bursie wrote:
On 2016-02-05 10:41, Erik Joelsson wrote:
Magnus pointed out that I mistakenly replaced fno-strict-aliasing
with -Wno-strict-aliasing. Reverted that change.
http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.02/
The new webrev looks good to me.
Added back build-dev.
On 6/19/2013 3:58 PM, Coleen Phillimore wrote:
Dan,
This looks good!
Coleen
On 6/18/2013 4:50 PM, Daniel D. Daugherty wrote:
Greetings,
I have picked up David Holmes' work on the following bug:
8014326 [OSX] All libjvm symbols are exported
http://bugs.su
Lois,
This looks really good! Thank you for enabling this on all the
platforms so we can use this checking everywhere.
Thanks,
Coleen
On 09/19/2013 11:10 AM, Lois Foltan wrote:
Please review the following fix:
Webrev:
http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/
Bug: JDK8 b
89 matches
Mail list logo
