Ant build consumes a lot of time and memory for my project. Specially flex and groovy compilation take most of the time. Java build with Aspect wiring happens in 3-5 min but flex and groovy components together takes 120 min.
As I am running Ant from a bat file ANT_OPTS setting is:
set ANT_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=128m
System configuration is
Ant 1.6
JDK 1.6
Flex SDK 3.6a
RAM 8 GB
During the build I get following warning:
Java HotSpot(TM) Client VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) Client VM warning: Try increasing the code cache size using -XX
:ReservedCodeCacheSize=
I have noticed that flex compiler [mxmlc] builds all the application files irrespective if they are changed or not.
Is there any way I can make it faster?
Currently it takes 120 min to build my application and I am not able to use my machine during that time.
Related
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
I'm a newbie in OpenCL.
Now I'm trying to compile one of the NVIDIA OPENCL SDK CODE SAMPLES named "OpenCL Bandwidth Test" linked here (https://developer.nvidia.com/opencl).
In this sample, a file named "oclBandwidthTest.cpp" is included.
And this file consults "oclUtils.h" and "shrQATest.h", so I added these two files path in makefile.
But when I try to compile it it still says "undefined reference to 'shrLog' 'shrLogEx' 'oclErrorString'" ... (too many).
I must do it until tomorrow but from last friday I'm still bound it.
I'm working on Ubuntu 12.04, I already installed SDK 4.2 and device driver.
Let me know what I must include (header file or library) in makefile.
II.B. Linux Installation Instructions
The OpenCL SDK samples in the NVIDIA GPU Computing SDK require a GPU with CUDA Compute
Architecture to run properly. For a complete list of CUDA-Architecture compute-enabled GPUs,
see the list online at: http://www.nvidia.com/object/cuda_learn_products.html
The OpenCL applications in the NVIDIA GPU Computing SDK require version 258.19 of the NVIDIA
Display Driver or later to run on 32 bit or 64 bit Linux. This required driver is made available to
registered developers at: https://nvdeveloper.nvidia.com/login.asp?action=login
Please make sure to read the Driver Installation Hints Document before you
install the driver: http://www.nvidia.com/object/driver_installation_hints.html
Uninstall any previous versions of the NVIDIA GPU Computing SDK
Install the NVIDIA GPU Computing SDK by running the installer provided for your OS.
The default installation folder for the OpenCL SDK is:
Linux
$(HOME)/NVIDIA_GPU_Computing_SDK/
In the following we will refer to the path that the SDK is installed into as .
Build the 32-bit or 64-bit (match the installation OS), release and debug
configurations, of the entire set of SDK projects and utility dependencies.
a. Go to /OpenCL
b. Build:
release configuration by typing "make".
debug configuration by typing "make dbg=1".
Running make at the top level first builds the shared and common utility libraries used by
the SDK samples (these libraries are simply for convenience and are not part of the OpenCL
distribution and are not required for your own OpenCL programs). Make then builds each
of the projects in the SDK.
Run the examples from the release or debug directory located in
/OpenCL/bin/linux/[release|debug].
Most of the SDK applications output messages to a console window that are of interest from the
standpoint of understanding basic OpenCL program flow, and several of the applications generate
graphics output in a separate OpenGL window.
Many of the SDK applications present some timing information useful for obtaining an
overall perspective of program structure and flow and the time required for setup and execution of
significant functions. The SDK example code, however, has generally been simplified for instructional
purposes and is not optimized. Advanced optimization techniques are beyond the scope of this SDK, and
any timing information presented by the samples is not intended for such usage as benchmarking.
All of the applications additionally log all the console information to a session log file in the
same directory as the executables. Those files are named clearly after the name of the sample app,
but with a .txt extension.
For convenience, the Makefile in /OpenCL can be used to execute all
SDK samples sequentially by typing "make runall" or "make dbg=1 runall".
I m currently using adobe flash builder 4.6 n there is java heap space error. i cleaned my project every time but it's not working is there any permanent solution for this issue, plz help as soon as possible.
java heap error comes for several reason like a build a project which has too much library in it build path for this type of project you have to build individual library and then build main Project.
You can increase a heap memory flash builder 4.6(FB 4.6) manually. 1024MB is a maximum limit of heap memory allocation. you can't allocate more memory than 1024MB.
go to C:\Program Files\Adobe\Adobe Flash Builder 4.6 and open FlashBuilder.ini file and update the line -Xmx512m to -Xmx1024m. By default 512MB heap memory allocate to heap. but you can increase it manually.
warning
if you try to increase heap memory more than 1024 then your FB 4.6 not open.
if this not solves your problem then put a log file
Using OpenJDK 7 from the command line on OS X Lion, how can I use jdb to debug an application that requires execution under a 32-bit JVM, due to JNI native code?
I know I can invoke java as java -d32 and it will use a 32-bit JVM. I can also pass that -d32 flag to jdb without an error, but it does not seem to have any effect: I still get the same error messages when the application tries to link its native code. Passing -J-d32 exhibits the same behaviour.
It is possible to achieve the above by starting java and jdb as separate processes from two different Terminal windows. So execute these commands, each in its own window:
java -d32 -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=127.0.0.1:5463 -classpath . MainClass
jdb -attach 127.0.0.1:5463
The first will start the JVM for the application, but suspend it immediately after creation. The second will start the debugger and attach it to the JVm just created. Then you can type run in that second window to launch the application. As an added bonus, output from the application and the debugger are not intermixed, as each has its own window.
References: The jdb help lists possible command line arguments, and JPDA has a section on transports.
Although the above does work for me, I'd welcome other answers providing easier solutions, preferrably as a single command and/or without any need to choose port numbers in an arbitrary fashion. The shared memory connector does not seem to work for my JVM.
I am doing some testing to determine resource usage of a rails war. I have used Warbler to package the "15-minute Blog" application using Rails 2.3.5 and JRuby 1.4.0. I am deploying into Tomcat 6.0.24 and create multiple deployments by copying the blog.war file as blogN.war.
This worked great for the first 4 deployments but I can't seem to deploy any more than 4 instances of the war; in other words, the catalina.out log hangs with "Deploying web application archive blog5.war".
Any ideas on what the problem might be or how I might better trouble-shoot this?
Increasing PermGenSpace memory to "-XX:PermSize=64m -XX:MaxPermSize=128m" corrected this problem.
Check your log files, may be the case that your java process, in which tomcat executes, runs out of memory, see java parameters ( -Xmx -Xms ) and http://wiki.apache.org/tomcat/FAQ/Memory . Increasing the available memory may allow you to run more instances of the application.