FULL PRODUCT VERSION :
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
SunOS 5.11 11.3 i86pc i386 i86pc
Slow SATA disk 1MB/s may aggravate the situation.
But even during slowness, other programs manage to process several MB of data faster than slowness of Java subsides.

EXTRA RELEVANT SYSTEM CONFIGURATION :
Memory 2GB. Not exhausted. About half remains free.
Plenty of disk space. Swap (/tmp) not exhausted.
Sole use is to run developerstudio12.6. That is based on NetBeans.

A DESCRIPTION OF THE PROBLEM :
Developerstudio of any version becomes very slow. Sometimes this occurs initially. Sometimes after some work on a project.
Delay may be several minutes. The entire computer may freeze, or become very slow.
Excessive disk activity.
CPU usage is not 100%. Yet everything becomes slow. It maybe due to some bottleneck on Input/Output, rather than CPU. Or perhaps CPU usage becomes 100% in bursts, which monitors are not so fast to detect.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Just run Developerstudio, or any NetBeans. Try just any application in Java. I am sure the bug would reproduce.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Nothing fancy. Just editing code, and using "Code Assistance" on it.
Should work as fast as any text editor.
ACTUAL -
In most severe case computer froze for about 20 minutes. Then resumed.
The only way to work faster was to shutdown Developerstudio. This shuts Java as well. Then restart.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
None.
It seems as if Developerstudio is slow. But actually it delays only because of Java.

After I applied the workaround, Java did produce a crash log once in /var/log. In it wrote that it could not allocate 2MB of memory. Although memory is mostly free.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Run as root.
Add arguments (flags) to Developerstudio:
-J-XX:+AggressiveHeap
-J-XX:+AggressiveOpts
-J-XX:+UseG1GC
-J-XX:+UseStringDeduplication
"-J" means to pass it to Java.

The options -J-XX:+AggressiveHeap, and -J-XX:+AggressiveOpts alleviate the problem only for a while. Maybe it was an illusion.
Then I added -J-XX:+UseG1GC -J-XX:+UseStringDeduplication. I had to exclude -J-XX:+AggressiveHeap, because Java complained it is incompatible with -J-XX:+UseG1GC.
I ran as root (by mistake).
- No slowness whatsoever.

Then I ran as ordinary user with:
-J-XX:+AggressiveOpts
-J-XX:+UseG1GC
-J-XX:+UseStringDeduplication
It worked slower. But not as drastically as before. Then crashed, as I described in "Error Message(s)/ Crash Logs".
Then I removed options 1 by 1. Still crashed. Now without a crash log. Maybe Java produces a crash log only when run from terminal, as opposed to menu.
Finally I ran just with 1 flag:
-J-XX:+UseG1GC
Crashes are infrequent. Have to be careful not to strain the application with too much activity. So, it does not crash for long. Although the activity is not excessive. For example, I pressed button "back" in dialogue for a new file in Developerstudio. It crashed. If I would not save other files prior to this, they would be lost. Ironically, the file, which I tried to create, was this report.
Even a crash is far better than the severe slowness.

If not for the workaround, the software would be useless.
Now it works bearably.
I already succeed to use Developerstudio to modify sendmail. I can give the modification to you. So you may give it to other users.

I tried to update JRE to newer version. But "Package Manager" prohibits this, because of old "incorporation". The new version does exist. But new "incorporation" - not. It bans packages, which are too new. In case of JRE - just any newer package.