Re: OS/X Java native bug
The implementation of -[ThreadUtilities performOnMainThreadWaiting:block:] does
the right thing here, which is calling the block directly if it’s already
running on the main thread:
https://github.com/openjdk/jdk/blob/9d518c528b11953b556aa7585fc69ff9c9a22435/src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m#L103.
It’s likely that your hang is caused by something else.
Saagar Jha
> On Mar 17, 2023, at 01:58, Michael Hall via Cocoa-dev
> wrote:
>
> This was just brought to my attention on a java mailing list.
>
> An option was added to java startup options on OS/X -XstartOnFirstThread so
> the code starts on the main Appkit thread.
>
> Currently if a java Swing application starts with that option it hangs.
>
> https://bugs.openjdk.org/browse/JDK-8289573
>
> This bug indicates a regression from an earlier one…
>
> https://bugs.openjdk.org/browse/JDK-7128597
>
> For apparently pretty much the same problem it suggests…
>
>> If +[NSThread isMainThread] returns true, you can simply call your
>> initializer directly, instead of punting it onto the main thread.
>
> That from a former Apple Java Swing support person. Mike Swingler.
>
> Which resulted in a fix including…
>
>> the addition of +[NSThread isMainThread] was done at Mike's suggestion
>
> I found some old code that seems to include that fix…
>
> if ([NSThread isMainThread]) {
> [GraphicsConfigUtil _getCGLConfigInfo: retArray];
> } else {
> [GraphicsConfigUtil performSelectorOnMainThread:
> @selector(_getCGLConfigInfo:) withObject: retArray waitUntilDone: YES];
> }
>
> The current code that seems to regress to the original bug now looks like…
>
> [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
>
> With what appears to be all the code that was in the selector
> _getCGLConfigInfo following in an inline block. This always appears to run on
> main thread which I think is the reverted to bug.
>
> I’m not that familiar with code including blocks. Is there some fairly easy
> way to modify this and keep it running as an inline block but also add the
> isMainThread check to not always run on the main thread?
> Or, would you have to put it back to include the check and invocation of a
> standalone selector?
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/saagar%40saagarjha.com
>
> This email sent to saa...@saagarjha.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
OS/X Java native bug
This was just brought to my attention on a java mailing list.
An option was added to java startup options on OS/X -XstartOnFirstThread so the
code starts on the main Appkit thread.
Currently if a java Swing application starts with that option it hangs.
https://bugs.openjdk.org/browse/JDK-8289573
This bug indicates a regression from an earlier one…
https://bugs.openjdk.org/browse/JDK-7128597
For apparently pretty much the same problem it suggests…
> If +[NSThread isMainThread] returns true, you can simply call your
> initializer directly, instead of punting it onto the main thread.
That from a former Apple Java Swing support person. Mike Swingler.
Which resulted in a fix including…
> the addition of +[NSThread isMainThread] was done at Mike's suggestion
I found some old code that seems to include that fix…
if ([NSThread isMainThread]) {
[GraphicsConfigUtil _getCGLConfigInfo: retArray];
} else {
[GraphicsConfigUtil performSelectorOnMainThread:
@selector(_getCGLConfigInfo:) withObject: retArray waitUntilDone: YES];
}
The current code that seems to regress to the original bug now looks like…
[ThreadUtilities performOnMainThreadWaiting:YES block:^(){
With what appears to be all the code that was in the selector _getCGLConfigInfo
following in an inline block. This always appears to run on main thread which I
think is the reverted to bug.
I’m not that familiar with code including blocks. Is there some fairly easy way
to modify this and keep it running as an inline block but also add the
isMainThread check to not always run on the main thread?
Or, would you have to put it back to include the check and invocation of a
standalone selector?
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: OS/X Java native bug
> On Mar 17, 2023, at 4:07 AM, Saagar Jha wrote: > > The implementation of -[ThreadUtilities performOnMainThreadWaiting:block:] > does the right thing here, which is calling the block directly if it’s > already running on the main thread: > https://github.com/openjdk/jdk/blob/9d518c528b11953b556aa7585fc69ff9c9a22435/src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m#L103. > It’s likely that your hang is caused by something else. > > Saagar Jha > That was already suggested but I couldn’t understand how it could be done. I’ll take it as correct with the second opinion. The stack trace seemed to indicate this as the place. Maybe something within the block. I may have to debug further. Thanks. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: OS/X Java native bug
> On Mar 17, 2023, at 6:31 AM, Michael Hall wrote:
>
>
>
>> On Mar 17, 2023, at 4:07 AM, Saagar Jha wrote:
>>
>> The implementation of -[ThreadUtilities performOnMainThreadWaiting:block:]
>> does the right thing here, which is calling the block directly if it’s
>> already running on the main thread:
>> https://github.com/openjdk/jdk/blob/9d518c528b11953b556aa7585fc69ff9c9a22435/src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m#L103.
>> It’s likely that your hang is caused by something else.
>>
>> Saagar Jha
>>
>
> That was already suggested but I couldn’t understand how it could be done.
> I’ll take it as correct with the second opinion. The stack trace seemed to
> indicate this as the place. Maybe something within the block.
> I may have to debug further.
>
> Thanks.
>
> Mike
>
Sorry, I looked at your link and am still not sure this is correct if you are
already on the main thread.
[ThreadUtilities performOnMainThreadWaiting:YES block:^(){
+ (void)performOnMainThreadWaiting:(BOOL)wait block:(void (^)())block {
if ([NSThread isMainThread] && wait == YES) {
block();
} else {
if (wait == YES) {
[self performOnMainThread:@selector(invokeBlock:) on:self
withObject:block waitUntilDone:YES];
} else {
void (^blockCopy)(void) = Block_copy(block);
[self performOnMainThread:@selector(invokeBlockCopy:) on:self
withObject:blockCopy waitUntilDone:NO];
}
}
}
Given that the code is on the main thread and wait is indicated the code blocks
correct? Until when? If it is until it is off the main thread, does that
happen? Best case, whenever it comes out of the wait it falls through without
ever attempting to run the block at all doesn’t it? Wouldn’t correct be
something like…
+ (void)performOnMainThreadWaiting:(BOOL)wait block:(void (^)())block {
if ([NSThread isMainThread] && wait == YES) {
block();
}
if (wait == YES) {
[self performOnMainThread:@selector(invokeBlock:) on:self
withObject:block waitUntilDone:YES];
} else {
void (^blockCopy)(void) = Block_copy(block);
[self performOnMainThread:@selector(invokeBlockCopy:) on:self
withObject:blockCopy waitUntilDone:NO];
}
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: OS/X Java native bug
> On Mar 17, 2023, at 6:51 AM, Michael Hall wrote: > >> > > Sorry, I looked at your link and am still not sure this is correct if you are > already on the main thread. > Searching shows this used enough places you would think it has to be correct. Again, I guess maybe I’ll try a little debugging. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: OS/X Java native bug
> On Mar 17, 2023, at 7:49 AM, Alan Snyder wrote: > > block() means invoke the block > >> On Mar 17, 2023, at 5:34 AM, Michael Hall via Cocoa-dev >> wrote: >> >> >> >>> On Mar 17, 2023, at 6:51 AM, Michael Hall wrote: >>> >>> >>> Sorry, I looked at your link and am still not sure this is correct if you >>> are already on the main thread. >>> >> Alan, Sorry for not believing you the first time. Semantics. Not what I usually think of with ‘block’. Sort of a difficult thing to pin down. What I first saw after the hang running a Panama early access for the jdk… "AWT-EventQueue-0" #14 prio=6 os_prio=31 cpu=16.71ms elapsed=5.56s tid=0x7f7fdc833400 nid=26883 runnable [0x73baf000] java.lang.Thread.State: RUNNABLE at sun.java2d.opengl.CGLGraphicsConfig.getCGLConfigInfo(java.desktop@19-panama/Native Method) at sun.java2d.opengl.CGLGraphicsConfig.getConfig(java.desktop@19-panama/CGLGraphicsConfig.java:137) at sun.awt.CGraphicsDevice.(java.desktop@19-panama/CGraphicsDevice.java:99) at sun.awt.CGraphicsEnvironment.initDevices(java.desktop@19-panama/CGraphicsEnvironment.java:169) - locked <0x00070fc0f658> (a sun.awt.CGraphicsEnvironment) I went to a current jdk 19 to maven build some of Martin’s project last night which still hangs but shows… "AWT-EventQueue-0" #21 [27907] prio=6 os_prio=31 cpu=13.40ms elapsed=3.81s tid=0x7fdb3785de00 nid=27907 runnable [0x717f5000] java.lang.Thread.State: RUNNABLE at sun.java2d.metal.MTLGraphicsConfig.tryLoadMetalLibrary(java.desktop@19.0.2/Native Method) at sun.java2d.metal.MTLGraphicsConfig.getConfig(java.desktop@19.0.2/MTLGraphicsConfig.java:140) at sun.awt.CGraphicsDevice.(java.desktop@19.0.2/CGraphicsDevice.java:78) at sun.awt.CGraphicsEnvironment.initDevices(java.desktop@19.0.2/CGraphicsEnvironment.java:169) - locked <0x00070fcf11d8> (a sun.awt.CGraphicsEnvironment) Different path same result. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
