On Mon, 8 Jul 2024 08:18:42 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 looser
>
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
com/sun/jdi/ThreadMemoryLeakTest.java purposely runs with a small heap so it is
easier to detect a memory leak with an OOME. Running without compressed oops
uses more memory leading to an OOME even though there is no leak. We should
require that this test be run only with compressed oops.
Test
> This PR adds ranked monitor support to the debug agent. The debug agent has a
> large number of monitors, and it's really hard to know which order to grab
> them in, and for that matter which monitors might already be held at any
> given moment. By imposing a rank on each monitor, we can check
On Thu, 15 Aug 2024 22:06:14 GMT, Dhamoder Nalla wrote:
>> src/hotspot/os/windows/os_windows.cpp line 1522:
>>
>>> 1520: const char* os::get_temp_directory() {
>>> 1521: static char path_buf[MAX_PATH];
>>> 1522: if (_GetTempPath2A != nullptr) {
>>
>> Where does _GetTempPath2A get initialize
On Thu, 15 Aug 2024 18:32:29 GMT, Chris Plummer wrote:
>> Dhamoder Nalla has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix missing code
>
> src/hotspot/os/windows/os_windows.cpp line 1522:
>
>> 1520: const char* os::get_temp_directory
There are issues with the test attaching to the debuggee too soon, and the
debug agent isn't ready. yet. This test is based on ProcessAttachTest, which
does not have this issue. I eventually realized the reason why is because
ProcessAttachTest has this little snippet of code, which I had removed
On Tue, 13 Aug 2024 02:20:41 GMT, David Holmes wrote:
> This work has been split out from JDK-8328877: [JNI] The JNI Specification
> needs to address the limitations of integer UTF-8 String lengths
>
> The modified UTF-8 format used by the VM can require up to six bytes to
> represent one unic
> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
> across the OpenJDK repository to retrieve the temporary directory path, as
> GetTempPath2 provides enhanced security. While GetTempPath may still function
> without errors, using GetTempPath2 reduces the risk of potenti
On Thu, 15 Aug 2024 16:23:18 GMT, Dhamoder Nalla wrote:
> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code
> across the OpenJDK repository to retrieve the temporary directory path, as
> GetTempPath2 provides enhanced security. While GetTempPath may still function
> with
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
Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across
the OpenJDK repository to retrieve the temporary directory path, as
GetTempPath2 provides enhanced security. While GetTempPath may still function
without errors, using GetTempPath2 reduces the risk of potential explo
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemType` is much more suitable name.
>
> There is a bunch o
On Thu, 15 Aug 2024 13:45:11 GMT, Yudi Zheng wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove newline
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 677:
>
>> 675:
>> 676: // Check for
On Wed, 14 Aug 2024 19:34:26 GMT, Leonid Mesnik wrote:
> The summary of the problem. Test is intermittently failing because can't get
> expected field watch event.
> The test is failing to get event in the 'setfmodw001b' thread with Xcomp only.
> I verified that frame with the method 'run' of se
On Wed, 14 Aug 2024 19:34:26 GMT, Leonid Mesnik wrote:
> The summary of the problem. Test is intermittently failing because can't get
> expected field watch event.
> The test is failing to get event in the 'setfmodw001b' thread with Xcomp only.
> I verified that frame with the method 'run' of se
The summary of the problem. Test is intermittently failing because can't get
expected field watch event.
The test is failing to get event in the 'setfmodw001b' thread with Xcomp only.
I verified that frame with the method 'run' of setfmodw001b is compiled when
line
118: setfmodw001.setWatch(4);
i
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 Fri, 12 Jul 2024 10:12:32 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> Is there a plan to get rid of the UseObjectMonitorTable flag in a future
> release? I
On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski wrote:
> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>
> `MEMFLAGS` implies that we can use more than one at the same time, but those
> are exclusive values, so `MemType` is much more suitable name.
>
> There is a bunch o
On Thu, 15 Aug 2024 07:46:34 GMT, Stefan Karlsson wrote:
> > > Whatever we choose we also need to consider the mt prefix of things like
> > > mtGC, mtClass, etc.
> >
> >
> > And what does that stand for: memory type? memory tracker? Arguably they
> > should have been nmtGC etc.
>
> The memfl
On Thu, 15 Aug 2024 06:31:14 GMT, David Holmes wrote:
> > Whatever we choose we also need to consider the mt prefix of things like
> > mtGC, mtClass, etc.
>
> And what does that stand for: memory type? memory tracker? Arguably they
> should have been nmtGC etc.
The memflags.hpp file says that
On Thu, 15 Aug 2024 06:07:49 GMT, Stefan Karlsson wrote:
> > I agree with @tstuefe here. MemFlag and MemType sound far too general when
> > this is NMT specific.
>
> Yes, it is not very specific, but it also not hard to learn and then know
> what this type is all about.
>
> > My preference to
23 matches
Mail list logo
