Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v7]
On Mon, 14 Mar 2022 08:03:39 GMT, Thomas Stuefe wrote:
> Thanks a lot, Florian! I got it to work under Linux x64.
Great!
> My error was that I had declared the label in C++ as `extern void*
> SafeFetch_continuation`. Declaring it as `extern char
> _SafeFetch32_continuation[] __attribute__ ((visibility ("hidden")));` as you
> suggested does the trick. I'm not sure I understand the difference.
Your approach might have worked as well, but you would have to use
`_continuation` on the C++ side. Arrays work directly because of
pointer decay. The actual type does not matter because you just want to create
a code address from that, so there's no corresponding object (in the C++
standard sense) at the address anyway.
Anyway, from what I've seen, the array is more idiomatic.
> > It doesn't hurt, but the Itanium ABI does not mangle such global data
> > symbols, so it's not strictly needed.
>
> I don't understand this remark, what does Itanium have to do with this?
The [C++ ABI definition](https://github.com/itanium-cxx-abi/cxx-abi) is
probably Itanium's most lasting contribution to computing. I think it's used on
most non-Windows systems these days, not just on Linux, and of course on all
kinds of CPUs.
-
PR: https://git.openjdk.java.net/jdk/pull/7727
Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v7]
On Sat, 12 Mar 2022 12:32:38 GMT, Andrew Haley wrote:
> > into the assembler sources and use
> > ```c++
> > extern char address_of_label[] __attribute__ ((visibility
> > ("hidden")));
> > ```
>
> ITYM
>
> ```
> extern "C" char address_of_label[] __attribute__ ((visibility ("hidden")));
It doesn't hurt, but the Itanium ABI does not mangle such global data symbols,
so it's not strictly needed.
-
PR: https://git.openjdk.java.net/jdk/pull/7727
Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v7]
On Fri, 11 Mar 2022 23:40:36 GMT, Thomas Stuefe wrote:
> I spent some time doing a static implementation of SafeFetch on Linux x64,
> and its not super trivial. The problem is that we need to know addresses of
> instructions inside that function. I can set labels in assembly, and I can
> export them, but so far I have been unable to use them as addresses in C++
> code. I will research some more.
There are basically two ways (easy) to do it. Put global symbols like
.globl address_of_label
address_of_label:
into the assembler sources and use
```c++
extern char address_of_label[] __attribute__ ((visibility ("hidden")));
from the C++ side.
Or use a local label, and export the difference to the function start to a
local label in a global data symbol from the assembler side:
.globl SafeFetch // Real function name goes here.
SafeFetch:
// …
.Llabel:
// …
.section .rodata
.globl SafeFetch_label_offset
.p2align 3
SafeFetch_label_offset:
.quad .Llabel - SafeFetch
.type SafeFetch_label_offset, @object
.size SafeFetch_label_offset, 8
And use
```c++
extern uintptr_t SafeFetch_label_offset __attribute__ ((__visibility
("hidden")));
and the expression `(uintptr_t) + SafeFetch_label_offset` to compute
the final address. The second approach is friendlier to tools (which may get
confused by symbols in the middle of functions).
If you have a PR, please Cc: me on it, I will have a look.
-
PR: https://git.openjdk.java.net/jdk/pull/7727
Re: RFR: 8282475: SafeFetch should not rely on existence of Thread::current [v6]
On Fri, 11 Mar 2022 09:50:22 GMT, Johannes Bechberger wrote: > According to > https://forums.swift.org/t/concurrencys-use-of-thread-local-variables/48654: > "these accesses are just a move from a system register plus a load/store at a > constant offset." Ideally you'd still benchmark that. Some AArch64 implementations have really, really slow moves from the system register used as the thread pointer. Hopefully Apple's implementation isn't in that category. - PR: https://git.openjdk.java.net/jdk/pull/7727
Re: [libattach] misleading error message when checking gid fails
* stuart nelson: > The reason getegid() returns -1 is because it wasn't in my allowed > syscalls list for seccomp, so EPERM (-1) was returned instead. Surely that's a broken seccomp filter. Such fundamental system calls really cannot be filtered. Thanks, Florian
Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
On Fri, 12 Feb 2021 12:22:44 GMT, Vladimir Kempik wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 435: >> >>> 433: //||\ Java thread created by VM does not >>> have glibc >>> 434: //|glibc guard page| - guard, attached Java thread usually >>> has >>> 435: //||/ 1 glibc guard page. >> >> Is this code going to be built by GCC (with glibc) or will only >> macOS compilers and libraries be used? > > only macos comiplers The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard region independently of page size, otherwise `-fstack-clash-protection` is not reliable. - PR: https://git.openjdk.java.net/jdk/pull/2200
Re: RFD: 8252768: Fast, asynchronous heap dumps
* Volker Simonis: > Not sure this is related to overcommit settings. According to the > man-page, fork() only fails with "ENOMEM" if fork() "failed to > allocate the necessary kernel structures because memory is tight". But > a failing fork is actually no problem at all. Currently, if fork() > fails, I just fall back to normal, synchronous dumping. Of course this > could be made configurable such that a failing asynchronous dump > wouldn't result in a synchronous dump with its long safepoint timeout > but instead completely skip the dump altogether. The problem is a bit more nefarious than that. If memory is tight, but not too tight, the fork will succeed. The dumper subprocess will do its thing, and the original process will continuing to mutate its heap. But the latter needs to create a copy of every page when it's mutated first. This requires memory allocation. If that fails, the OOM killer is invoked. I don't know which process will be terminated to free memory. If it's the production VM, that would be quite bad. Maybe the dumper could lower its OOM score. (This can happen during regular subprocess start without vfork, of course, but there, the critical phase should pass quickly.) Thanks, Florian
Re: RFD: 8252768: Fast, asynchronous heap dumps
* Volker Simonis: >> The other issue is that formally, there are significant restrictions on >> what kind of functionality is available after a fork call from a >> multi-threaded process. Only async-signal-safe functions are supported, >> and POSIX does not include malloc among them. glibc supports malloc as >> an extension, but many other things are broken to varying degrees. > Well, as you said, on Linux malloc() is working and I haven't seen Correction: On glibc. Historically, musl did not have a working malloc after multi-threaded fork because POSIX does not require it. There have been some discussions about supporting it like an extension, similar to glibc, but I don't know the current state. > anything else broken until now. As far as I can see, dumping is only > calling some basic I/O functions which are all async-signal-safe. Do > you have anything concrete in mind for the "many other things are > broken to varying degrees". NSS functions such as getpwuid_r do not work reliably with glibc. Even the FILE * functions have issues. The workaround is to collect this information before the fork, and not use . Thinking about it, the crash dumper would be more problematic in this regard, given the amount of information it collects. The heap dumper probably doesn't need all that. >> It would be safest to fork again and execve a helper process that >> processes the original forked process via mappings from /proc. >> > > The nice thing about this approach is that we're getting the > functionality basically "for free" because it uses Hotspot's own dump > routine without modifications. Processing memory mappings from /proc > would require rewriting the whole dump logic. Yes, that's true. > But there's another approach which I've also thought about. As I > mentioned in my first mail, the SA tools can already create a heap > dump from a core file. So we could immediately raise a SIGSEGV in the > child (which is async-hread-safe :) and create a core file. But you don't know where that coredump lands, and the coredump will also contain non-heap data or non-live heap objects, potentially making it much larger. Thanks, Florian
Re: RFD: 8252768: Fast, asynchronous heap dumps
* Volker Simonis: > Please let me know what you think and if there's something I've > overlooked? ZGC uses shared mappings for the heap, which will remain shared after fork, so this trick does not work there. The other issue is that formally, there are significant restrictions on what kind of functionality is available after a fork call from a multi-threaded process. Only async-signal-safe functions are supported, and POSIX does not include malloc among them. glibc supports malloc as an extension, but many other things are broken to varying degrees. It would be safest to fork again and execve a helper process that processes the original forked process via mappings from /proc. Thanks, Florian
Re: RFR (XS): 8231600: Avoid GCC 8 strncpy error in jdk.jdwp.agent
* Chris Plummer: > Fix looks good. Thanks. Would you be able to sponsor this change for me? Florian > On 9/28/19 2:09 AM, Florian Weimer wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231600 >> Webrev: http://cr.openjdk.java.net/~fweimer/8231600/webrev.01/ >> >> We know the size of the string, so we can use memcpy instead of strncpy. >> >> Thanks, >> Florian
RFR (XS): 8231600: Avoid GCC 8 strncpy error in jdk.jdwp.agent
Bug: https://bugs.openjdk.java.net/browse/JDK-8231600 Webrev: http://cr.openjdk.java.net/~fweimer/8231600/webrev.01/ We know the size of the string, so we can use memcpy instead of strncpy. Thanks, Florian
Re: Providing users with thread type
* Jean Christophe Beyler: > Is there any way we could provide that (not in JVMTI then)? On Linux, you can get truncated thread names from /proc/PID/task/*/comm. Maybe that's sufficient for your needs? Thanks, Florian
Re: JEP 240: Remove the JVM TI hprof Agent
On 02/16/2015 04:23 PM, Mario Torre wrote: Thermostat does support that natively with the CLI interface. Also I believe Visual VM can deal with saved and exported hprof dumps, likewise MAT (and Thermostat), which is probably the most advanced at this stage - so no need to install software really. I believe you are talking about heap dumps here. As far as I understand it, traces from profiling will be gone completely if the hprof agent is removed, so there won't be any data you can analyze externally. -- Florian Weimer / Red Hat Product Security
Re: JEP 240: Remove the JVM TI hprof Agent
On 02/13/2015 01:46 AM, mark.reinh...@oracle.com wrote: New JEP Candidate: http://openjdk.java.net/jeps/240 Removal of the hprof agent interferes with my TLS performance work. I'm not complaining (removing cruft is always a good idea), I'm just providing a data point. If I understand VisualVM correctly, it is GUI-only, so it will not work in headless deployments. I'm not convinced that many production systems allow remote management access (direct support for SSH tunneling might address this concern, though). It's sometimes a challenge to get additional software installed in a production environment—and hprof is just a command line option away. I understand that hprof is not the best JVM profiler out there, but it has been pretty useful to me. -- Florian Weimer / Red Hat Product Security
Re: gdb and OpenJDK
On 02/11/2015 11:27 PM, Jeremy Manson wrote: First, gdb needed to be extended to support the ability to plug in a frame unwinder. The process of submitting this to gdb (which has been ongoing for quite a while) is finally starting to make reasonable progress. Next, we need a plugin for OpenJDK. We have a plugin written that calls out to the serviceability agent. (It's written in Python, per gdb's requirements). Has the license issue already come up? OpenJDK is GPL version 2 only, GDB is GPL version 3 or later. Those two are not compatible. It's typically fine if such processes communicate which each others over a pipe, but direct linking within the same address space might not be okay. I don't know enough about the technology involved here to say if this is going to cause any real problems, but I want to avoid future disappointment. -- Florian Weimer / Red Hat Product Security
Re: Project to improve hs_err files
On 09/06/2013 01:32 PM, Mattis Castegren wrote: Please let me know if you have ideas of what information would make hs_err files more useful, and I will add them to my list. Structured logging to the systemd journal would be an interesting addition. This might be a bit tricky from a signal handler, though: http://lists.freedesktop.org/archives/systemd-devel/2012-November/007341.html http://lists.freedesktop.org/archives/systemd-devel/2014-January/016465.html -- Florian Weimer / Red Hat Product Security Team
Re: RR(S): 8014420 Default JDP address does not match the one assigned by IANA
On 05/15/2013 09:08 PM, Dmitry Samersoff wrote: http://cr.openjdk.java.net/~dsamersoff/8014420.JDP/webrev.01/ There's a typo in the test script, failing: + echo ERROR: Test app not started. Please, check machine resources before failing a bug. I'm not sure about the comma, Please check machine resources might be better. I double-checked that the address and the (unchanged) port number are correct. -- Florian Weimer / Red Hat Product Security Team
Re: Official number assignments for JDP
On 02/11/2013 01:04 PM, Dmitry Samersoff wrote: Thank you for doing it. I'll check with client team what is better for them. Hi, IANA has just notified me that 7095/UDP is now listed as an official port number for JDP: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml Florian -- Florian Weimer / Red Hat Product Security Team
Official number assignments for JDP (was: Re: [7u] Request for approval for 8002048 - Protocol for discovery of manageable Java processes on a network)
On 02/07/2013 12:02 PM, Dmitry Samersoff wrote: Florian, I can submit a request to IANA if you prefer, but I don't know what the turn-around time will be. Official IANA assignment would benefit everybody and your help is much appreciated. So please submit IANA request. I filled out the port number and multicast forms last week. I've already received a Multicast address, ticket [IANA #656814]: 224.0.23.178 JDP Java Discovery Protocol Also listed under http://www.iana.org/assignments/multicast-addresses. (The way things work, it's listed under the requestor. But the address is yours.) I was asked to pass on the following comment: Approved. But please tell them to consider cases where different networks (like many universities around the world) have multicast connectivity, and applications in one network discovering applications in totally unrelated networks. The port number application, ticket [IANA #656816], hasn't been processed yet. I requested registration of port 7095, but I don't know if we'll receive a different number in the end. How should we proceed? Should we wait a bit and change default address and port in one patch? Or do you want to change the default address now and the port number later? -- Florian Weimer / Red Hat Product Security Team
