[erlang-bugs] hipe_mfait_lock

[Mikael Pettersson]

Louis-Philippe Gauthier writes:
 > Hi Sverker,
 > That's not a bad idea, I'll try that approach!
 > 
 > Thanks,
 > LP
 > 
 > On Thu, Jan 15, 2015 at 12:27 AM, Sverker Eriksson <
 > sverker.eriksson@REDACTED> wrote:
 > 
 > >  One quite simple improvement is to change the hipe_mfait_lock to be a
 > > read-write mutex (erts_smp_rwmtx_t).
 > > And then do read-lock at lookup and exclusive write-lock only when
 > > inserting a new entry in the table.
 > >
 > > I don't think that requires much knowledge about the VM to pull off ;-) .
 > >
 > > /Sverker, Erlang/OTP
 > >
 > >
 > >
 > >
 > > On 01/14/2015 12:34 AM, Louis-Philippe Gauthier wrote:
 > >
 > > Hi erlang-bugs,
 > > I couple of months ago I tried running our full application using HiPE. I
 > > ran into several issues, some manageable, some not... The most problematic
 > > issue was due to locking, specifically, the hipe_mfait_lock (you can see
 > > the lock counter output in the gist bellow).
 > > https://gist.github.com/lpgauth/2b3220f4bceeed6f62d0
 > >
 > > Looking at the code it's obvious that this is a known problem... the
 > > following comment was added when the lock was added in 2010.
 > >
 > > "XXX: Redesign apply et al to avoid those updates."https://github.com/erlang/otp/blob/maint/erts/emulator/hipe/hipe_bif0.c#L1218
 > >
 > > Unfortunately, I'm don't know the runtime enough to start patching it... so
 > > instead I'm reporting it.

Please try the attached patch (against 17.4, should apply to older
versions too by I haven't checked), and let me know if it makes a
noticeable improvement to your use case.

Run-time apply:s now do their lookups using a shared read-lock, and
only if their lookups fail do they re-lock with an exclusive write-lock
in order to insert new data.  Module loading functions always take
exclusive locks, which matches the current behaviour.

/Mikael

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: otp17-hipe-mfait-rwlock.patch
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20150223/2ffbca3a/attachment.ksh>