Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: ELParser fiel of type LookaheadSuccess extends Error
To: Tomcat Developers List <dev@tomcat.apache.org>
References: <56B22160.8090703@kippdata.de>
From: Christopher Schultz <chris@christopherschultz.net>
Message-id: <56B22517.2030502@christopherschultz.net>
Date: Wed, 03 Feb 2016 11:04:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
MIME-version: 1.0
In-reply-to: <56B22160.8090703@kippdata.de>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rainer,

On 2/3/16 10:48 AM, Rainer Jung wrote:
> Hi there,
> 
> ELParser has a field named jj_ls of type LookaheadSuccess which
> extends Error. It is created during each instantiation of an
> ELParser object. Creating an Error is quite slow, because e.g. it
> calls java.lang.Throwable.fillInStack() during init.
> 
> This jj_ls is only used once in jj_scan_token() where it is thrown
> in case of certain condition, see line 2985:
> 
> 2968 private boolean jj_scan_token(int kind) { 2969 if (jj_scanpos
> == jj_lastpos) { 2970 jj_la--; 2971 if (jj_scanpos.next == null) { 
> 2972 jj_lastpos = jj_scanpos = jj_scanpos.next = 
> token_source.getNextToken(); 2973 } else { 2974 jj_lastpos =
> jj_scanpos = jj_scanpos.next; 2975 } 2976 } else { 2977 jj_scanpos
> = jj_scanpos.next; 2978 } 2979 if (jj_rescan) { 2980 int i = 0;
> Token tok = token; 2981 while (tok != null && tok != jj_scanpos) {
> i++; tok = tok.next; } 2982 if (tok != null)
> jj_add_error_token(kind, i); 2983 } 2984 if (jj_scanpos.kind !=
> kind) return true; 2985 if (jj_la == 0 && jj_scanpos == jj_lastpos)
> throw jj_ls; 2986 return false; 2987 }
> 
> This is generated code and it is the only place were jj_ls is being
> used.
> 
> I noticed this situation because I'm doing a performance analysis
> of an application. I wonder whether creating this jj_ls for each
> new ELParser instance in advance is the right thing to do. One
> could also put the burden on the usage side, e.g. generating it
> when it is needed to be thrown. Unfortunately I don't know enough
> about the typical runtime details of ELParser. E.g. it might be
> that typically only few instances of it are created because they
> get reused (which doesn't seem to be the case, we only create and
> use it method local in createNodeInternal.createNodeInternal()) or
> their results get cached (which seems to be the case).
> 
> I'll have a look at how effective the caching is for the
> application in question, but I'd be interested if there is an
> opinion whether the pattern to create the Error object eagerly when
> creating the ELParser object seems appropriate. No idea currently,
> how one would change it

Is the stack trace of the current implementation important when that
Error (subclass) is thrown? If the stack trace is important to be
filled-in at that earlier time, then this is a complex issue. If
nobody cares what the stack trace says, I'm +1 for only instantiating
the Error when it needs to be thrown.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlayJRcACgkQ9CaO5/Lv0PDawQCfbvmI12paCRrzqh4sArOg+ImQ
MHIAoIMAiGTtFXzL/GEYhHLbLvVF1uVY
=tfnY
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org