tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: ELParser fiel of type LookaheadSuccess extends Error
Date Wed, 03 Feb 2016 17:40:34 GMT
Hi Chris,

Am 03.02.2016 um 17:04 schrieb Christopher Schultz:
> -----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.

The stack should be nearly the same except for some <init> on top 
currently and jj_scan_token() when instantiated on demand. Is it 
important? I'd say the frames lower down should help people to find 
where in the app they create an EL which on parsing throws the error.

I'd be interested if there's an expectation whether ELParser object 
creation could happen frequently or should happen rarely (after an app 
has reached steady state).

Regards,

Rainer

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


Mime
View raw message