Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JBR-6696: hardened MTLGC_DestroyMTLGraphicsConfig #301

Closed
wants to merge 1,012 commits into from
Closed

Conversation

bourgesl
Copy link
Contributor

to ensure any aync callbacks are performed before deallocation, added CVDisplayLink checks, traces and refactored cleanup code + fixed review comments

@bourgesl
Copy link
Contributor Author

Will fix PR asap

@avu
Copy link
Collaborator

avu commented Feb 14, 2024

Did you check for freezes that happened with the previous version?

@bourgesl
Copy link
Contributor Author

Yes I am testing my patch ...

@bourgesl
Copy link
Contributor Author

(WIP) tests in progress...
still annoying trouble with (not direct surface) when scaling factor are changed and new frame created...

@@ -39,6 +39,10 @@
// scenarios with multiple subsequent updates.
#define KEEP_ALIVE_COUNT 4

// Min interval between 2 display link callbacks (Main thread may be blocked)
// ~ 2ms (shorter than 240Hz frame time)
#define KEEP_ALIVE_MIN_INTERVAL 2.0 / 1000.0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rephrase it in terms of FPS because it seems to better describe this restriction. Something like

#define MAX_FPS 240
#define KEEP_ALIVE_MIN_INTERVAL 1.0/MAX_FPS

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it seems possible to query monitor capabilities at runtime on recent macos, so yes, max_freq or fps is important as new monitors can achieve 480hz...
Here I just want to discard old callbacks ... postponed by busy main thread, then flushed at once...
Will look at cvtime ...

setenv("MTC_PRINT_SELECTOR_STATS", "1", 1);
}

void *result = dlopen("/Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to provide the path via JVM option

timebase = malloc(sizeof (mach_timebase_info_data_t));
mach_timebase_info(timebase);

printf("timebase->numer: %d\n", timebase->numer);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's better to use J2D runtime trace here (J2dRls...)

} else {
if (wait && isEventDispatchThread()) {
void (^blockCopy)(void) = Block_copy(^(){
if (!DECORATE_MAIN_THREAD) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use DECORATE_MAIN_THREAD as a macro so it's better to replace the if statement with the preprocessor IF or maybe enable it always in DEBUG mode.

@bourgesl bourgesl force-pushed the lbourges/JBR-6696 branch 5 times, most recently from e1b7ca0 to 5c43c86 Compare February 28, 2024 18:54
@bourgesl
Copy link
Contributor Author

New PR opened: #383

@vprovodin vprovodin force-pushed the main branch 6 times, most recently from 5a08a7a to 8934056 Compare May 24, 2024 00:03
@bourgesl bourgesl closed this May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet