scala REPL is slow on vista - java

I installed scala-2.8.0.RC3 by extracting the tgz file into my cygwin (vista) home directory. I made sure to set $PATH to scala-2.8.0.RC3/bin.
I start the REPL by typing:
$ scala
Welcome to Scala version 2.8.0.RC3 (Java HotSpot(TM) Client VM, Java 1.6.0_20).
Type in expressions to have them evaluated.
Type :help for more information.
scala>
Now when I tried to enter an expression
scala> 1 + 'a'
the cursor hangs there without any response. Granted that I have chrome open with a million tabs and VLC playing in the background, but CPU utilization was 12% and virtual memory was about 75% utilized. What's going on ? Do I have to set the CLASSPATH or perform other steps.

There is an enormous start-up cost for the REPL (which includes the compiler, of course), but it does not use fsc, it is self-contained within a single JVM. Using it gradually causes JVM bytecode to be converted to native code, after which it's very fast.

Have you tried sending Ctrl+Break to your Scala process ?
For a Java process this will force a dump of all the thread states and you'll be able to see what each thread is doing, what it's waiting on, if it's deadlocked etc.

Related

How to stop "Java platform SE binary" using excessive CPU

Suddenly, even after weeks of normal use, Java(TM) Platform SE binary has started using excessive CPU, causing intense lag on my PC.
The lag starts when I run any program in Java Eclipse Photon. The program is incredibly basic, it should literally just print "hello", but it takes 10 seconds of 70% CPU usage to do it.
It has worked previously, but I don't know what has changed.
My Specs are :
Intel(R) Core(TM) i5-4210U CPU # 1.70Ghz 2.40Ghz
6.00GB Installed memory
64-bit Operating System, x64-based processor
It may be relevant that there are multiple of these Java Platform SE Binary programs open, sometimes up to three, but only one will be using excessive CPU, the others will use about 3% each.
Any ideas how I can fix this issue?
Edit: Simple programs were working quickly previously, but now they are very intensive for seemingly no reason. I have restarted everything, and have the latest version of Java.
Click right mouse button on this process, choose 'preferences' and check path what exactly it is. My bet it's an eclipse, not your app. To verify this export app, close eclipse, run app by typing java -jar YourJarName.jar and then check results in Task Manager

Does bytecode have to be converted to machine code?

I am confused that for in the role of the JVM. Is my understanding correct that JVM only converts the Bytecode to Machine code? So essentially there is communcation between the OS, JVM and CPU. My assumption is that the bytecode gets converted to Machine code and then processed by CPU.
JVM is a virtual machine.
Its like when you install some OS(Linux, Solaris) on VMware or VirtualBox, those are virtual machines. They run on top of the host OS.
JVM is different in a way that it's machine code is bytecode. There are machines which have high level languages as their machine code. If JVM were to run on the hardware and not on the host OS then it would expect a hardware capable of using bytecode instruction set.
However since it's runs on top of host OS, any bytecode instruction is communicated to the host after being converted to machine code. In case of VMware/VirtualBox, these softwares take care of it. In case of JVM it's done by JRE.
JAVA is a compiled and interpreted language and not only just the interpreted language. Lets see step by step execution of its program.
Suppose we write a java program and save it as “hello.java” in a folder somewhere on a hard disk.
The name of the java compiler is “javac”. For its compilation we have to write “javac hello.java” on the command line.
At this stage the high level code gets converted to the machine level code. Java converts it into a .class file as “hello.class” . This code is also known as a byte code because every instruction in this file is of 1 Byte.
This byte code can also be taken away on any other platform like
Mac, Linux or Windows. It only takes a JVM of respective OS for its
execution. Hence, JAVA is known as a first platform independent and
architecturally neutral language.
Now, for its execution, interpreter is used. It is named as a “java” itself. For its interpretation, “java hello.java” should be used on the command line. It internally invokes class loader which is responsible for loading the ‘hello.class’ file from hard disk to JVM’s address space.
Here there comes a ‘Byte code verifier’ which verifies the code to avoid run time failures. After successful verification, JVM executes the byte by byte code with the help of OS.
Thus the whole java program gets executed by JVM and OS. While JVM acts as a mini OS for the java program and it concerns OS only when the instructions are not in its scope.

JVM (Java Virtual Machine) is an abstract machine.

I am a java beginner. i just read a line "
JVM (Java Virtual Machine) is an abstract machine." can anyone please help me to understand term abstract machine. what is abstract machine.
JVM = JAVA VIRTUAL MACHINE:- The word virtual itself indicates that it doesn't exists PHYSICALLY.
Elaborated here:
Abstract means HIDDEN.
When assembly programs runs on a computer, it is executed in the system runtime environment:
Properties
Platform dependent (if compiled for windows, a program will run only in windows not in Linux/UNIX etc.)
Not portable (same as above)
Systems runtime (in user's PC mainly under OS's control)
When Java Program runs into a computer, it is executed in another virtual machine (JVM) for which, the runtime environment is provided by JRE (JAVA Runtime Environment), it is installed automatically when you install JDK (Java Development Kit).
Without JRE, it is impossible to run Java Programs (Update: You can bundle your custom JRE with your code, in that case no need to install JDK or JRE separately but only in JDK9 & above)
This JVM itself runs in the system runtime (in user's PC/OS) but when Java program runs it is loaded into this running JVM.
For more practical AND visual experience:(for Windows only)
Open Task Manager
Go to Processes Tab
Find Java(TM) Platform SE Binary (This is JVM) - Java Instance
And now run a java program and write some code to delay the execution, like multi-threading with wait and notify (you can find such programs on google), due to this running program your Java Instance will show a little high memory and disk usage (not much high but slightly higher than that when no program was running in JRE/JVM). These processes you see in Task Manager, are running in System Runtime, and your Java program will not be listed there.
Instead it will be running inside this already running JRE.
This is the reason why JVM is ABSTRACT.
Now, do a little cross check and prove it..
Run 2-3 java programs, either keep them in longer waiting or just write Input Scanner and don't provide input, program will continue to run in blocking state so that we can see them later.
Once gain, confirm that only one instance of JVM/Java is running in task manager (Depends on how many JREs you have installed, sometimes IDEs can also create one instance, so better close it first for clear observation)
Now, where are those 2-3 Java Programs running?? Open VisualVM (it's under the same package/folder where your java executable resides)..
In this VisualVM, you can clearly see that, all your RUNNING Java Programs are listed.
Now, open side by side windows... Task Manager, VisualVM and one of your Running Code's Console.
Verify,
in Task manager - 1 instance of Java Binary.
in VisualVM - 3 different instances of your programs (if you run 3 java porgram)
Now, provide input in one of your code so that blocking state goes away and program terminates successfully.
Now verify,
in Task Manager - still 1 instance of Java Binary.
in VisualVM - 2 instances, because 1 code terminated/finished.
So, all your Java programs run under a Virtual Machine, a machine that is hidden, physically not available, abstract.
An abstract machine is a machine that does not have a physical existence.
Abstractness
A bicycle has a physical existence. I can touch it. It is not abstract.
A computer chip has a physical existence. I can touch it. It is not abstract.
A JVM is an executing program ... and has no physical existence. I cannot touch it. It is abstract.
Machine-ness:
A bicycle is a machine for transporting people.
A computer chip is a machine for executing programs that are coded in the instruction set of the chip; e.g. Intel x86 machine code.
A JVM is also a machine for executing programs that are coded in the instruction set of all JVMs; i.e. Java bytecodes.
Abstract machine means all of java application run in JVM and JVM runs in different platform as Window, Linux, Mac ...
JVM is interface to java application can run all platform
It is a bit philosophical question. When java application is compiled, the compiler produces its own "assembly" code that can not run directly on a hardware, it needs JVM. So, JVM creates an environment for java code similar to that of a machine. In other words from java perspective it is a machine, but in reality is a program that sits on top of a computer's operating system.
It means not real machine, however, it acts like a machine. Not any machine but as a machine called Central Processing Unit(CPU).
You could understand this like, whenever you write java program, you are writing instructions for a machine, but this machine is abstract, which is called Java Virtual Machine(JVM).
For each Operating system(OS) there is a Virtual Machine so that you do not have to write different versions of your java program to different OS.The JVM that you have in your JDK will handle the translation to each OS.
Your java program passes these steps to be understood by the underlying OS.
.java (Source file) gets compiled by compiler and becomes .class(class file) and this will be passed to JVM to be interpreted to machine language.
Class file is the one that has instructions for JVM

Determine optimal Java runtime parameters before launch?

we're running a Java application for rendering ans displaying quite a number of images. To make this smooth, we's like to assign a fair amount of heap space, and would like to check if there's a 64 bit version available on the computer. We'd like to run the application on many different computers, so manually checking the available memory and the Runtime version by trial and error is quite a hassle.
Does anyone know of a method to determine the availably memory that can be reserved for heap space, and to determine the available JREs; so we could somehow pass these parameters on to the JRE when executing the jar?
I'm aware that this would require some sort of batch file, like discussed in this thread:
Setting Launch Parameters In Java Class
Has anyone come across a running example for a Windows environment? My knowledge about Windows Batch-files is limited at best.
Regards, Marius
to check if java is 64-bit:
java -version 2>&1|find /i "64-Bit" && echo YEP!||echo NOPE!
To get free memory :
wmic os get freephysicalmemory
or:
systeminfo | find "Physical Memory"
EDIT
Universal and fast way to get free memory:
mshta "javascript:close(new ActiveXObject('Scripting.FileSystemObject').GetStandardStream(1).Write(GetObject('winmgmts:').ExecQuery('Select * from Win32_PerfFormattedData_PerfOS_Memory').ItemIndex(0).AvailableBytes));"|more
assign result to variable:
for /f "usebackq" %%a in (`mshta ^"javascript^:close^(new ActiveXObject^(^'Scripting.FileSystemObject^'^).GetStandardStream^(1^).Write^(GetObject^(^'winmgmts:^'^).ExecQuery^(^'Select * from Win32_PerfFormattedData_PerfOS_Memory^'^).ItemIndex^(0^).AvailableBytes^)^);^"^|more`) do set free_mem=%%a

Best way to run a Perl script from weblogic Java EE application

I currently work in a Weblogic Java EE project, where from time to time the application executes a Perl script to do some batch jobs. In the application the script is getting invoked as
Process p = Runtime.getRuntime().exec(cmdString);
Though it is a dangerous way to run, but it was working properly until we had a requirement to execute the script synchronously under a for loop. After a couple of run we are getting
java.io.IOException: Not enough space as probably OS is running out of virtual memory while exec-ing under a for loop. As a result we are not able to run the script at all in the server.
I am desperately looking for a safer and better way to run the Perl script, where we don't need to fork the parent process, or at-least not to eat-up all swap space!
The spec is as follows:
Appserver - Weblogic 9.52
JDK - 1.5
OS - SunOS 5.10
Sun-Fire-T200
I've had something similar on a couple of occasions. Since the child process is a fork of the (very large parent it can see all of it shares all it's memory (using copy on write). What i discovered was that the kernel needs to be able to ensure that it could copy all of the memory pages before forking the child, on a 32bit OS you run out of virtual head run really fast.
Possible solutions:
Use a 64Bit OS and JVM, pushes the issue down the road so far it doesn't matter
Host your script in another process (like HTTPD) and poke it using a HTTP request to invoke it
Create a perl-server, which reads perl scripts via network and executes them one by one.
If you want to keep your code unchanged and have enough disk free space, you can just add a sufficiently large swap area to your OS.
Assuming you need 10 GB, here is how you do it with UFS:
mkfile 10g /export/home/10g-swap
swap -a /export/home/10g-swap
echo "/export/home/10g-swap - - swap - no -" >> /etc/vfstab
If you use ZFS, that would be:
zfs create -V 10gb rpool/swap1
swap -a /dev/zvol/dsk/rpool/swap1
Don't worry about that large a swap, this won't have any performance impact as the swap will only be used for virtual memory reservation, not pagination.
Otherwise, as already suggested in previous replies, one way to avoid the virtual memory issue you experience would be to use a helper program, i.e. a small service that your contact through a network socket (or a higher level protocol like ssh) and that executes the perl script "remotely".
Note that the issue has nothing to do with a 32-bit or 64-bit JVM, it is just Solaris doesn't overcommit memory and this is by design.

Categories