You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Bläsing,
Matthias <mb...@doppel-helix.eu> on 2021/04/02 17:53:22 UTC
Re: NSString on M1 Mac
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
Re: NSString on M1 Mac
Posted by Bläsing,
Matthias <mb...@doppel-helix.eu>.
Please ignore this - I'm still try to align my fingers with Thunderbird.
Am 02.04.2021 um 19:53 schrieb Bläsing, Matthias:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists