In hotspot/src/share/vm/utilities/exceptions.hpp, there's some code:
// The THREAD & TRAPS macros facilitate the declaration of functions that throw exceptions.
// Convention: Use the TRAPS macro as the last argument of such a function; e.g.:
//
// int this_function_may_trap(int x, float y, TRAPS)
#define THREAD __the_thread__
#define TRAPS Thread* THREAD
The THREAD macro only use for throw an exception:
// The THROW... macros should be used to throw an exception. They require a THREAD variable to be
// visible within the scope containing the THROW. Usually this is achieved by declaring the function
// with a TRAPS argument.
#define THREAD_AND_LOCATION THREAD, __FILE__, __LINE__
#define THROW_OOP(e) \
{ Exceptions::_throw_oop(THREAD_AND_LOCATION, e); return; }
#define THROW_HANDLE(e) \
{ Exceptions::_throw(THREAD_AND_LOCATION, e); return; }
// the real place to use __the_thread__ macro
void Exceptions::_throw(Thread* thread, const char* file, int line, Handle h_exception, const char* message) {......}
However, I use grep to search all OpenJDK8's code, only to find there's only one place here has this __the_thread__ macro.
Can someone tell me what does the real macro define?
__the_thread__ here is the name of a variable or rather an argument to VM functions that may throw an exception. It is always accessed through a THREAD or TRAPS macro, that's why there are no other references, and the real name of the variable does not matter.
For example, the definition
jint find_field_offset(jobject field, int must_be_static, TRAPS)
is expanded by preprocessor to
jint find_field_offset(jobject field, int must_be_static, Thread* __the_thread__)
Related
have been strugling with this over 2 days, I am not very skilled in C. So, have an objc function mapped to C function with the following syntax
extern int32_t createWallet(void (*fn)(int32_t handle, int32_t errCode)
but dont know how to pass a block like function. Have been trying to pass
void (^ createWalletCallback)(int32_t t, int32_t e) = NULL;
createWalletCallback = ^void(int32_t t, int32_t e){
/// some code here
}
but no success. Could you pls at least point me what to change? Thanks
This seems to be a duplicate of Is there a way to wrap an ObjectiveC block into function pointer?, where the advice is "don't do it".
Instead, can you not use a plain C function pointer? Define a function
void createWalletCallback(int32_t t, int32_t e) {
// some code here, maybe referencing global variables
// (including a semaphore, if other code needs to wait on the response)
}
and then just call
createWallet(&createWalletCallback);
TL;DR: Does the __block attribute on an std::vector prevent RVO in Objective-C++?
In Modern C++, the canonical way to return a vector from a function is to just return it by value so that return value optimization can be used if possible. In Objective-C++, this appears to work the same way.
- (void)fetchPeople {
std::vector<Person> people = [self readPeopleFromDatabase];
}
- (std::vector<Person>)readPeopleFromDatabase {
std::vector<Person> people;
people.emplace_back(...);
people.emplace_back(...);
// No copy is made here.
return people;
}
However, if the __block attribute is applied to the second vector, then it appears that a copy of the vector is being created when it returns. Here is a slightly contrived example:
- (std::vector<Person>)readPeopleFromDatabase {
// __block is needed to allow the vector to be modified.
__block std::vector<Person> people;
void (^block)() = ^ {
people.emplace_back(...);
people.emplace_back(...);
};
block();
#if 1
// This appears to require a copy.
return people;
#else
// This does not require a copy.
return std::move(people);
#endif
}
There are plenty of Stack Overflow questions that explicitly state that you don't need to use std::move when returning a vector because that will prevent copy elision from taking place.
However, this Stack Overflow question states that there are, indeed, some times when you do need to explicitly use std::move when copy elision is not possible.
Is the use of __block in Objective-C++ one of those times when copy elision is not possible and std::move should be used instead? My profiling appears to confirm that, but I'd love a more authoritative explanation.
(This is on Xcode 10 with C++17 support.)
I don't know about authoritative, but a __block variable is specifically designed to be able to outlive the scope it's in and contains special runtime state that tracks whether it's stack- or heap-backed. For example:
#include <iostream>
#include <dispatch/dispatch.h>
using std::cerr; using std::endl;
struct destruct_logger
{
destruct_logger()
{}
destruct_logger(const destruct_logger& rhs)
{
cerr << "destruct_logger copy constructor: " << &rhs << " --> " << this << endl;
}
void dummy() {}
~destruct_logger()
{
cerr << "~destruct_logger on " << this << endl;
}
};
void my_function()
{
__block destruct_logger logger;
cerr << "Calling dispatch_after, &logger = " << &logger << endl;
dispatch_after(
dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * NSEC_PER_SEC)), dispatch_get_main_queue(),
^{
cerr << "Block firing\n";
logger.dummy();
});
cerr << "dispatch_after returned: &logger = " << &logger << endl;
}
int main(int argc, const char * argv[])
{
my_function();
cerr << "my_function() returned\n";
dispatch_main();
return 0;
}
If I run that code, I get the following output:
Calling dispatch_after, &logger = 0x7fff5fbff718
destruct_logger copy constructor: 0x7fff5fbff718 --> 0x100504700
dispatch_after returned: &logger = 0x100504700
~destruct_logger on 0x7fff5fbff718
my_function() returned
Block firing
~destruct_logger on 0x100504700
There's quite a lot happening here:
Before we call dispatch_after, logger is still stack-based. (0x7fff… address)
dispatch_after internally performs a Block_copy() of the block which captures logger. This means the logger variable must now be moved to the heap. As it's a C++ object, this means the copy constructor is invoked.
And indeed, after dispatch_after returns, &logger now evaluates to the new (heap) address.
The original stack instance of course must be destroyed.
The heap instance is only destroyed once the capturing block has been destroyed.
So a __block "variable" is actually a much more complex object that can move around in memory on demand behind the scenes.
If you were to subsequently return logger from my_function, RVO wouldn't be possible, because (a) it now lives on the heap, not the stack, and (b) not making a copy on returning would allow mutation of the instance captured by blocks.
I guess it might be possible to make it runtime state dependent - use RVO memory for stack-backing, then if it gets moved to the heap, copy back into the return value when the function returns. But this would complicate functions that operate on blocks, as the backing state would now need to be stored separately from the variable. It also seems like overly complex and surprising behaviour, so I'm not surprised that RVO doesn't happen for __block variables.
I found an block example in the book "Effective Objective-C 2.0"
void (^block)();
if (/* some condition */) {
block = ^ {
NSLog(#"Block A");
};
} else {
block = ^ {
NSLog(#"Block B");
};
}
block();
The code is dangerous, and here is the explanation in the book:
The two blocks that are defined within the if and else statements are allocated within stack memory. When it allocates stack memory for each block, the compiler is free to overwrite this memory at the end of the scope in which that memory was allocated. So each block is guaranteed to be valid only within its respective if-statement section. The code would compile without error but at runtime may or may not function correctly. If it didn’t decide to produce code that overwrote the chosen block, the code would run without error, but if it did, a crash would certainly occur.
I don't understand the meaning of "If it didn’t decide to produce code that overwrote the chosen block, the code would run without error, but if it did, a crash would certainly occur."
Can someone explain and give examples?
The issue is similar to that of a C array being created locally to a function and then used after the function returns:
#import <Foundation/Foundation.h>
dispatch_block_t global_block;
int * global_arr;
void set_globals(void)
{
if( YES ){
global_block = ^{
NSLog(#"Summer is butter on your chin and corn mush between every tooth.");
};
int arr[5] = {1, 2, 3, 4, 5};
global_arr = arr;
}
}
void write_on_the_stack(int i)
{
int arr[5] = {64, 128, 256, 512, 1024};
int v = arr[3];
dispatch_block_t b = ^{
int j = i + 10;
j += v;
};
b();
}
int main(int argc, const char * argv[])
{
#autoreleasepool {
set_globals();
write_on_the_stack();
global_block();
NSLog(#"%d", global_arr[0]); // Prints garbage
}
return 0;
}
The space on the stack that was used to store the values of the array may be re-used for any purpose. I use the separate function here because it most reliably demonstrates the problem. For your exact case, with the if block and the access in the same function, the compiler is still free to re-use the stack space. It may not, but you can't rely on that. You're breaking the scope rules of the language (derived from C).
As Jesse Rusak and CrimsonChris pointed out in comments, though, with a Block-type variable compiled under ARC, the Block is created on the stack like the array, but copied off the stack (to the heap) when it's stored in a strong pointer. All object pointers, including your global, are strong by default.
If you were not compiling with ARC, this would be unreliable. I can't come up with a failing example with my current compiler, but again, it's breaking the rules and the compiler is under no obligation to do what you want.
Essentially what this is saying is that if there's code running on a separate thread, and something gets assigned to the area of memory currently used by block but before the block() call, then bad things will happen.
void (^block)();
if (/* some condition *)) {
block = ^ {
NSLog(#"Block A");
}
} else {
block = ^ {
NSLog(#"Block B");
}
}
<--- another thread overwrites the **block** block
block(); <--- runtime error since **block** has been dereferenced.
Sup guys,
I'm trying to do a function that calls itself but by putting everything on one block,
As you can see, the following function is intended to be called an indefinite amount of times (until arcrandom returns a number lower than 50) and you should expect as an output a variable number of "RUNNING" messages, depending on chance.
void (^_test_closure)(void) = ^ {
NSLog(#"RUNNING");
if(arc4random() % 100 > 50) {
_test_closure();
}
};
_test_closure();
However, when running it, I get an EXC_BAD_ACCESS error and the reason I've found is that when the code tries to calls _test_closure inside of the closure it basically points to nowhere.
Does anyone know how to make the above code work?
You have to declare your block itself as a block variable:
__block void (^_test_closure)();
_test_closure = ^{
NSLog(#"Running...");
if ((arc4random() % 100) > 50) {
_test_closure();
}
}
_test_closure();
Recursion and blocks is tricky. Because a block captures all variables passed in, the variable _test_closure is not initialized yet (and clang should give you a warning:
Block pointer variable '_test_closure' is uninitialized when captured by block
).
There are several ways you can get around this, but the most obvious & simplest is to just make the block itself a __block variable (what #H2CO3 said). This allows the block to be weak-linked almost, so that when you call it again, it is properly initialized.
Another option you have is making the block a global or static, like this:
// outside of 'main', thus being a global variable
void (^blockRecurse)(int) = ^(int level) {
if (level < 0)
return;
NSLog(#"Level: %i", level);
blockRecurse(--level);
};
int main()
{
#autoreleasepool {
blockRecurse(10);
}
}
This means it's not being captured by the block, but instead it's referencing the global / static variable, which can be changed by all code equally.
It works with XCode 5 - no warnings, no retain cycles:
typedef void(^blockT)();
blockT block1;
blockT __block block1recursive;
block1recursive = block1 = ^(){
block1recursive();
};
block1();
I am trying to write some code that interacts with an USB device in Objective C, and I got stuck on setting the callback function for incoming reports. In my case it's an IOKIT function but I think the problem is more general as I (apparently) don't know how to correctly set a C callback function in Objective-C. I've got a Class "USBController" that handles the io functions
USBController.m:
#include <CoreFoundation/CoreFoundation.h>
#include <Carbon/Carbon.h>
#include <IOKit/hid/IOHIDLib.h>
#import "USBController.h"
static void Handle_IOHIDDeviceIOHIDReportCallback(
void * inContext, // context from IOHIDDeviceRegisterInputReportCallback
IOReturn inResult, // completion result for the input report operation
void * inSender, // IOHIDDeviceRef of the device this report is from
IOHIDReportType inType, // the report type
uint32_t inReportID, // the report ID
uint8_t * inReport, // pointer to the report data
CFIndex InReportLength) // the actual size of the input report
{
printf("hello"); //just to see if the function is called
}
#implementation USBController
- (void)ConnectToDevice {
...
IOHIDDeviceRegisterInputReportCallback(tIOHIDDeviceRefs[0], report, reportSize,
Handle_IOHIDDeviceIOHIDReportCallback,(void*)self);
...
}
...
#end
All the functions are also declared in the header file.
I think I did pretty much the same as what I've found here, but it doesn't work. The project compiles nicely and everything works up till the moment there is input and the callback function is to be called. Then I get an "EXC_BAD_ACCESS" error. The first three arguments of the function are correct. I'm not so sure about the context..
What did I do wrong?
I am not sure at all that your EXEC_BAD_ACCESS depends on your callback. Indeed, if you say that it is called (I suppose you see the log) and since it only logs a message, there should be no problem with this.
EXEC_BAD_ACCESS is caused by an attempt to access an already deallocated object. You can get more information in two ways:
execute the program in debug mode, so when it crashes you will be able to see the stack content;
activate NSZombies or run the program using the performance tool Zombies; this will tell you exactly which object was accessed after its deallocation.
I know how to fix this. When calling this:
IOHIDDeviceRegisterInputReportCallback(tIOHIDDeviceRefs[0], report, reportSize,
Handle_IOHIDDeviceIOHIDReportCallback,(void*)self);
You don't include the code for the creation/type of the value called report. However the method name "Handle_IOHIDDeviceIOHIDReportCallback" comes from an Apple document where there is an error in the creation of the report value. https://developer.apple.com/library/archive/technotes/tn2187/_index.html
CFIndex reportSize = 64;
uint8_t report = malloc( reportSize ); // <---- WRONG
IOHIDDeviceRegisterInputReportCallback( deviceRef,
report,
reportSize,
Handle_IOHIDDeviceIOHIDReportCallback,
context );
Instead do this:
uint8_t *report = (uint8_t *)malloc(reportSize);