On Sun, 30 Jan 2022 00:39:20 GMT, Kim Barrett wrote:
> Please review this change to the HotSpot Style Guide change process.
>
> The current process involves gathering consensus among the HotSpot Group
> Members. That's fine for changes of substance. But it seems overly weighty
> for editorial
On Wed, 20 Oct 2021 08:11:34 GMT, Stefan Karlsson wrote:
> We encountered the following linking error when trying to build Generational
> ZGC on Windows:
>
> jvm.exp : error LNK2001: unresolved external symbol "const
> ZBasicOopIterateClosure
> >::`vftable'&quo
On Wed, 20 Oct 2021 12:23:28 GMT, Stefan Karlsson wrote:
>> We encountered the following linking error when trying to build Generational
>> ZGC on Windows:
>>
>> jvm.exp : error LNK2001: unresolved external symbol "const
>> ZBasicOopIterate
ymbols that get filtered out of
> the mapfile, which is then passed to the linker.
>
> I can get the code to link if I add a second exception for vftable symbols
> containing the string 'lambda':
> if ($$7 ~ /??_7.*@@6B@/ && $$7 !~ /type_info/ && $$7 !~ /l
We encountered the following linking error when trying to build Generational
ZGC on Windows:
jvm.exp : error LNK2001: unresolved external symbol "const
ZBasicOopIterateClosure
>::`vftable'"
(??_7?$ZBasicOopIterateClosure@V6B@)
I narrowed this down to a simple reproducer, which doesn't li
On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote:
> This patch enables ZGC on macOS/aarch64. It does three things:
> 1) Enables building of ZGC on this platform.
> 2) Adds `os::processor_id()`, which for now always returns 0.
> 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where th
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 Tue, 9 Mar 2021 17:55:12 GMT, Anton Kozlov wrote:
>> src/hotspot/share/runtime/thread.cpp line 2515:
>>
>>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread
>>> *thread) {
>>> 2514: // Enable WXWrite: called directly from interpreter native wrapper.
>>> 2515: MA
On Thu, 11 Mar 2021 14:07:43 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 Fri, 5 Feb 2021 16:07:09 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 19:38:16 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, 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 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 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
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
> table
On Thu, 10 Sep 2020 15:30:04 GMT, Monica Beckwith wrote:
>> ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will
>> enable and run microbenchmarks and scaling
>> tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015
>> (heap and multi-JVM) scaling tests
HotSpot changes look good.
StefanK
On 2020-03-20 14:15, Magnus Ihse Bursie wrote:
Can I get some hotspot reviewers on this as well? And is this trivial,
from the Hotspot PoV?
/Magnus
On 2020-03-20 14:05, Erik Joelsson wrote:
Looks good!
/Erik
On 2020-03-20 03:58, Magnus Ihse Bursie wrote:
Thanks, Erik!
StefanK
On 2019-12-19 09:22, Erik Joelsson wrote:
Looks good!
/Erik
On 2019-12-18 18:58, Stefan Karlsson wrote:
Adding build-dev.
StefanK
On 2019-12-18 18:52, Stefan Karlsson wrote:
Hi all,
Please review this patch to add a configure check to see if the SDK
supports the
Adding build-dev.
StefanK
On 2019-12-18 18:52, Stefan Karlsson wrote:
Hi all,
Please review this patch to add a configure check to see if the SDK
supports the APIs needed to build ZGC on Windows.
https://cr.openjdk.java.net/~stefank/8236110
https://bugs.openjdk.java.net/browse/JDK-8236110
Thanks, Erik.
StefanK
On 2019-11-22 15:24, Erik Joelsson wrote:
Build change looks good.
/Erik
On 2019-11-21 13:11, Stefan Karlsson wrote:
Hi,
I'm looking for a review for this tiny build change:
https://cr.openjdk.java.net/~stefank/8233299/webrev.01/make/autoconf/hotspot.m4.udiff
2019 11:18:20 +0100
From: Stefan Karlsson
To: hotspot-gc-dev
Hi all,
Please review this patch to add ZGC support on Windows.
https://cr.openjdk.java.net/~stefank/8233299/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8233299
As mentioned in the JEP (https://openjdk.java.net/jep
works.
I'll make sure to test with hs-tier2-graal.
Thanks for reviewing!
StefanK
Thanks,
Vladimir
On 5/2/18 7:37 AM, Stefan Karlsson wrote:
Hi all,
Please review these patches to allow for conditional compilation of
the GCs in HotSpot.
Full patch:
http://cr.openjdk.java.net/~stefank/
On 2018-05-03 15:19, Erik Helin wrote:
On 05/02/2018 04:37 PM, Stefan Karlsson wrote:
> Hi all,
Hi Stefan,
thanks for taking on this work, much appreciated!
On 05/02/2018 04:37 PM, Stefan Karlsson wrote:
> The first patch simply cleans up some INCLUDE_ALL_GCS usages in
platform-sp
On 2018-05-03 11:06, Magnus Ihse Bursie wrote:
On 2018-05-02 16:37, Stefan Karlsson wrote:
Hi all,
Please review these patches to allow for conditional compilation of
the GCs in HotSpot.
Full patch:
http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/
It's nice to see this cl
Looks good to me. Thanks for fixing.
StefanK
On 2018-05-03 00:13, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8202552/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8202552
Stefan K. found several places where #ifdef instead of #if is used for
INCLUDE_JVMCI.
I also found plac
Hi all,
Please review these patches to allow for conditional compilation of the
GCs in HotSpot.
Full patch:
http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/
(See below for a more fine-grained division into smaller patches)
Today Parallel, G1, and CMS, are all guarded by INCLUDE_AL
Hi Magnus,
Thanks a lot for implementing this! I tested this with
--with-log=info,report=none, and it's exactly what I want in my config
script ;)
Thanks,
StefanK
On 2018-04-10 22:54, Magnus Ihse Bursie wrote:
From the bug report:
"The compile errors you get from HotSpot are quite large, a
On 09/20/2013 02:46 PM, Stefan Karlsson wrote:
On 09/19/2013 05:13 PM, Lois Foltan wrote:
Please review the following fix:
Webrev:
http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/
The changes looks good.
I forgot this rather benign bug:
http://cr.openjdk.java.net/~hseigel
On 09/19/2013 05:13 PM, Lois Foltan wrote:
Please review the following fix:
Webrev:
http://cr.openjdk.java.net/~hseigel/bug_jdk7195622.0/
The changes looks good.
There are some changes that I don't fully agree with, but I will not
block the push because of them. I'm just going to mentio
Looping in build-dev and build-infra-dev.
StefanK
On 11/29/2011 09:47 AM, Stefan Karlsson wrote:
David,
Thanks for the review.
All,
Updated webrev: http://cr.openjdk.java.net/~stefank/7116081/webrev.2/
The rationale for this change is inlined:
On 11/29/2011 12:48 AM, David Holmes wrote
30 matches
Mail list logo
