[OpenJDK 2D-Dev] Question regarding the integration of harfbuzz (JEP 258)

[Steven R. Loomis]

Volker,
 0. I’d like to see what the crashing stack frame is when NOT on harfbuzz, because there should be no change.

 1. Phil addressed this one

 2. I will take a look on AIX. I’ll see if I can build Harfbuzz itself on AIX at first.

 3. Yes, I’ll work on putting some docs together for that test.  Actually, other tests such as the Font2DTest  would be a good test. Or, any text in a complex script such as Hindi.

 4. I’m not sure. A threaded stress test would be good.  Perhaps Harfbuzz-in-JDK could leverage the hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp you mentioned. 
 
 Behdad - file is here http://hg.openjdk.java.net/jdk9/client/hotspot/file/c8e212fb27d0/src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp  - any comments on this or other items? 

-s

> 
> -------- Original Message --------
> Subject:	Re: [OpenJDK 2D-Dev] Question regarding the integration of harfbuzz (JEP 258)
> Date:	Wed, 09 Dec 2015 09:02:33 -0800
> From:	Philip Race <philip.race at oracle.com> <mailto:philip.race at oracle.com>
> Organization:	Oracle Corporation
> To:	2d-dev at openjdk.java.net <mailto:2d-dev at openjdk.java.net>
> 
> Hi Volker,
> 
> Running with ICU should stop harfbuzz use completely so if
> you are still seeing a crash, perhaps it is due to something else entirely.
> Especially since a "simple AWT program" should not load layout anyway.
> There was a fair amount of new and changed code pushed recently ...
> 
> Yes, we need to run harfbuzz in multiple concurrent threads in the JDK.
> A single threaded lock on harfbuzz would throttle text operations.
> I suppose it is possible that we do not strictly need it as we currently 
> create a
> new harfbuzz "instance" each time we go to invoke layout but that
> is something that at least theoretically could change.
> 
> The approach to synchronization is all from up-stream harfbuzz.
> The harfbuzz mailing list might be the place to discuss that.
> I'd expect it does work on AIX as a principal driver here is that
> the IBM sponsored ICU project has deprecated its layout engine
> and IBM/ICU are moving to harfbuzz so I'd be somewhat astonished
> if they haven't yet tried it on AIX. Did you try just getting a copy
> of the full hotspot library and running its configure on AIX to see if
> harfbuzz can work out which options it wants there ? Obviously
> I did not try that since I don't have AIX. Steven Loomis of IBM
> who submitted the JEP should be able to help with a lot of this.
> 
> -phil.
> 
> On 12/8/15, 10:50 AM, Volker Simonis wrote:
> > Hi,
> >
> > the integration of harfbuzz broke our AIX build because there's no
> > implementation available for the hb_atomic macros in
> > hb-atomic-private.hh. I've fixed that locally but still get a crash
> > when running a simple AWT program (even with
> > -Dsun.font.layoutengine=icu).
> >
> > I'm curretnly debugging the problem, but I have some general questions:
> >
> > 1. Do we really need the multi-threaded features of harfbuzz in OpenJDK?
> >
> > 2. Why does hurbuzz require these synchronization macros? From a first
> > glance it doesn't seem to use multiple threads by itself. Does it have
> > some global data structures which it needs to protect if harfbuzz is
> > called from various threads?
> >
> > 3. Is there a way to test the hurfbuzz engine on a new platform? I saw
> > the new test TestLayoutVsICU.java but it is marked as "manual" and it
> > seems to require external fonts (at least some of which seem to be
> > freely available). Could you please provide at least a minimal
> > description on how this test can be run?
> >
> > 4. Is there a way to test that the implementation of the hb_atomic
> > macros in hb-atomic-private.hh is correct (i.e. a way to stress
> > harfbuzz from multiple threads)? I think this is important as I
> > couldn't find a good description of the requirements for the atomic
> > macros and on weak memory model architectures we should really get
> > this right. For example there's no description of which fences are
> > required around the various atomic operations. Getting this right
> > across all platforms in the HotSpot (see
> > hotspot/src/os_cpu/../vm/atomic_os_cp.inline.hpp) is already hard
> > enough so I'm a little concerned that we are now introducing similar
> > primitives in the class library.
> >
> > Thank you and best regards,
> > Volker

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151209/53706429/attachment.html>