On Fri, 7 Feb 2025 12:34:40 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Wed, 8 Jan 2025 16:43:51 GMT, Coleen Phillimore wrote:
>> This is the same change that I pushed as commit
>> 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111
>> for the graal changes.
>>
>> A tier1 sanity test complete.
>
> Coleen Phillimore has refreshed the co
On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore wrote:
>> Please review this change that makes AccessFlags and modifier_flags u2 types
>> and removes the last remnants of Hotspot adding internal access flags. This
>> change moves AccessFlags and modifier_flags in Klass to alignment gaps
>>
On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote:
>> Could you please cherry pick
>> https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2
>> for the JVMCI support?
>
> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-)
@rkennke It is in the merg
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes hav
On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
On Thu, 19 Sep 2024 14:22:51 GMT, Stefan Karlsson wrote:
>> We haven't decided whether or not we will git rid of
>> ```Klass::_prototype_header``` before intergrating this PR, or not. @stefank
>> could point you to a WIP branch, if that's helpful.
>
> This is my current work-in-progress code:
>
On Thu, 19 Sep 2024 05:03:42 GMT, Stefan Karlsson wrote:
>> Yes, I saw that patch. I'm not sure I like the idea of cpu dependent code
>> also doing the encoding. There were some C2 changes related to it that I
>> didn't understand if that scheme required them. I don't see the down side
>> t
On Tue, 17 Sep 2024 12:52:03 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
On Fri, 30 Aug 2024 20:23:54 GMT, Coleen Phillimore wrote:
>> I don't think the JVMCI knows about the type KlassFlags - I used the same
>> code that I used for InstanceKlass::_misc_flags._flags (see above this).
>
> I made the change to refactor the getMiscFlags function, but if you want to
>
On Fri, 30 Aug 2024 21:51:49 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 18:50:42 GMT, Coleen Phillimore wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to t
On Thu, 29 Aug 2024 16:22:22 GMT, Gilles Duboscq wrote:
>> Move JVM implementation access flags that are not specified by the classfile
>> format into Klass so we can shrink AccessFlags to u2 in a future change.
>>
>> Tested with tier1-7.
>>
>> NOTE: there are arm, ppc and s390 changes to this
On Tue, 20 Aug 2024 10:07:26 GMT, Roman Kennke wrote:
> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>
> Main changes:
> - Introduction of the (experimental) flag UseCompactObjectHeaders. All
> changes in this PR are protected by this flag. The purpose of the fl
On Thu, 15 Aug 2024 06:12:22 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Wed, 10 Jul 2024 20:10:07 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Mon, 8 Jul 2024 12:13:07 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> lo
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote:
> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
> not enforce checking line number derived from uncommon trap debug info.
> However, Graal does not set this property explicitly.
This pull r
On Thu, 8 Jun 2023 17:14:39 GMT, Yudi Zheng wrote:
> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
> not enforce checking line number derived from uncommon trap debug info.
> However, Graal does not set this property explicitly.
Th
On Thu, 8 Jun 2023 17:19:46 GMT, Doug Simon wrote:
>> HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
>> not enforce checking line number derived from uncommon trap debug info.
>> However, Graal does not set this property explicitly.
>
> test/hotspot/jtreg/serviceab
HeapMonitor checks if System.getProperty("jvmci.Compiler") is graal and will
not enforce checking line number derived from uncommon trap debug info.
However, Graal does not set this property explicitly.
-
Commit messages:
- Avoid using jvmci.Compiler property to determine if Graal
22 matches
Mail list logo
