On Fri, 12 Apr 2024 22:43:15 GMT, Vladimir Kozlov wrote:
> This is part of changes which try to reduce size of `nmethod` and `codeblob`
> data vs code in CodeCache.
> These changes reduced size of `nmethod` header from 288 to 240 bytes. From
> 304 to 256 in optimized VM:
>
> Statistics for
This is part of changes which try to reduce size of `nmethod` and `codeblob`
data vs code in CodeCache.
These changes reduced size of `nmethod` header from 288 to 240 bytes. From 304
to 256 in optimized VM:
Statistics for 1282 bytecoded nmethods for C2:
total in heap = 5560352 (100%)
header =
On Wed, 10 Apr 2024 00:28:01 GMT, Alex Menkov wrote:
> The test starts listening on dynamic port and calls stopListening with
> incorrect (cArgs1) and correct (cArgs2) argument maps.
> Incorrect map is created by finding "free" port (`(new
> ServerSocket(0)).getLocalPort()`)
> The test fails
On Fri, 12 Apr 2024 21:08:54 GMT, Alex Menkov wrote:
>> The test starts listening on dynamic port and calls stopListening with
>> incorrect (cArgs1) and correct (cArgs2) argument maps.
>> Incorrect map is created by finding "free" port (`(new
>> ServerSocket(0)).getLocalPort()`)
>> The test
On Fri, 12 Apr 2024 18:05:59 GMT, Chris Plummer wrote:
> You might want to consider adding the following diff. It will help in case
> this issue (or similar) reproduces again:
>
makes sense. added.
-
PR Comment: https://git.openjdk.org/jdk/pull/18705#issuecomment-2052542650
> The test starts listening on dynamic port and calls stopListening with
> incorrect (cArgs1) and correct (cArgs2) argument maps.
> Incorrect map is created by finding "free" port (`(new
> ServerSocket(0)).getLocalPort()`)
> The test fails if the same port is selected later when the listening
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
On Fri, 12 Apr 2024 06:07:31 GMT, Thomas Stuefe wrote:
> I am curious: what is the memory overhead for parallel mode, and (I am not
> familiar with the logic) how many threads are involved? Is the number of
> thread bounded?
>
> I ask because, especially for the OnOOM handling, we may already
On Wed, 10 Apr 2024 17:36:32 GMT, Alex Menkov wrote:
>> The test starts listening on dynamic port and calls stopListening with
>> incorrect (cArgs1) and correct (cArgs2) argument maps.
>> Incorrect map is created by finding "free" port (`(new
>> ServerSocket(0)).getLocalPort()`)
>> The test
On Fri, 12 Apr 2024 12:00:55 GMT, Serguei Spitsyn wrote:
>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes
>> were introduced in the JDK 22 to unify/simplify the JVM TI functions
>> supporting implementation of the virtual threads. This enhancement is to
>>
On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie wrote:
>> Jonathan Gibbons has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust call for `saveDanglingDocComments` for enum members
>
> The build changes look okay.
>
> Do you have
On Fri, 12 Apr 2024 15:26:03 GMT, Andrew Haley wrote:
>> Hello Sergey.
>> W^X mode was initially forced by Apple to prevent writing to executable
>> memory, as a security feature.
>> This change just eliminates this security feature at all, doesn't it ?
>> Basically: "want to write to
On Fri, 12 Apr 2024 12:00:55 GMT, Serguei Spitsyn wrote:
>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes
>> were introduced in the JDK 22 to unify/simplify the JVM TI functions
>> supporting implementation of the virtual threads. This enhancement is to
>>
On Fri, 12 Apr 2024 12:00:55 GMT, Serguei Spitsyn wrote:
>> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes
>> were introduced in the JDK 22 to unify/simplify the JVM TI functions
>> supporting implementation of the virtual threads. This enhancement is to
>>
On Fri, 12 Apr 2024 01:22:04 GMT, Serguei Spitsyn wrote:
>> Good question, thanks.
>> The `JvmtiVTMSTransitionDisabler` is supposed to be installed in the
>> caller's context if needed.
>> However, it is not easy to make sure it is always the case.
>> At least, I see a couple of contexts when
Hi Maxim, a great idea, the JDK serviceability team here at Oracle would
like to assist you in any way we can.
I think also we should (in the future) consider the format of the error
file and associated jcmd and perhaps render the content
in a format that is better suited to programmatic
On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote:
> An alternative for preemptively switching the W^X thread mode on macOS with
> an AArch64 CPU. This implementation triggers the switch in response to the
> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this
>
On Fri, 12 Apr 2024 14:50:46 GMT, Vladimir Kempik wrote:
> Hello Sergey. W^X mode was initially forced by Apple to prevent writing to
> executable memory, as a security feature. This change just eliminates this
> security feature at all, doesn't it ? Basically: "want to write to Executable
>
On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote:
> An alternative for preemptively switching the W^X thread mode on macOS with
> an AArch64 CPU. This implementation triggers the switch in response to the
> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this
>
An alternative for preemptively switching the W^X thread mode on macOS with an
AArch64 CPU. This implementation triggers the switch in response to the SIGBUS
signal if the *si_addr* belongs to the CodeCache area. With this approach, it
is now feasible to eliminate all WX guards and avoid
> The internal JVM TI JvmtiHandshake and JvmtiUnitedHandshakeClosure classes
> were introduced in the JDK 22 to unify/simplify the JVM TI functions
> supporting implementation of the virtual threads. This enhancement is to
> refactor the JVM TI internal functions
>
On Fri, 12 Apr 2024 02:17:34 GMT, Alex Menkov wrote:
> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix
> affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`,
> `-XX:+HeapDumpAfterFullGC`
22 matches
Mail list logo
