Home » Modeling » OCL » Checking OCL
| Checking OCL [message #71523] |
Thu, 02 July 2009 09:27  |
Eclipse User |
|
|
|
Hi,
In my plugin, I use the following code to check ocl on a package:
-------------------------------------------------------
OCL myOcl = OCL.newInstance();
myOcl.setEvaluationTracingEnabled(false);
myOcl.setParseTracingEnabled(false);
Helper oclHelper = myOcl.createOCLHelper();
oclHelper.setInstanceContext(element);
OCLExpression oclInv=null;
try {
oclInv = (OCLExpression) oclHelper.createQuery(oclExpr);
} catch (Exception e) {
System.out.println("Invalid OCL!\n");
e.printStackTrace();
}
valid = myOcl.check(element, oclInv);
------------------------------------------------------
This code works fine, except that after repeatedly checking constraints I
get consequently an out of memory error.
What am I doing wrong here?
Samuel
|
|
| | | |
| Re: Checking OCL [message #71603 is a reply to message #71583] |
Tue, 07 July 2009 07:37  |
| Eclipse User |
|
|
|
--=-u5DQzusVHI/1a+7cyU4V
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Samuel, Alex,
One noteworthy point about working with UML is that the UML
implementation's CacheAdapter is a famous source of memory leaks in
applications that don't account for it.
The OCL parser for UML makes use of the CacheAdapter for inverse
navigation of references, so you will find that this adapter becomes
attached not only to the elements of your model but also to the parsed
syntax trees of your OCL constraints and expressions. An OCL facade (as
created by OCL::newInstance()) keeps track of all of the constraints
that it has parsed, and must be dispose()d when no longer needed. This
ensures that all of the OCL expression objects are removed from the
CacheAdapter's knowledge and can be reclaimed.
If you can, it is highly recommended to parse any constraint only once
and to re-use a single OCL instance in as wide a context as possible.
This should help to cut down on memory usage and on time spent in
parsing. Otherwise, do be sure to dispose OCLs when they are obsolete.
HTH,
Christian
On Tue, 2009-07-07 at 09:45 +0200, user@domain.invalid wrote:
> Hi Alex,
>
> Enclosed you find the code of my plugin and a project with UML models
> and profiles. I launch an Eclipse application with my plugin in it, open
> the file 'CallBackSeq.uml', select the package in it and run the
> 'Validate' action of my plugin through the 'ArchiMate' menu. The OCL
> constraints are in the UML profile named 'CallbackSeqProfile.uml'. After
> successfully checking a few constraints, I get an 'out of memory' error.
> If I check fewer constraints, I don't get it, but if I then repeat the
> check, I do get it.
>
> I really hope you can find the problem.
>
> Cheers,
>
> Samuel
--=-u5DQzusVHI/1a+7cyU4V
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Samuel, Alex,<BR>
<BR>
One noteworthy point about working with UML is that the UML implementation's CacheAdapter is a famous source of memory leaks in applications that don't account for it.<BR>
<BR>
The OCL parser for UML makes use of the CacheAdapter for inverse navigation of references, so you will find that this adapter becomes attached not only to the elements of your model but also to the parsed syntax trees of your OCL constraints and expressions. An OCL facade (as created by OCL::newInstance()) keeps track of all of the constraints that it has parsed, and must be dispose()d when no longer needed. This ensures that all of the OCL expression objects are removed from the CacheAdapter's knowledge and can be reclaimed.<BR>
<BR>
If you can, it is highly recommended to parse any constraint only once and to re-use a single OCL instance in as wide a context as possible. This should help to cut down on memory usage and on time spent in parsing. Otherwise, do be sure to dispose OCLs when they are obsolete.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Tue, 2009-07-07 at 09:45 +0200, user@domain.invalid wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Alex,
Enclosed you find the code of my plugin and a project with UML models
and profiles. I launch an Eclipse application with my plugin in it, open
the file 'CallBackSeq.uml', select the package in it and run the
'Validate' action of my plugin through the 'ArchiMate' menu. The OCL
constraints are in the UML profile named 'CallbackSeqProfile.uml'. After
successfully checking a few constraints, I get an 'out of memory' error.
If I check fewer constraints, I don't get it, but if I then repeat the
check, I do get it.
I really hope you can find the problem.
Cheers,
Samuel
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-u5DQzusVHI/1a+7cyU4V--
|
|
| | |
| Re: Checking OCL [message #71657 is a reply to message #71639] |
Wed, 08 July 2009 07:33 |
| Eclipse User |
|
|
|
--=-7dfmbcRYz0jGhBT4kUV0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Samuel,
I would expect that this isn't a design to which you should have to
resort. Disposing an OCL really is intended to clean up any potential
leaks, so if that's not working, then probably there's a bug. A good
profiler will tell you exactly what's going on.
The only comment that I have on your code snippet (from a memory
perspective) is that the oclInv.destroy() call should be redundant, as
the myOcl.dispose() will effect the same result (and more).
Cheers,
Christian
On Wed, 2009-07-08 at 07:22 +0000, Samuel wrote:
> Hey Christian,
>
> I made my OCL and Helper object a static element to my plugins activator,
> and now it works!
>
> Thanks so much :)
>
> Samuel
>
--=-7dfmbcRYz0jGhBT4kUV0
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Samuel,<BR>
<BR>
I would expect that this isn't a design to which you should have to resort. Disposing an OCL really is intended to clean up any potential leaks, so if that's not working, then probably there's a bug. A good profiler will tell you exactly what's going on.<BR>
<BR>
The only comment that I have on your code snippet (from a memory perspective) is that the oclInv.destroy() call should be redundant, as the myOcl.dispose() will effect the same result (and more).<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Wed, 2009-07-08 at 07:22 +0000, Samuel wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hey Christian,
I made my OCL and Helper object a static element to my plugins activator,
and now it works!
Thanks so much :)
Samuel
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-7dfmbcRYz0jGhBT4kUV0--
|
|
|
Goto Forum:
Current Time: Wed Jul 23 17:31:46 EDT 2025
Powered by FUDForum. Page generated in 0.67388 seconds |
Home