llvm dev - Dec 2013 - [LLVMdev] Making LLVM safer in out-of-memory situations

Hello,

Philipp Becker and me, Vaidas Gasiunas, are developers at SAP and part of a team
developing a C-like domain-specific language for the SAP HANA in-memory
database. We use LLVM as a backend to translate our language to native code,
primarily on x86-64 platforms. Our programs are created dynamically, compiled
and optimized in a running database. As a result of that we have special
requirements with respect to response time and safety. In particular, we have to
avoid long compile times and must deal with error situations like out-of-memory
without crashing or producing memory leaks in the compiler. The compiler
performance is especially important since that we must compile generated
functions which tend to be rather long - in the range of thousands of LOC per
function.

To address these requirements we have developed a set of patches improving
performance and malfunction safety of certain compiler passes and would be
interested in contributing them at some point. Before proposing concrete
changes, we would like to know what the general interest is with respect to
making LLVM safer in out-of-memory situations.

Best Regards,
Vaidas Gasiunas

On Dec 12, 2013, at 04:25 , Gasiunas, Vaidas <vaidas.gasiunas at sap.com>
wrote:
> To address these requirements we have developed a set of patches improving
performance and malfunction safety of certain compiler passes and would be
interested in contributing them at some point. Before proposing concrete
changes, we would like to know what the general interest is with respect to
making LLVM safer in out-of-memory situations.
I'm in favor! I can't imagine we shouldn't be able to craft fixes
that don't otherwise adversely affect LLVM.

-- 
Rick



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131212/d4a591f2/attachment.sig>

On Dec 12, 2013, at 4:25 AM, Gasiunas, Vaidas <vaidas.gasiunas at sap.com>
wrote:
> Hello,
> 
> Philipp Becker and me, Vaidas Gasiunas, are developers at SAP and part of a
team developing a C-like domain-specific language for the SAP HANA in-memory
database. We use LLVM as a backend to translate our language to native code,
primarily on x86-64 platforms. Our programs are created dynamically, compiled
and optimized in a running database. As a result of that we have special
requirements with respect to response time and safety. In particular, we have to
avoid long compile times and must deal with error situations like out-of-memory
without crashing or producing memory leaks in the compiler. The compiler
performance is especially important since that we must compile generated
functions which tend to be rather long - in the range of thousands of LOC per
function.
> 
> To address these requirements we have developed a set of patches improving
performance and malfunction safety of certain compiler passes and would be
interested in contributing them at some point. Before proposing concrete
changes, we would like to know what the general interest is with respect to
making LLVM safer in out-of-memory situations.
This sounds pretty awesome to me!

I'm looking forward to seeing what y'all came up with.

-Filip
> 
> Best Regards,
> Vaidas Gasiunas
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131212/c7174ae2/attachment.html>

----- Original Message -----
> From: "Rick Mann" <rmann at latencyzero.com>
> To: "Vaidas Gasiunas" <vaidas.gasiunas at sap.com>
> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, December 12, 2013 1:24:40 PM
> Subject: Re: [LLVMdev] Making LLVM safer in out-of-memory situations
> 
> 
> On Dec 12, 2013, at 04:25 , Gasiunas, Vaidas
> <vaidas.gasiunas at sap.com> wrote:
> 
> > To address these requirements we have developed a set of patches
> > improving performance and malfunction safety of certain compiler
> > passes and would be interested in contributing them at some point.
> > Before proposing concrete changes, we would like to know what the
> > general interest is with respect to making LLVM safer in
> > out-of-memory situations.
> 
> I'm in favor! I can't imagine we shouldn't be able to craft
fixes
> that don't otherwise adversely affect LLVM.
I also agree, handling low memory situations gracefully is important in a number
of different environments.

 -Hal
> 
> --
> Rick
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On 12/12/13 4:25 AM, Gasiunas, Vaidas wrote:
> Hello,
>
> Philipp Becker and me, Vaidas Gasiunas, are developers at SAP and part of a
team developing a C-like domain-specific language for the SAP HANA in-memory
database. We use LLVM as a backend to translate our language to native code,
primarily on x86-64 platforms. Our programs are created dynamically, compiled
and optimized in a running database. As a result of that we have special
requirements with respect to response time and safety. In particular, we have to
avoid long compile times and must deal with error situations like out-of-memory
without crashing or producing memory leaks in the compiler. The compiler
performance is especially important since that we must compile generated
functions which tend to be rather long - in the range of thousands of LOC per
function.
>
> To address these requirements we have developed a set of patches improving
performance and malfunction safety of certain compiler passes and would be
interested in contributing them at some point. Before proposing concrete
changes, we would like to know what the general interest is with respect to
making LLVM safer in out-of-memory situations.
I'm hugely in favor of the general direction.  Happy to help by 
reviewing changes and the like.

This type of work was on my long term todo list; I'm thrilled to see 
someone else doing it now.  :)

One question: How are you handling EOM?  Error return?  Custom region 
allocator?

Philip

Hi Philip,

Thanks for the positive response from all of you!
 
> One question: How are you handling EOM?  Error return?  Custom region
allocator?
When running into an Out-of-memory situation we're currently only doing an
error return, i.e. the compilation fails, but does so without crashing the
process in which the compilation/jitting occurs. It is ok for us if llvm returns
with a catchable exception and unwinds all allocated memory correctly.

To increase stability for us we have already moved the main part of the
compilation to a separate process that may crash in case of an error without
doing much harm, i.e. does not crash the database. Therefore, we've
currently concentrating on specific components that still remain in the database
process, such as CodeLoader and VMCore, which is used for emitting IR code.
Although, of course, we're also interested in increasing the general
stability of the whole llvm w.r.t. error situations.

Best regards,
Philipp

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Philip Reames
Sent: Freitag, 13. Dezember 2013 02:04
To: Gasiunas, Vaidas; LLVM Dev
Subject: Re: [LLVMdev] Making LLVM safer in out-of-memory situations

On 12/12/13 4:25 AM, Gasiunas, Vaidas wrote:
> Hello,
>
> Philipp Becker and me, Vaidas Gasiunas, are developers at SAP and part of a
team developing a C-like domain-specific language for the SAP HANA in-memory
database. We use LLVM as a backend to translate our language to native code,
primarily on x86-64 platforms. Our programs are created dynamically, compiled
and optimized in a running database. As a result of that we have special
requirements with respect to response time and safety. In particular, we have to
avoid long compile times and must deal with error situations like out-of-memory
without crashing or producing memory leaks in the compiler. The compiler
performance is especially important since that we must compile generated
functions which tend to be rather long - in the range of thousands of LOC per
function.
>
> To address these requirements we have developed a set of patches improving
performance and malfunction safety of certain compiler passes and would be
interested in contributing them at some point. Before proposing concrete
changes, we would like to know what the general interest is with respect to
making LLVM safer in out-of-memory situations.
I'm hugely in favor of the general direction.  Happy to help by 
reviewing changes and the like.

This type of work was on my long term todo list; I'm thrilled to see 
someone else doing it now.  :)

One question: How are you handling EOM?  Error return?  Custom region 
allocator?

Philip
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 12 December 2013 12:25, Gasiunas, Vaidas <vaidas.gasiunas at sap.com>
wrote:
> Hello,
>
> Philipp Becker and me, Vaidas Gasiunas, are developers at SAP and part of a
team developing a C-like domain-specific language for the SAP HANA in-memory
database. We use LLVM as a backend to translate our language to native code,
primarily on x86-64 platforms. Our programs are created dynamically, compiled
and optimized in a running database. As a result of that we have special
requirements with respect to response time and safety. In particular, we have to
avoid long compile times and must deal with error situations like out-of-memory
without crashing or producing memory leaks in the compiler. The compiler
performance is especially important since that we must compile generated
functions which tend to be rather long - in the range of thousands of LOC per
function.
>
> To address these requirements we have developed a set of patches improving
performance and malfunction safety of certain compiler passes and would be
interested in contributing them at some point. Before proposing concrete
changes, we would like to know what the general interest is with respect to
making LLVM safer in out-of-memory situations.
>
Did you look into another way of looking at this.
E.g.  I have source code X. I have 1 Gig of RAM and no SWAP file. Will
LLVM compile it or run out of memory in the process?

Running LLVM and being able to retrieve stats like "Max RAM used
during compile" might be a workable solution to mitigate the
likelihood of OOM.

The reason I am interested in this is that cloud computing sometimes
gives you cheap Virtual Machines with quite low limits for resources
like RAM.
It would be nice to know before trying to compile some source code,
that it will not fail due to OOM before you start.

Kind Regards

James

Hi James,

I don't think that would be a suitable approach for us. First, it requires a
reliable way to estimate the memory to be consumed by a particular program. Our
experience is that compiler behavior depends not only on the size of the
program, but also on its structure. So I don't think there is also a simple
relationship between the size of the program and the memory consumed. Second, we
have multiple threads running in parallel, also multiple parallel compilations.
Thus even if we check the memory before compilation, the situation can change
later during compilation process. It is also not possible to reserve memory for
a particular LLVM compilation, because in most of places it uses the global
allocator.

Regards,
Vaidas

-----Original Message-----
From: James Courtier-Dutton [mailto:james.dutton at gmail.com] 
Sent: Donnerstag, 9. Januar 2014 16:50
To: Gasiunas, Vaidas
Cc: LLVM Dev
Subject: Re: [LLVMdev] Making LLVM safer in out-of-memory situations

On 12 December 2013 12:25, Gasiunas, Vaidas <vaidas.gasiunas at sap.com>
wrote:
> Hello,
>
> Philipp Becker and me, Vaidas Gasiunas, are developers at SAP and part of a
team developing a C-like domain-specific language for the SAP HANA in-memory
database. We use LLVM as a backend to translate our language to native code,
primarily on x86-64 platforms. Our programs are created dynamically, compiled
and optimized in a running database. As a result of that we have special
requirements with respect to response time and safety. In particular, we have to
avoid long compile times and must deal with error situations like out-of-memory
without crashing or producing memory leaks in the compiler. The compiler
performance is especially important since that we must compile generated
functions which tend to be rather long - in the range of thousands of LOC per
function.
>
> To address these requirements we have developed a set of patches improving
performance and malfunction safety of certain compiler passes and would be
interested in contributing them at some point. Before proposing concrete
changes, we would like to know what the general interest is with respect to
making LLVM safer in out-of-memory situations.
>
Did you look into another way of looking at this.
E.g.  I have source code X. I have 1 Gig of RAM and no SWAP file. Will
LLVM compile it or run out of memory in the process?

Running LLVM and being able to retrieve stats like "Max RAM used
during compile" might be a workable solution to mitigate the
likelihood of OOM.

The reason I am interested in this is that cloud computing sometimes
gives you cheap Virtual Machines with quite low limits for resources
like RAM.
It would be nice to know before trying to compile some source code,
that it will not fail due to OOM before you start.

Kind Regards

James