On Fri, 22 Nov 2024 16:48:04 GMT, Severin Gehwolf wrote:
> The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2
> when path adjustment is deemed needed. So I'm not clear why it's needed for
> cg v2
It looks like there's no way to see at this point, if we are in cgroup v1
> This PR merges JEP 404, a generational mode for the Shenandoah garbage
> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would
> like to target JDK24 with this PR.
William Kemper has updated the pull request with a new target base due to a
merge or a rebase. The pull r
On Fri, 22 Nov 2024 19:19:37 GMT, Kevin Walls wrote:
>> Remove redundant SecurityManager, AccessController references
>> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
>> Security Manager).
>
> Kevin Walls has updated the pull request incrementally with one additional
On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian Lövdahl wrote:
>> The fix is twofold.
>>
>> 1. Stop the main container after an iteration is done. The main container is
>> started with its runtime defined as 120 seconds, which means that each
>> iteration takes 120 seconds. In reality, one iteratio
On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote:
> Remove redundant SecurityManager Permission references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
> Security Manager).
Marked as reviewed by lmesnik (Reviewer).
-
PR Review: https://git.openj
On Fri, 15 Nov 2024 23:36:37 GMT, Leonid Mesnik wrote:
> Hi
> Could you please review the the fix that add locks information into SA jhsdb
> stack --mixed output.
>
> Here is the motivation for this rfe and explanation why I add it into SA now.
>
> The information about current owners of Hotsp
On Thu, 21 Nov 2024 19:43:40 GMT, Leonid Mesnik wrote:
>> Hi
>> Could you please review the the fix that add locks information into SA jhsdb
>> stack --mixed output.
>>
>> Here is the motivation for this rfe and explanation why I add it into SA now.
>>
>> The information about current owners o
On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote:
> Remove redundant SecurityManager, AccessController references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
> Security Manager).
As mentioned in https://github.com/openjdk/jdk/pull/22100 java.management.rmi
i
> Remove redundant SecurityManager, AccessController references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
> Security Manager).
Kevin Walls has updated the pull request incrementally with one additional
commit since the last revision:
Remove last import sun.r
On Thu, 21 Nov 2024 10:17:36 GMT, Kevin Walls wrote:
>> Remove redundant SecurityManager, AccessController references
>> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
>> Security Manager).
>>
>> src/jdk.management/share/classes/com/sun/management/internal/GarbageCol
On Sat, 16 Nov 2024 00:20:10 GMT, Vladimir Ivanov wrote:
> Optimize constructor to skip extra copy for registers. The tier1 tests are
> OK. The Specjvm2008 benchmark reports ~1% improvement.
@kimbarrett - Hi! This is the issue with copy constructors that I mentioned in
the parking lot a while
On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote:
> Remove redundant SecurityManager, AccessController references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
> Security Manager).
Thanks @dfuch - both comments relate to my note:
There are still some Privileged
On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote:
> These two tests both do stack dumps with one or more active threads. This can
> result in SA throwing an exception if the thread is in a bad state. However,
> SA will still generate stack traces for all other threads, and the tests
> sho
On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote:
> These two tests both do stack dumps with one or more active threads. This can
> result in SA throwing an exception if the thread is in a bad state. However,
> SA will still generate stack traces for all other threads, and the tests
> sho
On Fri, 22 Nov 2024 13:00:14 GMT, Sergey Chernyshev
wrote:
>>> Here, `limit` at line 64 is not stored as a possible lowest limit, so if
>>> the inner group has lower limit than the outer group, it won't be detected
>>> (cg v2 is affected too).
>>
>> Good spot! How about this to fix it?
>>
>>
On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote:
> Remove redundant SecurityManager, AccessController references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
> Security Manager).
src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionI
On Fri, 22 Nov 2024 10:57:31 GMT, Severin Gehwolf wrote:
> One thing to note is that the new test requires root privileges (AFAIK). We
> should skip the test if we are being run as root.
The test works just like other docker tests, root privileges are not required.
In systems that can't run do
On Fri, 22 Nov 2024 10:54:34 GMT, Severin Gehwolf wrote:
> Good spot! How about this to fix it?
>
> ```
> jlong limit = mem->read_memory_limit_in_bytes(phys_mem);
> jlong lowest_limit = limit < 0 ? phys_mem: limit;
> ```
Make sense to me.
> I'm worried about the added complexity. 1.) Is this
On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote:
> Remove redundant SecurityManager Permission references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the
> Security Manager).
Looks good!
-
Marked as reviewed by coleenp (Reviewer).
PR Review: http
Remove redundant SecurityManager Permission references
(following on from JDK-8338411: Implement JEP 486: Permanently Disable the
Security Manager).
-
Commit messages:
- 8334493: Remove SecurityManager Permissions infrastructure from
DiagnosticCommands
Changes: https://git.openjd
On Fri, 22 Nov 2024 09:54:39 GMT, Sergey Chernyshev
wrote:
> Here, `limit` at line 64 is not stored as a possible lowest limit, so if the
> inner group has lower limit than the outer group, it won't be detected (cg v2
> is affected too).
Good spot! How about this to fix it?
jlong limit = me
On Fri, 22 Nov 2024 09:57:44 GMT, Sergey Chernyshev
wrote:
>> Cgroup V1 subsustem fails to initialize mounted controllers properly in
>> certain cases, that may lead to controllers left undetected/inactive. We
>> observed the behavior in CloudFoundry deployments, it affects also host
>> syste
On Tue, 12 Nov 2024 23:29:47 GMT, Sergey Chernyshev
wrote:
>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java
>> line 46:
>>
>>> 44: }
>>> 45:
>>> 46: public void setPath(String cgroupPath) {
>>
>> This should behave the same as Hotspot and
> Cgroup V1 subsustem fails to initialize mounted controllers properly in
> certain cases, that may lead to controllers left undetected/inactive. We
> observed the behavior in CloudFoundry deployments, it affects also host
> systems.
>
> The relevant /proc/self/mountinfo line is
>
>
> 2207 21
24 matches
Mail list logo
