Hi Tres,
Am 02.04.2021 um 17:20 schrieb Tres Finocchiaro:
I'm working with Dyorgio on
https://github.com/dyorgio/macos-tray-icon-fixer/issues/5
<https://github.com/dyorgio/macos-tray-icon-fixer/issues/5> and
although the code works on Intel, we cannot get it to run on M1 Macs.
The library is a stop-gap for upstream
https://github.com/openjdk/jdk/commit/400dc76f686206d17c6ff87799c10021edc146d0
<https://github.com/openjdk/jdk/commit/400dc76f686206d17c6ff87799c10021edc146d0>.
What is odd is the code seems to segfault simply constructing an
NSString
<https://github.com/dyorgio/macos-tray-icon-fixer/blob/main/src/main/java/dyorgio/runtime/macos/trayicon/fixer/jna/foundation/NSString.java>.
I was wondering if anyone on the mailing list had a working NSString
class for the new M1 architecture or knowledge of a bug working with
this architecture?
Random segfaults could be problems in libffi or the bindings - or in the
GC. See here:
https://github.com/dyorgio/macos-tray-icon-fixer/blob/53702e10f45984a6145cd18edf87af22e92b912d/src/main/java/dyorgio/runtime/macos/trayicon/fixer/jna/foundation/NSDictionary.java#L43-L45
At that point the id of the NSString is extracted from the surrounding
object. If nothing else holds a strong reference to the NSString, the
object becomes eligible for GC at that point (with some hotspot magic
even earlier). When GC kicks in NSObject#finalize is invoked, which I
assume will deallocate the string. As GC settings have the tendency to
be highly architecture and JDK build specific, this could explain the
different observed behavior.
On JDK 9+ you can use Reference#reachabilityFence to prevent GC of the
object. For older JDKs you could stuff the object into a static holder.
Greetings
Matthias
