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__ ((v
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")));
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
> expor
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. S
* 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
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 usuall
* 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()
> fai
* 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 suppo
* 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 fu
* 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/
>>
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
* 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
all 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
e. 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 disa
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
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
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
/service-names-port-numbers.xml>
Florian
--
Florian Weimer / Red Hat Product Security Team
ess
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
* keith mcguigan:
> 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes
> Summary: Initial checkin of JSDT code
> Reviewed-by: sspitsyn, sbohne
>
> ! make/com/sun/Makefile
> + make/com/sun/tracing/Makefile
This file contains the wrong copyright header:
diff -r 66c2b0cf
20 matches
Mail list logo
