So the problem is that I would like to disable explicit GC to make sure no library can "force" FullGC with System.gc(). But I would like to still retain some control of when FullGC will happen. Is this doable? I mean is it possible to force (or strongly suggest) FullGC via JMX or some Tomcat management tools? Or maybe some command-line in cron?
The motivation of forcing FullGC is to make sure it doesn't happen in the middle of the day.
To my understanding FullGC will happen randomly with -XX:+DisableExplicitGC option. It will happen when Java will feel there is need to do this.
Or maybe there is some way to suggest Java something like "don't do FullGC from 7:00 to 16:00"?
Full GC can be forced even with -XX:+DisableExplicitGC by invoking a heap inspection operation like GC.class_histogram
Via JMX
MBean: com.sun.management:type=DiagnosticCommand
Operation: gcClassHistogram
From the command line
jcmd <pid> GC.class_histogram
Patching System.gc
Alternatively, you can intercept System.gc() calls by preloading a shared library with a custom JVM_GC implementation.
Here is an example:
#define _GNU_SOURCE
#include <time.h>
#include <dlfcn.h>
void JVM_GC() {
time_t timestamp = time(NULL);
struct tm t;
localtime_r(×tamp, &t);
// Don't do Full GC between 7:00 and 16:00
if (t.tm_hour >= 7 && t.tm_hour < 16) {
return;
}
void* original_jvm_gc = dlsym(RTLD_NEXT, "JVM_GC");
if (original_jvm_gc != NULL) {
((void (*)()) original_jvm_gc)();
}
}
Compile:
gcc -O2 -fPIC -shared -o librestrictgc.so restrictgc.c -ldl
Run:
LD_PRELOAD=/path/to/librestrictgc.so java <args>
Related
There is a large number of questions on SO about how to execute a library or dynamically load an executable. As far as I can tell, all the answers come down to: compile your executable as position-independent code and load it with dlopen. This worked great --- and still works great on macOS --- until a recent change in glibc, which explicitly disabled dlopening PIEs. This change is now in the current version of glibc (2.30) on ArchLinux, for example, and trying to dlopen a position-independent executable gives an error: "cannot dynamically load position-independent executable".
It's difficult to guess what prompted such a radical change that breaks so much code and useful use cases. (The explanations on Patchwork and Bugzilla don't make much sense to me.) But there is now a question: what to do if you want to create an executable that's also a dynamic library, or vice versa?
A solution was linked from one of the comments. Reproducing it here for posterity:
#include <stdio.h>
#include <unistd.h>
const char service_interp[] __attribute__((section(".interp"))) = "/lib/ld-linux-x86-64.so.2";
extern "C" {
void lib_entry(void)
{
printf("Entry point of the service library\n");
_exit(0);
}
}
Compiling with g++ -shared test-no-pie.cpp -o test-no-pie -Wl,-e,lib_entry produces a shared object (dynamic library) that can also be executed on Linux.
I have two questions:
What if I want to pass command-line arguments? How to modify this solution so it accepts arc,argv?
Are there other alternatives?
It's difficult to guess what prompted such a radical change
Not really: it never worked correctly.
that breaks so much code
That code was broken already in subtle ways. Now you get a clear indication that it will not work.
Are there other alternatives?
Don't do that?
What problem does dlopening an executable solve?
If it's a real problem, open a GLIBC bugzilla feature request, explaining that problem and requesting a supported mechanism to achieve desired result.
Update:
at least say why "it never worked correctly". Is it some triviality like potentially clashing globals between the executables, or something real?
Thread-local variables is an example that doesn't work correctly. Whether you think they are "real" or not I have no idea.
Here is the code:
// foo.c
#include <stdio.h>
__thread int var;
__attribute__((constructor))
static void init()
{
var = 42;
printf("foo.c init: %d %p\n", var, &var);
}
int bar() {
printf("foo.c bar: %d %p\n", var, &var);
return var;
}
int main()
{
printf("foo.c main: %d %p bar()=%d\n", var, &var, bar());
return 0;
}
gcc -g foo.c -o foo -Wl,-E -fpie -pie && ./foo
foo.c init: 42 0x7fb5dfd7d4fc
foo.c bar: 42 0x7fb5dfd7d4fc
foo.c main: 42 0x7fb5dfd7d4fc bar()=42
// main.c
// Error checking omitted for brevity
#include <dlfcn.h>
#include <stdio.h>
int main()
{
void *h1 = dlopen("./foo", RTLD_LOCAL|RTLD_LAZY);
int (*bar)(void) = dlsym(h1, "bar");
printf("main.c: %d\n", bar());
return 0;
}
gcc -g main.c -ldl && ./a.out
foo.c init: 42 0x7fb7305da73c
foo.c bar: 0 0x7fb7305da73c <<< what?
main.c: 0 <<< what?
This is using GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
Bottom line: this was never designed to work, and you just happened to not step on many of the land-mines, so you thought it is working, when in fact you were exercising undefined behavior.
Please see this answer:
https://stackoverflow.com/a/68339111/14760867
The argc, argv question is not answered there, but when I found I needed one, I hacked something together to parse /proc/self/cmdline at runtime for pam_cap.so use.
There is a large number of questions on SO about how to execute a library or dynamically load an executable. As far as I can tell, all the answers come down to: compile your executable as position-independent code and load it with dlopen. This worked great --- and still works great on macOS --- until a recent change in glibc, which explicitly disabled dlopening PIEs. This change is now in the current version of glibc (2.30) on ArchLinux, for example, and trying to dlopen a position-independent executable gives an error: "cannot dynamically load position-independent executable".
It's difficult to guess what prompted such a radical change that breaks so much code and useful use cases. (The explanations on Patchwork and Bugzilla don't make much sense to me.) But there is now a question: what to do if you want to create an executable that's also a dynamic library, or vice versa?
A solution was linked from one of the comments. Reproducing it here for posterity:
#include <stdio.h>
#include <unistd.h>
const char service_interp[] __attribute__((section(".interp"))) = "/lib/ld-linux-x86-64.so.2";
extern "C" {
void lib_entry(void)
{
printf("Entry point of the service library\n");
_exit(0);
}
}
Compiling with g++ -shared test-no-pie.cpp -o test-no-pie -Wl,-e,lib_entry produces a shared object (dynamic library) that can also be executed on Linux.
I have two questions:
What if I want to pass command-line arguments? How to modify this solution so it accepts arc,argv?
Are there other alternatives?
It's difficult to guess what prompted such a radical change
Not really: it never worked correctly.
that breaks so much code
That code was broken already in subtle ways. Now you get a clear indication that it will not work.
Are there other alternatives?
Don't do that?
What problem does dlopening an executable solve?
If it's a real problem, open a GLIBC bugzilla feature request, explaining that problem and requesting a supported mechanism to achieve desired result.
Update:
at least say why "it never worked correctly". Is it some triviality like potentially clashing globals between the executables, or something real?
Thread-local variables is an example that doesn't work correctly. Whether you think they are "real" or not I have no idea.
Here is the code:
// foo.c
#include <stdio.h>
__thread int var;
__attribute__((constructor))
static void init()
{
var = 42;
printf("foo.c init: %d %p\n", var, &var);
}
int bar() {
printf("foo.c bar: %d %p\n", var, &var);
return var;
}
int main()
{
printf("foo.c main: %d %p bar()=%d\n", var, &var, bar());
return 0;
}
gcc -g foo.c -o foo -Wl,-E -fpie -pie && ./foo
foo.c init: 42 0x7fb5dfd7d4fc
foo.c bar: 42 0x7fb5dfd7d4fc
foo.c main: 42 0x7fb5dfd7d4fc bar()=42
// main.c
// Error checking omitted for brevity
#include <dlfcn.h>
#include <stdio.h>
int main()
{
void *h1 = dlopen("./foo", RTLD_LOCAL|RTLD_LAZY);
int (*bar)(void) = dlsym(h1, "bar");
printf("main.c: %d\n", bar());
return 0;
}
gcc -g main.c -ldl && ./a.out
foo.c init: 42 0x7fb7305da73c
foo.c bar: 0 0x7fb7305da73c <<< what?
main.c: 0 <<< what?
This is using GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
Bottom line: this was never designed to work, and you just happened to not step on many of the land-mines, so you thought it is working, when in fact you were exercising undefined behavior.
Please see this answer:
https://stackoverflow.com/a/68339111/14760867
The argc, argv question is not answered there, but when I found I needed one, I hacked something together to parse /proc/self/cmdline at runtime for pam_cap.so use.
I read the following manual:
http://linux.die.net/man/3/clock_gettime
and I wrote the following code:
#include <time.h>
int main() {
struct timespec clk;
clock_gettime(CLOCK_REALTIME, &clk);
return 0;
}
Surprisingly, I get the following errors:
Symbol CLOCK_REALTIME could not be resolved
undefined reference to clock_gettime
I still don't understand what is the problem. I included the header, and these names show in this header.
maybe you should use#define _POSIX_TIMERS,#define _REENTRANT
besides, when you compile the code, make sure to link the real-time library which is cc filename.c -o filename -lrt
Update 1.0:
sometimes in windows or mac os, C ide may not include real-time library automatically, or we may not used the posix directly without _POSIX_TIMES, therefore you have to link the real-time library manually. In Linux, you can just type in cc filename.c -o filename -lrt to compile the c file.
This question is related to this one as well as its answer.
I just discovered some ugliness in a build I'm working on. The situation looks somewhat like the following (written in gmake format); note, this specifically applies to a 32-bit memory model on sparc and x86 hardware:
OBJ_SET1 := some objects
OBJ_SET2 := some objects
# note: OBJ_SET2 doesn't get this flag
${OBJ_SET1} : CCFLAGS += -PIC
${OBJ_SET1} ${OBJ_SET2} : %.o : %.cc
${CCC} ${CCFLAGS} -m32 -o ${#} -c ${<}
obj1.o : ${OBJ_SET1}
obj2.o : ${OBJ_SET2}
sharedlib.so : obj1.o obj2.o
obj1.o obj2.o sharedlib.so :
${LINK} ${LDFLAGS} -m32 -PIC -o ${#} ${^}
Clearly it can work to mix objects compiled with and without PIC in a shared object (this has been in use for years). I don't know enough about PIC to know whether it's a good idea/smart, and my guess is in this case it's not needed but rather it's happening because someone didn't care enough to find out the right way to do it when tacking on new stuff to the build.
My question is:
Is this safe
Is it a good idea
What potential problems can occur as a result
If I switch everything to PIC, are there any non-obvious gotchas that I might want to watch out for.
Forgot I even wrote this question.
Some explanations are in order first:
Non-PIC code may be loaded by the OS into any position in memory in [most?] modern OSs. After everything is loaded, it goes through a phase that fixes up the text segment (where the executable stuff ends up) so it correctly addresses global variables; to pull this off, the text segment must be writable.
PIC executable data can be loaded once by the OS and shared across multiple users/processes. For the OS to do this, however, the text segment must be read-only -- which means no fix-ups. The code is compiled to use a Global Offset Table (GOT) so it can address globals relative to the GOT, alleviating the need for fix-ups.
If a shared object is built without PIC, although it is strongly encouraged it doesn't appear that it's strictly necessary; if the OS must fix-up the text segment then it's forced to load it into memory that's marked read-write ... which prevents sharing across processes/users.
If an executable binary is built /with/ PIC, I don't know what goes wrong under the hood but I've witnessed a few tools become unstable (mysterious crashes & the like).
The answers:
Mixing PIC/non-PIC, or using PIC in executables can cause hard to predict and track down instabilities. I don't have a technical explanation for why.
... to include segfaults, bus errors, stack corruption, and probably more besides.
Non-PIC in shared objects is probably not going to cause any serious problems, though it can result in more RAM used if the library is used many times across processes and/or users.
update (4/17)
I've since discovered the cause of some of the crashes I had seen previously. To illustrate:
/*header.h*/
#include <map>
typedef std::map<std::string,std::string> StringMap;
StringMap asdf;
/*file1.cc*/
#include "header.h"
/*file2.cc*/
#include "header.h"
int main( int argc, char** argv ) {
for( int ii = 0; ii < argc; ++ii ) {
asdf[argv[ii]] = argv[ii];
}
return 0;
}
... then:
$ g++ file1.cc -shared -PIC -o libblah1.so
$ g++ file1.cc -shared -PIC -o libblah2.so
$ g++ file1.cc -shared -PIC -o libblah3.so
$ g++ file1.cc -shared -PIC -o libblah4.so
$ g++ file1.cc -shared -PIC -o libblah5.so
$ g++ -zmuldefs file2.cc -Wl,-{L,R}$(pwd) -lblah{1..5} -o fdsa
# ^^^^^^^^^
# This is the evil that made it possible
$ args=(this is the song that never ends);
$ eval ./fdsa $(for i in {1..100}; do echo -n ${args[*]}; done)
That particular example may not end up crashing, but it's basically the situation that had existed in that group's code. If it does crash it'll likely be in the destructor, usually a double-free error.
Many years previous they added -zmuldefs to their build to get rid of multiply defined symbol errors. The compiler emits code for running constructors/destructors on global objects. -zmuldefs forces them to live at the same location in memory but it still runs the constructors/destructors once for the exe and each library that included the offending header -- hence the double-free.
I am using the following code to set the cr0 bit to disable cache.
When I compile this
#include <stdio.h>
int main()
{
__asm__("pushl %eax\n\t"
"mov %cr0,%eax;\n\t"
"orl $(1 << 30),%eax;\n\t"
"mov %eax,%cr0;\n\t"
"wbinvd\n\t"
"popl %eax"
);
return 0;
}
I am getting error saying that the operands are invalid for mov.
Can anyone please point me to a good gcc x86-64 guide for doing these kinds of things?
Also what exactly is wrong with the above code?
Ok, so finally I wrote the following kernel module. Am not sure it is right, since I don't observe the drastic slowdown which should accompany when you disable cache. But this compiles and inserts properly.
Any pointers will be helpful.
Thanks!
#include <linux/init.h>
#include <linux/module.h>
MODULE_LICENSE("Dual BSD/GPL");
static int hello_init(void)
{
printk(KERN_ALERT "Hello, world\n");
__asm__("push %rax\n\t"
"mov %cr0,%rax;\n\t"
"or $(1 << 30),%rax;\n\t"
"mov %rax,%cr0;\n\t"
"wbinvd\n\t"
"pop %rax"
);
return 0;
}
static void hello_exit(void)
{
printk(KERN_ALERT "Goodbye, cruel world\n");
__asm__("push %rax\n\t"
"mov %cr0,%rax;\n\t"
"and $~(1 << 30),%rax;\n\t"
"mov %rax,%cr0;\n\t"
"wbinvd\n\t"
"pop %rax"
);
}
module_init(hello_init);
module_exit(hello_exit);
You cannot do operations like this from user code and even running as root is user code.
You will need to make this into a driver module and load it using insmod.
I think you don't see the "drastic slowdown" because you have multiple cores, right?
I made some experiments and it seems to me that setting CD in %cr0 only affects the processor your are running the module on.
Make sure that you run your code on all cores where you want to disable caching. You could, for example, create a /proc/cachedisable file where a read triggers your code. Then use
taskset -c cpu_number cat /proc/cachedisable
to disable the caches on CPU cpu_number. Do the same with /proc/cacheenable and you have everything you need. This works for me and there is no need to alter the MTRRs, which is pretty complicated. If you have multiple processors then you can disable caching on only one of them and perform your experiments on this cpu. Then the rest of the system remains usable.
Try this:
"mov %%cr0, %%eax \n"
A simple % is interpreted as user argument (I think).
You should read this
The code compiles OK for me on 32-bit x86 bit not on x86-64 - this is with gcc 4.2.1 on Mac OS X:
$ gcc -Wall -m32 cr0.c -o cr0
$
No errors or warnings.
$ gcc -Wall -m64 cr0.c -o cr0
/var/folders/.../cce0FYAB.s:9:suffix or operands invalid for `push'
/var/folders/.../cce0FYAB.s:10:suffix or operands invalid for `mov'
/var/folders/.../cce0FYAB.s:12:suffix or operands invalid for `mov'
/var/folders/.../cce0FYAB.s:14:suffix or operands invalid for `pop'
$
So I guess there are deeper issues than just the mov %eax,%cr0 instruction here with asm on x86-64.
Looking at the x86-64 ISA it seems that you probably need something like this for x86-64:
#include <stdio.h>
int main()
{
__asm__("pushq %rax\n\t"
"movq %cr0,%rax\n\t"
"orl $(1 << 30),%eax\n\t"
"movq %rax,%cr0\n\t"
"wbinvd\n\t"
"popq %rax"
);
return 0;
}
I don't know if this works but it at least compiles/assembles OK:
$ gcc -Wall -m64 cr0.c -o cr0
$