tcmalloc is one part of gperftools. I discover the version of tcmalloc used in gperftools laest version(currently 2.10) entirely different from tcmalloc from github: https://github.com/google/tcmalloc.
Anyone tells me the differenece between gperftools's tcmalloc and libtcmalloc.so from LD_PRELOAD, and how gerftools interacts with tcmalloc(register hook?)
Related
While building the code getting package sun.security.action is not visible
Package sun.security.action is declared on module java.base, which does not export it to the unnamed module.
What should I do.
Kindly advice, Thanks in advance
Java 8 had no module system - everything is visible or just needs to get imported by archives in jdk (f.e. tools.jar).
Java 9 brought JMS and encapsulated some jdk classes.
In your case, see <JAVA_HOME>/lib/src.zip!/java.base/module-info.class:
exports sun.security.action to
java.desktop,
java.security.jgss,
jdk.crypto.ec,
jdk.incubator.foreign;
Your package isn't public but restricted to some other internal packages/modules.
There was a workaround by adding compiler option --add-exports=java.base/sun.security.action=ALL-UNNAMED at compile time to fix this limitation until version 16.
With version 17 and JEP 403 forget all hope:
It is not a goal to define new standard APIs to replace internal elements for which standard replacements do not yet exist, though such APIs could be suggested in response to this JEP.
Backwards compatibility and important frameworks have lower priority than jdk security - JCP makes strange decisions and works against the community sometimes -.-
is UPX able to pack Dylibs ? it works very well with Mac Os X application executables, but I cannot make it pack a dylib it throws an UnknownExecutableFormatException exception. Nevertheless I can see a lot of references to dylibs in the mach-o part of upx source code. Any hints ? Thanks a lot.
It was possible on older versions of UPX if the dylib included an init or load command (eg. LC_ROUTINES). The developers withdrew this one version later though due to other unforeseen issues with trying to pack dylibs. So to answer your question, yes it is possible, but only under certain cirumstances, and not recommended.
Changes in 3.05 (27 Apr 2010):
...
* Withdraw support for shared libraries on Darwin (Apple Mac OS X)
because upx does not understand enough about .dylib.
..
Changes in 3.04 (27 Sep 2009):
...
* new formats Dylib/i386 and Dylib/ppc32 support shared libraries
[such as browser plugins] on Darwin (Apple Macintosh). An existing
-init function (LC_ROUTINES command) is required.
...
What I have tried (running Tcl and Tk 8.6.0 on Windows):
load D:/toot/bar/em.dll
load "D:/toot/bar/em.dll"
load D://toot//bar//em.dll
load "D://toot//bar//em.dll"
load D:\toot\bar\em.dll
load "D:\toot\bar\em.dll"
load D:\\toot\\bar\\em.dll
load "D:\\toot\\bar\\em.dll"
All of which return one of these two errors:
couldn't load library [what I put after 'load']: invalid argument
couldn't load library [what I put after 'load', rendered]: this library or a dependent library could not be found in library path
Assuming that file exists D:/toot/bar/em.dll returns truea, load D:/toot/bar/em.dll should work. However, it sounds like you've got problems with things (i.e., other DLLs) that the library depends on.
This is a general problem on Windows that has been asked elsewhere on Stack Overflow; the answers there are relevant to this question. You should also be aware that if the DLL has been linked against a specific version of the Tcl DLL (not recommended on Windows for Tcl extensions) then you need to have the same version of Tcl installed as it was linked against. Stub-enabled extensions do not have this problem at all (though they can still run into problems with other required libraries being absent).
It's a shame that the load command doesn't tell you what DLL is missing in its error message, but IIRC the underlying OS API doesn't report it either. You're stuck with using an external tool to diagnose these things…
a Don't worry about backslash/forward-slash issues; Tcl handles those for you.
I have this problem, too,couldn't load library "ChariotExt": invalid argument.
And sovled it by change tcl version x64 to x86.
Is it possible to use incr-tcl when working with tcl version 8.4.19?
Which include packages are required?
Until now we used Active-Tcl version 8.6, which came with incr-tcl built-in. Now we need to support stations that only have version 8.4.19 installed, and I want to know whether there's a technological roadblock or if it's just a matter of installing and referencing additional packages.
It's most certainly possible to have [incr Tcl] working with the Tcl 8.4 series.
bash$ tclsh8.4
% puts [info patchlevel]
8.4.7
% package require Itcl
3.3
% puts $itcl::patchLevel
3.3b1
You might prefer a slightly different version, but that combination works on my system (OSX Leopard).
We are trying to do benchmarking of JVM on our system using SPECJVM2008. It is seen that the pre-compiled Specjvm2008.jar is compiled with a higher version than JDK 1.4 but my system will understand only JDK-1.4 or lower. I looked out for procedure to compile SPECJVM2008 for my target but could not find any. Can anyone help me to cross-compile SPECJVM2008 ? Thanks.
SpecJVM2008 will not support JDK-1.4 b'cos it is written using JDK-1.5 and later and is not backward compatible
I refer you to retrotranslator
Executing:
java -jar retrotranslator-transformer-1.2.9.jar -srcjar SPECjvm2008.jar -destjar SPECjvm2008_14.jar -embed com.mycompany.internal
produces a JDK 1.4 compatible jar with SPECjvm2008.