On Mon, 15 Jul 2024 00:50:30 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, 15 Jul 2024 00:50:30 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, 17 Jul 2024 06:39:14 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Remove try_read
>> - Add explicit to single parameter constructors
>> - Remove superfluous access specifier
On Mon, 15 Jul 2024 00:50:30 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, 15 Jul 2024 00:50:30 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 Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Wed, 17 Jul 2024 02:57:51 GMT, Chen Liang wrote:
>> What would be the terminology for a final field that's set by hotspot,
>> against the regular java constrcutor rules?
>
> I have chosen the wording "all final fields are used by the VM"
I don't know of any specific terminology - we typicall
On Wed, 17 Jul 2024 03:03:23 GMT, Chen Liang wrote:
>> Move fields common to Method and Field to executable, which simplifies
>> implementation. Removed useless transient modifiers as Method and Field were
>> never serializable.
>
> Chen Liang has updated the pull request incrementally with one
On Tue, 16 Jul 2024 22:41:40 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/reflect/Executable.java line 54:
>>
>>> 52: public abstract sealed class Executable extends AccessibleObject
>>> 53: implements Member, GenericDeclaration permits Constructor, Method {
>>> 54: //
> Move fields common to Method and Field to executable, which simplifies
> implementation. Removed useless transient modifiers as Method and Field were
> never serializable.
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
Redundant tr
On Mon, 15 Jul 2024 13:39:02 GMT, Aleksey Shipilev wrote:
>> Indeed, for some reason I thought the range of short is -256 to 255 instead
>> of -65536 to 65535
>
>> Indeed, for some reason I thought the range of short is -256 to 255 instead
>> of -65536 to 65535
>
> Yeah, I thought something li
On Mon, 15 Jul 2024 13:26:39 GMT, ExE Boss wrote:
>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes
>> `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>>
>> Please review
On Tue, 16 Jul 2024 22:00:49 GMT, David Holmes wrote:
>> Move fields common to Method and Field to executable, which simplifies
>> implementation. Removed useless transient modifiers as Method and Field were
>> never serializable.
>
> src/java.base/share/classes/java/lang/reflect/Executable.jav
On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote:
> Move fields common to Method and Field to executable, which simplifies
> implementation. Removed useless transient modifiers as Method and Field were
> never serializable.
Hotspot changes look good. Core-libs do too but I will leave that fo
On Tue, 16 Jul 2024 03:45:36 GMT, Chen Liang wrote:
> Move fields common to Method and Field to executable
s/Field/Constructor
I was a bit confused about executable fields for a moment. :)
-
PR Comment: https://git.openjdk.org/jdk/pull/20188#issuecomment-2231889229
On Tue, 16 Jul 2024 19:59:41 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388:
>>
>>> 1386: Name withIndex(int i) {
>>> 1387: if (i == this.index) return this;
>>> 1388: return new Name(i, type, function, arguments,
On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. On a strategic view, this index field should just become final
>> so that `Name` becomes eligible for value class migration once valhalla
>> comes. Thi
On Tue, 16 Jul 2024 19:39:16 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/java.base/share/classes/java/lang/invoke/LambdaForm.java
>>
>> Co-authored-by: ExE Boss <3889017+exe-b...@
On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. On a strategic view, this index field should just become final
>> so that `Name` becomes eligible for value class migration once valhalla
>> comes. Thi
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
> It was ex
On Tue, 16 Jul 2024 15:12:15 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
> This PR limits the number of cases in which we deoptimize frames when closing
> a shared Arena. The initial intent of this was to improve the performance of
> shared arena closure in cases where a lot of threads are accessing and
> closing shared arenas at the same time (see attached benchmark
In annotated types, local and inner class types should be annotated as
"top-level" types. For example, in the test here
public static Class getLocalsMember() {
class Local {
class Member {
@Annot(2635) Member(@Annot(2732) Local Local.this) {}
}
On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote:
>> Removing a redundant private method, which has the same implementation with
>> the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revisio
On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote:
>> Removing a redundant private method, which has the same implementation with
>> the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revisio
On Tue, 16 Jul 2024 16:54:09 GMT, Naoto Sato wrote:
>> Removing a redundant private method, which has the same implementation with
>> the public sibling and obsolete method description.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revisio
> Removing a redundant private method, which has the same implementation with
> the public sibling and obsolete method description.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed unnecessary `this`
-
Changes:
-
Removing a redundant private method, which has the same implementation with the
public sibling and obsolete method description.
-
Commit messages:
- initial commit
Changes: https://git.openjdk.org/jdk/pull/20199/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20199&range=0
On Tue, 16 Jul 2024 15:00:04 GMT, Doug Simon wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JVMCI support
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod.java
> line 62:
>
>>
> This PR limits the number of cases in which we deoptimize frames when closing
> a shared Arena. The initial intent of this was to improve the performance of
> shared arena closure in cases where a lot of threads are accessing and
> closing shared arenas at the same time (see attached benchmark
On Tue, 16 Jul 2024 14:46:13 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
On Tue, 16 Jul 2024 14:46:13 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
>> accessing and clo
> This PR limits the number of cases in which we deoptimize frames when closing
> a shared Arena. The initial intent of this was to improve the performance of
> shared arena closure in cases where a lot of threads are accessing and
> closing shared arenas at the same time (see attached benchmark
On Tue, 16 Jul 2024 13:35:50 GMT, Alan Bateman wrote:
>> Please review this patch that address the reflection member filtering flaws.
>>
>> 1. Remove a pointless bootstrap check to ensure no filter is accidentally
>> bypassed due to class-loading order.
>> 2. Clarify the scenarios for filtering
On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote:
> Please review this patch that address the reflection member filtering flaws.
>
> 1. Remove a pointless bootstrap check to ensure no filter is accidentally
> bypassed due to class-loading order.
> 2. Clarify the scenarios for filtering, and th
On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang wrote:
> 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways
> to steal this instance, bypassing the filtered getter.
JEP 471 has the roadmap for sun.misc.Unsafe, which is to wind it down over
time. Relaxing the filter to a
On Mon, 17 Jun 2024 15:24:27 GMT, Weijun Wang wrote:
>> Make sure `pd` is always the same object when `getProtectionDomain0` is null.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> explain why the test is related to the fix
On Tue, 16 Jul 2024 12:37:43 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with 10
>> additional commits since the last revision:
>>
>> - Remove try_read
>> - Add explicit to single parameter constructors
>> - Remove superfluous access specifier
On Mon, 15 Jul 2024 00:50:30 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 Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Tue, 16 Jul 2024 08:52:01 GMT, Julian Waters wrote:
>> src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32:
>>
>>> 30: #include /* for _MAx_PATH */
>>> 31:
>>> 32: typedef unsigned long long UNSIGNED_JLONG;
>>
>> This change has nothing to do with _sprintf. Not sure why it's
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling using
> gcc, and 2015 when using Visual Studio. Since it conforms to
On Mon, 15 Jul 2024 16:30:02 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> USe os::snprintf in HotSpot
>
> src/jdk.jdwp.agent/windows/native/libjdwp/util_md.h line 32:
>
>> 30: #include /
44 matches
Mail list logo