java 17.0.3 with zgc
-Xms8g -Xmx8g -XX:SoftMaxHeapSize=7500m -XX:ConcGCThreads=4 -XX:-UseDynamicNumberOfGCThreads -XX:+UseZGC
[516623.420s][info][gc,task ] GC(50947) Using 4 workers
[516626.249s][info][gc,phases] GC(50947) Pause Mark Start 2829.801ms
[516626.418s][info][gc,phases] GC(50947) Concurrent Mark 168.389ms
[516626.418s][info][gc,phases] GC(50947) Pause Mark End 0.040ms
[516626.418s][info][gc,phases] GC(50947) Concurrent Mark Free 0.001ms
[516626.457s][info][gc,phases] GC(50947) Concurrent Process Non-Strong References 38.371ms
[516626.457s][info][gc,phases] GC(50947) Concurrent Reset Relocation Set 0.057ms
[516626.460s][info][gc,phases] GC(50947) Concurrent Select Relocation Set 2.591ms
[516626.460s][info][gc,phases] GC(50947) Pause Relocate Start 0.021ms
[516626.462s][info][gc,phases] GC(50947) Concurrent Relocate 2.486ms
[516626.462s][info][gc,ref ] GC(50947) Soft: 2038 encountered, 284 discovered, 0 enqueued
[516626.462s][info][gc,ref ] GC(50947) Weak: 26751 encountered, 2023 discovered, 0 enqueued
[516626.462s][info][gc,ref ] GC(50947) Final: 150 encountered, 2 discovered, 0 enqueued
[516626.462s][info][gc,ref ] GC(50947) Phantom: 454 encountered, 396 discovered, 0 enqueued
[516626.462s][info][gc,reloc ] GC(50947) Small Pages: 1135 / 2270M, Empty: 1350M, Relocated: 3M, In-Place: 0
[516626.462s][info][gc,reloc ] GC(50947) Medium Pages: 1 / 32M, Empty: 0M, Relocated: 0M, In-Place: 0
[516626.462s][info][gc,reloc ] GC(50947) Large Pages: 0 / 0M, Empty: 0M, Relocated: 0M, In-Place: 0
[516626.462s][info][gc,reloc ] GC(50947) Forwarding Usage: 0M
[516626.462s][info][gc ] GC(50947) Garbage Collection (Proactive) 2302M(28%)->546M(7%)
What scenario will cause this phenomenon?
Related
I'm having trouble understanding the difference between Kotlin ticker channel TickerMode.FIXED_DELAY and TickerMode.FIXED_PERIOD. I've played with both, but I'm unable to draw inferences from their behavior. I've also read the example in the docs. I would be grateful for a clearer explanation, with an illustration of each.
As you can find in coroutines sources the difference is that FIXED_PERIOD is more sophisticated and gets into account the fact the receiver cannot keep up and adjust the delay before next invocations of send. This can be tricky to demonstrate though, because you need to measure time a receiver spends waiting for a next tick.
P.S. Note that this functionality is marked as obsolete, i.e. "the design of the corresponding declarations has serious known flaws and they will be redesigned in the future." In this case the reason is that it isn't integrated with structured concurrency.
fun main() = runBlocking {
println("\nFIXED_PERIOD")
val tickerPeriodMode = ticker(100, 0, mode = TickerMode.FIXED_PERIOD)
consumer(tickerPeriodMode)
println("\nFIXED_DELAY")
val tickerDelayMode = ticker(100, 0, mode = TickerMode.FIXED_DELAY)
consumer(tickerDelayMode)
}
private suspend fun CoroutineScope.consumer(ticker: ReceiveChannel<Unit>) {
val job = launch {
var i = 0
while (isActive) {
val waitTime = measureTimeMillis {
ticker.receive()
}
print("[%4d ms]".format(waitTime))
if (i++ == 1) {
delay(150)
println(" adding extra 150ms delay")
} else
println(" going ahead")
}
}
delay(1_000L)
job.cancel()
ticker.cancel() // indicate that no more elements are needed
}
Output
FIXED_PERIOD
[ 1 ms] going ahead
[ 91 ms] adding extra 150ms delay
[ 0 ms] going ahead
[ 46 ms] going ahead
[ 100 ms] going ahead
[ 102 ms] going ahead
[ 98 ms] going ahead
[ 100 ms] going ahead
[ 99 ms] going ahead
[ 100 ms] going ahead
[ 100 ms] going ahead
FIXED_DELAY
[ 0 ms] going ahead
[ 105 ms] adding extra 150ms delay
[ 0 ms] going ahead
[ 101 ms] going ahead
[ 100 ms] going ahead
[ 103 ms] going ahead
[ 103 ms] going ahead
[ 101 ms] going ahead
[ 101 ms] going ahead
[ 105 ms] going ahead
I want to use for http://www.rebol.com/docs/words/wfor.html
for Red it doesn't work.
What's the equivalent ?
As for in Rebol2 is just a mezzanine, you can write your own for
for: func [
"Repeats a block over a range of values."
[catch throw]
'word [word!] "Variable to hold current value"
start [number! series! time! date! char!] "Starting value"
end [number! series! time! date! char!] "Ending value"
bump [number! time! char!] "Amount to skip each time"
body [block!] "Block to evaluate"
/local result do-body op
][
if (type? start) <> (type? end) [
throw make error! reduce ['script 'expect-arg 'for 'end type? start]
]
do-body: func reduce [[throw] word] body
op: :greater-or-equal?
either series? start [
if not same? head start head end [
throw make error! reduce ['script 'invalid-arg end]
]
if (negative? bump) [op: :lesser?]
while [op index? end index? start] [
set/any 'result do-body start
start: skip start bump
]
if (negative? bump) [set/any 'result do-body start]
] [
if (negative? bump) [op: :lesser-or-equal?]
while [op end start] [
set/any 'result do-body start
start: start + bump
]
]
get/any 'result
]
but you can find also a few mightier or more c-syntax-like versions on the net e.g. a proposal for Rebol3
cfor: func [ ; Not this name
"General loop based on an initial state, test, and per-loop change."
init [block! object!] "Words & initial values as object spec (local)"
test [block!] "Continue if condition is true"
bump [block!] "Move to the next step in the loop"
body [block!] "Block to evaluate each time"
/local ret
] [
if block? init [init: make object! init]
test: bind/copy test init
body: bind/copy body init
bump: bind/copy bump init
while test [set/any 'ret do body do bump get/any 'ret]
]
Red also offers the possibility to define your own macro and compile it.
I have a Rebol2 console app (Rebol Core) which I would like to disable the keyboard character echo to the console. The app is run from a minimal Linux kernel/initramfs, and is started by busybox inittab (not from terminal). It has a minimal console user interface using ansi codes for color, etc., and responds to menu selections via single key presses. To 'quiet' the console, I have the cursor turned off, and don't see the output of the key presses (until recently).
I previously thought I had the problem solved by calling 'stty -echo' within Rebol, but it actually does not work as I just discovered- there is one function that takes 5-10 seconds and can see the echoed key presses while waiting for the function to complete.
I'm not quite sure why I only see the echoed characters while this one function is running, but it is the only function which takes any amount of time. The keyboard is polled by opening the console:// in binary mode, waiting for a key press, then a switch statement to choose the function. The reading of the keys in binary/console seem to 'consume' the key echo-
minimal example, pressing 'a'-
cons: open/binary console://
first cons
== 97
(the value is returned as I want, and the char is not echoed, which is good- I think in most functions my keys are 'consumed' in the get-key loop, but the longer function does not get a chance to 'consume' them, and end up echoing to the console)
Is there some way to disable the console character echo inside Rebol2? I have looked in system/console and system/ports/input,output, but don't see anything obvious. My current workaround is to simply change the text color to match the background so any key presses are not visible while the specific function runs.
here is a minimal example of what I'm doing-
get-key: func [ /local cons ch ][
cons: open/binary console://
ch: lowercase to-string to-char first cons
all [ equal? ch "^[" append ch copy/part cons 2 ]
close cons
ch
]
forever [
switch get-key [
;up arrow
"^[[A" [ some-function1 ]
;down arrow
"^[[B" [ some-function2 ]
;enter
"^M" [ some-function3 ]
;quit
"q" [ break ]
]
]
The forever loop seems to 'consume' the keyboard input (nothing echoed), but if one of the functions takes any amount of time, any keyboard input will get echoed to the screen wherever the cursor happens to be. In most cases I never see any echoed characters as the time between calling get-key is minimal. I would also note that the echoed characters do not also show up in the subsequent call to get-key.
update-
here is a better sample of code to see the problem-
get-key: has [ cons ch ][
cons: open/binary console://
ch: lowercase to-string to-char first cons
prin rejoin [ "<" ch ">" ] ;show get-key chars
ch
]
long-func: does [ call/wait {sleep 10} ]
reb-func: does [ wait 10 ]
forever [
switch get-key [
"f" [ long-func ]
"r" [ reb-func ]
"q" [ break ]
]
]
I figured out that my 'long' function is using call's which can take a few seconds, so the problem arises when a call is used.
The above code, when run will show that keys are echoed only because they are printed in the get-key function (brackets), when the long-func is running, then keys are echoed outside of get-key (no brackets), and when done the get-key will process those keys also. Or simply run 'call/wait {sleep 10}' and you will get echoed keys while waiting, and also get the sames keys echoed by Rebol when the call returns. Keys are not echoed when reb-func runs, and get-key will process all buffered keys when reb-func is done. The keyboard input is being handled twice when call is used.
I have tried redirecting stdin/stdout in the call command (in the call string command, like at bash prompt), but have not found a combo that works. (My actual code runs call with /output/error to capture all output).
Without optimizing your code with waiting on the port and an awake function I guess your problem can be solved by placing opening and closing the console port outside your get-key function as in
get-key: func [ /local ch ][
ch: lowercase to-string to-char first cons
all [ equal? ch "^[" append ch copy/part cons 2 ]
ch
]
cons: open/binary [scheme: 'console]
forever [
switch get-key [
;up arrow
"^[[A" [ some-function1 ]
;down arrow
"^[[B" [ some-function2 ]
;enter
"^M" [ some-function3 ]
;quit
"q" [ break ]
]
]
close cons
ok, here is an optimized version including your second example
long-func: does [ call/wait {stty -echo ; sleep 10} ]
reb-func: does [ wait 10 ]
cons: open/binary [scheme: 'console]
cons/awake: func [port] [
key: to-char first port
print ["<" key ">"]
switch key [
#"f" [long-func]
#"r" [reb-func]
#"q" [break]
]
]
forever [
wait [cons]
]
you can see, that all keys are catched without extra echo
The rearranged console code is not necessary (and all keys are cached no matter which arrangement is used), although the ability to add an awake function is nice to know. In my real code, the get-key has a '/timeout t' option where I can do a 'wait [ cons t ]' and return a string (for extended key codes like up arrow) or none, which means I can also flush the console input before my switch get-key (so any keys pressed while running functions get flushed).
forever [
while [ get-key/timeout 0.1 ][] ;flush
switch get-key [ ;wait for key
...
The 'stty -echo' works well in the example given, and would seem to solve my problem, but I still see a few characters echoed if I press a bunch of keys while the long functions are running (I inserted {stty -echo; } in all commands). Somehow, in the Rebol call creating of processes (fork/exec I assume), tty input/output can still 'leak' i/o characters. Or maybe one of the programs called is opening a tty even though it inherits the file descriptors of the parent.
Here is what I ended up doing- changing the way I call commands so they run in background, but still wait for them to complete.
;used by other funcs to parse output of commands
set 'cmd-output "" ;output from 'call' commands
set 'cmd-error "" ;error from 'call commands
set 'cmd func [ str [string!] /local ret ][
--old--
;clear previous
cmd-output: copy ""
cmd-error: copy ""
;--new--
write %out ""
write %err ""
attempt [ delete %ret ]
;--old--
;ret: call/wait/output/error str cmd-output cmd-error
;--new-- stdout->out stderr->err exitcode->ret
call rejoin [ str { >out 2>err; echo -n $? > ret} ]
;wait for return code, (up to 20 seconds, should be plenty)
loop 200 [ all [ exists? %ret break ] wait 0.1 ]
cmd-output: read %out
cmd-error: read %err
ret: to-integer read %ret
--old--
;debug-cmd writes info to a logfile
debug-cmd str ret
ret
]
This works, as I cannot get any (unwanted) characters to show on the screen as before (and I guess it proves those characters were coming from the called processes).
Example:
st> [ fnord := 7 ] value
I was always under the impression that they went into the SystemDictionary at Smalltalk, but that's not true:
st> [ fnord := 7 ] value
st> Smalltalk at: #fnord
Object: SystemDictionary new: 512 "<0x2acfca382030>" error: Invalid argument #fnord: key not found
However, at least on GNU Smalltalk, the values seem to be persisted somewhere --- accessing fnord returns the right value:
st> [ fnord := 7 ] value
st> fnord
7
Update: I figured out how to disassemble blocks! It's really hard.
st> [ fnord := 7 ] block inspect
An instance of CompiledBlock
header: 32768
clean-ness flags: 0
number of arguments: 0
number of temporaries: 0
number of literals: 4
needed stack slots: 8
method: UndefinedObject>>executeStatements
literals: [
[1] {fnord}
[2] a BlockClosure
[3] #block
[4] #inspect
]
byte codes: [
[1] source code line number 1
[3] push 7
[5] store into Global Variable {fnord}
[7] pop stack top
push Global Variable {fnord}
[9] return stack top
]
[] in UndefinedObject>>executeStatements
So it definitely thinks it's writing to a global variable.
Undeclared variable bindings go into a global dictionary named Undeclared. That binding (a key->value pair) gets moved to Smalltalk once you properly declare it. This is how forward-references are resolved when loading code, for example. That is, when a variable is used before the code declaring it is loaded.
Developing an app for OSX. There's still bugs and it crashes in release builds.
However, it runs in debug builds, when there's a blank NSLog statement in a few spots. If the NSLog statements are removed, the app crashes on run.
The first statement, in a run loop (prints calculated ticks and drawn frames, it simulates a fluid in an NSView)
NSLog(#"%d ticks, %d frames", ticks, frames);
The second statement, in the tick method that gets called every loop,
NSLog(#"");
In debug mode, running from Xcode, it works just fine with these two statements. If either is removed, it crashes. After several hours searching, I can't find any reference to apps crashing without blank NSLog statements.
Edit: The final question is: Is there anything I should look out for that might be causing this?
Edit 2: The run and tick methods are
-(void) run {
timeval start = gettime();
timeval end = gettime();
float dt = 1./60;
self.E.dt = dt;
float tick = 1e6*dt;
float unprocessed;
int ticks = 0;
int frames = 0;
timeval now;
while ( TRUE ) {
now = gettime();
unprocessed += diff(end, now)/tick;
end = now;
BOOL shouldRender = true; // set false to limit framerate to tickrate
while ( unprocessed >= 1 ) {
ticks++;
[self tick];
unprocessed -= 1;
shouldRender = true;
}
if ( shouldRender ) {
frames++;
}
if ( diff(start, gettime()) > 1000000 ) {
start.tv_sec += 1;
NSLog(#"%d ticks, %d frames", ticks, frames);
frames = 0;
ticks = 0;
}
}
}
-(void) tick {
NSLog(#"");
NSDictionary* fs = [NSDictionary dictionaryWithObjectsAndKeys:self.u, #"u", self.v, #"v", self.p, #"p", self.T, "#T", nil];
NSDictionary* gs = [self.E evolve:fs];
[self.u swap:[gs objectForKey:#"u"]];
[self.v swap:[gs objectForKey:#"v"]];
[self.p swap:[gs objectForKey:#"p"]];
[self.T swap:[gs objectForKey:#"T"]];
[self.view setNeedsDisplay:YES];
}
Edit 3: This is clearly an issue with LLVM. When I compile with GCC, I get no crash. Unfortunately there's an extraordinary amount of memory leaks now due to no ARC. Confusion level increased.
Edit 4: Backtrace
Crashed Thread: 2
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000010
External Modification Warnings:
Debugger attached to process.
VM Regions Near 0x10:
-->
__TEXT 0000000103a9b000-0000000103a9c000 [ 4K] r-x/rwx SM=COW /Users/USER/Library/Developer/Xcode/DerivedData/Splash-ahjwbarsbqqbuzfcnxstxpslekdi/Build/Products/Debug/Splash.app/Contents/MacOS/Splash
Application Specific Information:
objc_msgSend() selector name: copy
objc[32100]: garbage collection is OFF
Thread 2 Crashed:
0 libobjc.A.dylib 0x00007fff8e43ee90 objc_msgSend + 16
1 com.apple.CoreFoundation 0x00007fff87edf8ac -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 668
2 com.apple.CoreFoundation 0x00007fff87efcd13 +[NSDictionary dictionaryWithObjectsAndKeys:] + 1203
3 com.mbarriault.Splash 0x0000000103a9d488 -[Game tick] + 328 (Game.m:95)
4 com.mbarriault.Splash 0x0000000103a9d2a9 -[Game run] + 361 (Game.m:76)
5 com.apple.Foundation 0x00007fff9020874e -[NSThread main] + 68
6 com.apple.Foundation 0x00007fff902086c6 __NSThread__main__ + 1575
7 libsystem_c.dylib 0x00007fff8dba18bf _pthread_start + 335
8 libsystem_c.dylib 0x00007fff8dba4b75 thread_start + 13
Thread 2 crashed with X86 Thread State (64-bit):
rax: 0x0000000103aa5a00 rbx: 0x0000000000000004 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000103aa3071 rsi: 0x00007fff8f9ea7d0 rbp: 0x0000000107b47970 rsp: 0x0000000107b47900
r8: 0x0000000000000004 r9: 0x0000000103aa5ab0 r10: 0x0000000000000001 r11: 0x0000000000000000
r12: 0x0000000000000003 r13: 0x0000000107b47928 r14: 0x0000000107b479a0 r15: 0x0000000107b47980
rip: 0x00007fff8e43ee90 rfl: 0x0000000000010202 cr2: 0x0000000000000010
Logical CPU: 3
I removed ID information and the logs for threads that didn't crash, as the whole log went over the post length limit.
Edit 5: Changing the dictionary creation from NSDictionary:dictionaryWithObjectsAndKeys: to NSDictionary:dictionaryWithObjects:forKeys: seems to have fixed all my problems. I'm not entirely certain why, but I'll take it! Thanks everyone!
Edit 6: The correct answer, believe if you will, was a simple typo in a string.
From the look of the backtrace it is crashing when allocating the NSDictionary. Probably one of the object references being used to initialize the NSDictionary is invalid. If you post code from the tick method it could help narrow down what the problem is. Also, if you try debugging with NSZombie on it could tell us which object type it is crashing on.
Edit:
OK. Now that I see the tick code, I can see the problem. I didn't see it at first, but you are using the c-string "#T", which you probably intended to be #"T".