Is there a way of outputting the Java heap space, the JRuby application was started with (like -J-Xms2048m), from the application code?
The value passed in at the JVM command line is available in the Runtime JMX bean provided by the JDK, as #stephanlindauer pointed out.
Another way that's less sensitive to how the JVM was launched is to use the Memory bean, like so:
membean = java.lang.management.ManagementFactory.memory_mx_bean
heap = membean.heap_memory_usage
puts heap.max
On my system with no special JRuby flags, this outputs "466092032" (roughly reflecting our default max of 500MB), and when specifying a 2GB maximum heap, (jruby -J-Xmx2g) it outputs "1908932608".
turns out, you can puts values that were passed in via the environment variables like this:
puts java.lang.System.getenv()['JRUBY_OPTS']
or
puts ENV['JRUBY_OPTS']
or
puts java.lang.management.ManagementFactory.getRuntimeMXBean().getInputArguments().to_s
remember to require "java" before.
Related
Could someone please tell me why a variable is declared as "External" in a module and how to use that in other modules through Linkage section and how to pass them into new fields so I can write it to a new file.
EXTERNAL items are commonly found in WORKING-STORAGE. These are normally not passed from one program to another via CALL and LINKAGE but shared directly via the COBOL runtime.
Declaring an item as EXTERNAL behaves like "runtime named global storage", you assign a name and a length to a global piece of memory and can access it anywhere in the same runtime unit (no direct CALL needed), even in cases like the following:
MAIN
-> CALL B
B: somevar EXTERNAL
-> MOVE 'TEST' TO somevar
-> CANCEL B
-> CALL C
C: somevar EXTERNAL -> now contains 'TEST'
On an IBM Z mainframe, running z/OS, the runtime routines for all High Level Languages (HLLs) is called Language Environment (LE). Decades ago, each HLL had its own runtime and this caused some problems when they were mixed into the same run unit; starting in the early 1990s IBM switched all HLLs to LE for their runtime.
LE has the concept of an enclave. Part of the text at that link says an enclave is the equivalent of a run unit in COBOL.
Your question is tagged CICS, and sometimes behavior is different when running in that environment. Quoting from that link...
Under CICS the execution of a CICS LINK command creates what Language Environment calls a Child Enclave. A new environment is initialized and the child enclave gets its runtime options. These runtime options are independent of those options that existed in the creating enclave.
[...]
Something similar happens when a CICS XCTL command is executed. In this case we do not get a child enclave, but the existing enclave is terminated and then reinitialized with the runtime options determined for the new program. The same performance considerations apply.
So, as #SimonSobich noted, if you use CALLs to invoke your subroutines when running in CICS, EXTERNAL data is global to the run unit. But, if you use EXEC CICS XCTL to invoke your subroutines, you may see different behavior and have to design your application differently.
I actually need to know the attributes of my UDP Agent in my TCL script (to print some values and use it for statistics) and this is my first time with this script language. I tried to use the command info but I failed to use it.
This is my code :
#Setup a UDP connection
set udp [new Agent/UDP]
puts [$udp info class] # Work and print "Agent/UDP"
puts [info class variables Agent/UDP] #Fail with the error "Agent/UDP does not refer to an object"
I tried with :
puts [info class variables udp] #Fail (same error)
puts [info class variables $udp] #Error : _o87 does not refer to an object
No more result.
Can you tell me what I did wrong and how to get the attributes of my Agent/UDP object.
The problem is that there are multiple object systems about. Agent/UDP is an OTcl class, whereas info class operates on TclOO classes. TclOO (the standard object system from Tcl 8.6 onwards) is quite a lot newer than OTcl and has more features (it is faster too) but the syntax is a bit different in the detail so we don't expect ns-2 to ever be ported over. (There is a twisted heritage from OTcl to TclOO via XOTcl… but the syntax isn't one of the things that made the transition, as that was drawn more from another object system, [incr Tcl]. Tcl's been “blessed” with a plague of object systems.)
Documentation for OTcl isn't the easiest to find, but this page is helpful, as is the equivalent for instances. In particular, it tells us that we can do introspection via the info instproc (i.e., method):
set udp [new Agent/UDP]
puts [$udp info vars]
puts [$udp info commands]
I see a lot of config options like jit.logging=true, and I want to watch out for things like when the jvm gives CodeCache is full. Compiler has been disabled messages, where does jruby log this stuff? Better yet, how can I tell it which file to log to? Is it just STDOUT and STDERR?
By setting JRuby properties that affects JIT Runtime Properties ( such as: jruby.jit.logging, jruby.jit.logging, jruby.jit.logging ) you get log to standard error (commonly abbreviated stderr)
You could tell which file to log to by redirecting stderr to a specific file; for example:
jruby -J-Djruby.jit.logging=true myscript.rb 2> myfile.log
beware, however, myfile.log receives even other stderr outputs; i.e if myscript.rb
executes statements such as:
$stderr.puts "print this in stderr"
you will see "print this in stderr" in myfile.log
I am getting OOM exception (Java heap space) for reduce child. I read in the documentation that increasing the value of mapred.reduce.child.java.opts to -Xmx512M or more would help. Since I am not the admin, I cannot change that value in mapred-site.xml. I would like to set that value only for my job through the java program. I tried setting it using Configuration class as follows, but that didn't work.
Configuration config = new Configuration();
config.set("mapred.reduce.child.java.opts", "-Xmx512M");
JobConf conf1 = new JobConf(config, this.getClass());
The version of Hadoop is 1.0.3
What is the proper way of setting the configuration values programmatically?
AS #ThomasJungblut and #octo have pointed out, the procedure I mentioned in the question is the right way of doing it. The OOM exception still persists, so I would start a new thread instead of continuing here.
I'm using JOGL with to load an OBJ model and display it in a GL canvas using a VBO. Everything is work for the most part however, there are some models where the vertices must be deformed. For example, I have an arrow object and must be able to deform the stem of the arrow to make the tail as long/short as needed while maintaining the object geometry for the arrow head.
This works fine for one instance of the renderer but when I try and add another one to the scene, the system exits on the GLDrawElements call and outputs this error log. Can anyone point me in the right direction? I'm at a complete loss.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000069e3e4c8, pid=6544, tid=2692
#
# JRE version: 6.0_21-b06
# Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0-b16 mixed mode windows-amd64 )
# Problematic frame:
# C [nvoglnt.dll+0x93e4c8]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
...
Stack: [0x0000000052640000,0x0000000052740000], sp=0x000000005273ecb0, free space=3fb0000000000000000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [nvoglnt.dll+0x93e4c8]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J com.sun.opengl.impl.GLImpl.glDrawElements0(IIIJ)V
J com.sun.opengl.impl.GLImpl.glDrawElements(IIIJ)V
j com.sonogenics.model.AbstractModelHandler$Renderer.display(Ljavax/media/opengl/GL;)V+196
j com.sonogenics.model.AbstractModelHandler$Renderer.display(Ljavax/media/opengl/GL;Lcom/sonogenics/camera/SimpleProjection;FFFLcom/sonogenics/playout/Field;)V+436
...
Use GDebugger to see what call causes the error and check for invalid data in your gl calls.
It's quite awesome. :)
ACCESS_VIOLATION means you told GL to read memory that is outside the the 'good' areas :)
Within Drawelements there are a couple reasons that could be, you want to check where you setup the GL buffers as well as what you are passing into DrawElements.
-One of your buffers was a bad address, causing it to read from who
knows where
-One of your offsets, strides, were too long causing GL to go beyond the
end of an allocation
-You number of verts you said were in the model was too long... causing it
to go beyond the end of the
allocation
-Your VBO allocation wasn't large enough for the stride * number of
verts