Finished part 1 of the Wayland McWayface tutorial of Drew DeVault - Issue with spi toolprovider interface and jextract

[Maurizio Cimadamore]

On 26/02/2019 19:20, Mark Hammons wrote:
> Probably. I don't know if it's the reason the tool provider isn't 
> working though, I'll have to test that later. In other news, I was 
> testing the power consumption of my implementation vs the original c 
> implementation of this software (with some minor tweaks since the 
> wlroots library has had incompatible changes since this software was 
> published), and the jvm implementation isn't super far off the 
> original. It uses 2x the power on average, and when I look at what's 
> going on with visualvm it says most of the time spent is on native 
> callbacks  (not entirely surprising since one of the callbacks is 
> called 60 times per second or more).
>
> I would assume that the foreign interface is still not fully 
> optimized? If it isn't, that seems like pretty great news cause it's 
> already performing very well. If it is, well, it's still pretty 
> promising.

Heh - your assumption is correct, upcalls is the least optimized code 
path (if you are on Windows, downcalls aren't great either - but I think 
you're on Linux, given the header you're working on :-)).

See this:

https://youtu.be/cfxBrYud9KM?t=1759

Where I talk a bit about the current status of Panama performance and 
possible further developments; in case you are interested, since I gave 
that talk, we actually have a branch with all the performance work - 
called "foreign+linkToNative", so that could be a way to get an idea of 
what's coming.

Maurizio


>
> ~Mark
>
> On 2/26/19 12:16 AM, Maurizio Cimadamore wrote:
>> Could you be experiencing this?
>>
>> https://github.com/scala/bug/issues/11381
>>
>> The problem reported by SBT looks the same, and it's JDK 12-related.
>>
>> Maurizio
>>
>> On 25/02/2019 21:25, Maurizio Cimadamore wrote:
>>> That doesn't look good.
>>>
>>> I suggest you try to Java-ize your example and try again. If that 
>>> works, then we're looking at an issue which could be caused by some 
>>> incompatibility between sbt and the Panama JDK (e.g. does sbt 
>>> support classfiles of that version number?) or, possibly, some more 
>>> obscure bug in the Panama JDK.
>>>
>>> Maurizio
>>>
>>> On 25/02/2019 20:51, Mark Hammons wrote:
>>>> I gave it a shot, and changed my setProperty to a getProperty to 
>>>> make sure the debug flag was set and still no helpful debug 
>>>> information. This gets printed out whenever I run sbt, so maybe 
>>>> it's related?
>>>>
>>>> error: error while loading String, class file 
>>>> '/modules/java.base/java/lang/String.class' is broken
>>>> (class java.lang.NullPointerException/null)
>>>>
>>>> On 2/25/19 3:11 PM, Mark Hammons wrote:
>>>>> I will do this when I return home tonight.
>>>>>
>>>>> On 25/02/2019 12:37, Maurizio Cimadamore wrote:
>>>>>>
>>>>>> On 25/02/2019 00:40, Mark Hammons wrote:
>>>>>>> So at least I know the command is failing, but still no output 
>>>>>>> as to why. 
>>>>>>
>>>>>> Error code 4 means jextract failed with some runtime exception - 
>>>>>> but the "jextract.debug" option should print the exception message:
>>>>>>
>>>>>> ```
>>>>>> ctx.err.println(re.getMessage());
>>>>>> if (Main.DEBUG) {
>>>>>>   re.printStackTrace(ctx.err);
>>>>>> }
>>>>>> return RUNTIME_ERROR;
>>>>>> ```
>>>>>>
>>>>>> I'm not sure setting the property the way you do is the right way 
>>>>>> to go. The property is cached in a static field:
>>>>>>
>>>>>> ```
>>>>>> public static final boolean DEBUG = 
>>>>>> Boolean.getBoolean("jextract.debug");
>>>>>> ```
>>>>>>
>>>>>> So you are basically depending on the order in which classes are 
>>>>>> loaded/initialized here. Can you try to pass -Djextract.debug to 
>>>>>> the VM directly instead of doing it from the program? (not 100% 
>>>>>> sure that is why you are getting no output, but let's try to 
>>>>>> remove as many accidental factors as possible).
>>>>>>
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>>
>>>>>>
>>>>>