headers
Jonathan Gibbons | 2 Feb 23:29
Picon
Favicon

Re: jsr instructions in OpenJDK 6 classes

On 02/02/2012 01:29 PM, Kelly O'Hair wrote:
> On Feb 2, 2012, at 8:59 AM, Andrew Haley wrote:
>
>> On 02/02/2012 04:52 PM, Joe Darcy wrote:
>>> stackmaps are used.
>>>
>>> I haven't delved into the OpenJDK 6 build before writing this email, but
>>> I suspect some of the classes in rt.jar are compiled with -target 5, but
>>> javac in OpenJDK 6 defaults to -target 6 so you wouldn't see jsr
>>> instructions from a stock compile.
>> Well, I'm using the same compile command so that doesn't quite explain it,
>> but never mind.
>>
>> Why are some of the classes in rt.jar are compiled with -target 5 ?
>> Would it hurt simply to remove that?
>>
>> Andrew.
>
> Not sure about OpenJDK6.
>
> But I thought ALL the classes in JDK6 were compiled with -target 5.
>
> As I recall the big issue was the StackMapTable attributes in -target 6 classes.
> Many of the classfile reader/writers had issues having to re-create the StackMaptable attribute
> and I vaguely recall some performance issues, and maybe some rt.jar size issues,
> and maybe some pack200 issues, etc. etc.
>
> It was, how do you say it..... a  'can o worms' ???:^(
>
> -kto
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kumar Srinivasan | 3 Feb 00:17
Picon
Favicon

Re: jsr instructions in OpenJDK 6 classes

On 2/2/2012 2:29 PM, Jonathan Gibbons wrote:
> On 02/02/2012 01:29 PM, Kelly O'Hair wrote:
>> On Feb 2, 2012, at 8:59 AM, Andrew Haley wrote:
>>
>>> On 02/02/2012 04:52 PM, Joe Darcy wrote:
>>>> stackmaps are used.
>>>>
>>>> I haven't delved into the OpenJDK 6 build before writing this 
>>>> email, but
>>>> I suspect some of the classes in rt.jar are compiled with -target 
>>>> 5, but
>>>> javac in OpenJDK 6 defaults to -target 6 so you wouldn't see jsr
>>>> instructions from a stock compile.
>>> Well, I'm using the same compile command so that doesn't quite 
>>> explain it,
>>> but never mind.
>>>
>>> Why are some of the classes in rt.jar are compiled with -target 5 ?
>>> Would it hurt simply to remove that?
>>>
>>> Andrew.
>>
>> Not sure about OpenJDK6.
>>
>> But I thought ALL the classes in JDK6 were compiled with -target 5.
>>
>> As I recall the big issue was the StackMapTable attributes in -target 
>> 6 classes.
>> Many of the classfile reader/writers had issues having to re-create 
>> the StackMaptable attribute
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Weimer | 3 Feb 16:15
Picon

Re: Getting langtools into Maven Central

* Jesse Glick:

> On 12/29/2011 12:07 PM, Joe Darcy wrote:
>> javac in OpenJDK 6 has had a proper superset of the fixes in Oracle JDK 6 since OpenJDK 6 includes a large
>> batch of fixes inherited from its JDK 7 lineage.
>
> I stand corrected. Still, it may be missing some fixes made in 7, and
> offers no _advantage_ over OpenJDK 7's javac that I know of, so it
> would be simpler to just publish 7.x artifacts.

Sometimes, it's an advantage if the compiler lacks bug fixes because it
can compile older sources.  Access to a private field of an object of
parametric type (with the proper erasure) is something which I recently
encountered.  It used to compile javac 6 (at least the version in Debian
squeeze), but javac 7 rejects it (rightly).

--

-- 
Florian Weimer                <fweimer@...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
Permalink | Reply | 1 comment |
headers
leszekp | 7 Feb 10:57

javac lexer parser rewrite

Hello

Javac scanner and parser now are handwritten. The code, especially in parser is quite messy and
hard to read and modify.
It is possible to rewrite lexer and parser using some kind of java parser generator.
It would improve readability and allows for easier modifications.

There is a project 'compiler grammar' (which seems dormant). Java lexer and parser were rewritten
using antlr. But antrl generated parsers are very slow.

Many lexer and parser generators exists which are able to process 'classic' regular expressions for lexer or
context free grammars for parser and produce fast code (ie. jflex, beaver, jikes parser generator and more)

What do you think about it? Is there a need for such thing? Is it worth the effort?

Regards
Leszek Piotrowicz
Permalink | Reply | 12 comments |
headers
Maurizio Cimadamore | 7 Feb 11:27
Picon
Favicon

Re: javac lexer parser rewrite

Hi
let me start by saying that I agree with you - the current parser/lexer 
architecture is messy and it represent a barrier for other people to 
chime in and start to contribute. However, when I was working on a 
parser improvement related to lambda expressions (I added lookahead 
support), I was surprised to see how fast javac lexer/parser actually 
are. Here are some 'unofficial' numbers taken on my machine (each run 
correspond to lexing the 'jdk/src' folder of the JDK 8 repo):

Run1: 0m6.501s
Run2: 0m6.205s
Run3: 0m6.936s

AVG: 6.547
TOTAL FILES: 7846
AVG TIME/FILE: 0.83 * 10-6 s

So, is it messy? Sure - is it fast? Yes, like hell. So, to summarise,  I 
think that any effort to try to improve our parser/lexer architecture is 
definitively welcome - however, anyone embarking on such a project 
should keep the above numbers in mind - if you can achieve the same 
speed (well, even marginally slower would be acceptable) than it'd be an 
option well worth considering.

Maurizio

On 07/02/12 09:57, leszekp@... wrote:
> Hello
>
> Javac scanner and parser now are handwritten. The code, especially in parser is quite messy and
(Continue reading)

Permalink | Reply | 1 comment |
headers
leszekp | 7 Feb 12:29

Re: javac lexer parser rewrite

Hello
I would gladly experiment with lexing/parsing to see if machine generated code are of comparable speed
I wonder how you measure pure lexing time. Do you have some 'special' wrapper around javac to do it?

Leszek

-------- Original Message --------
From: Maurizio Cimadamore <maurizio.cimadamore@...>
To: leszekp@...
Cc: compiler-dev@...
Subject: Re: javac lexer parser rewrite
Date: Tue, 07 Feb 2012 10:27:10 +0000

> Hi
> let me start by saying that I agree with you - the current parser/lexer 
> architecture is messy and it represent a barrier for other people to 
> chime in and start to contribute. However, when I was working on a 
> parser improvement related to lambda expressions (I added lookahead 
> support), I was surprised to see how fast javac lexer/parser actually 
> are. Here are some 'unofficial' numbers taken on my machine (each run 
> correspond to lexing the 'jdk/src' folder of the JDK 8 repo):
> 
> Run1: 0m6.501s
> Run2: 0m6.205s
> Run3: 0m6.936s
> 
> AVG: 6.547
> TOTAL FILES: 7846
> AVG TIME/FILE: 0.83 * 10-6 s
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jonathan Gibbons | 7 Feb 16:15
Picon
Favicon

Re: javac lexer parser rewrite

For javac, just write a small program to call the (internal) javac 
classes directly.

-- Jon

On 02/07/2012 03:29 AM, leszekp@... wrote:
> Hello
> I would gladly experiment with lexing/parsing to see if machine generated code are of comparable speed
> I wonder how you measure pure lexing time. Do you have some 'special' wrapper around javac to do it?
>
> Leszek
>
> -------- Original Message --------
> From: Maurizio Cimadamore<maurizio.cimadamore@...>
> To: leszekp@...
> Cc: compiler-dev@...
> Subject: Re: javac lexer parser rewrite
> Date: Tue, 07 Feb 2012 10:27:10 +0000
>
>> Hi
>> let me start by saying that I agree with you - the current parser/lexer
>> architecture is messy and it represent a barrier for other people to
>> chime in and start to contribute. However, when I was working on a
>> parser improvement related to lambda expressions (I added lookahead
>> support), I was surprised to see how fast javac lexer/parser actually
>> are. Here are some 'unofficial' numbers taken on my machine (each run
>> correspond to lexing the 'jdk/src' folder of the JDK 8 repo):
>>
>> Run1: 0m6.501s
>> Run2: 0m6.205s
(Continue reading)

Permalink | Reply | 0 comments |
headers
Per Bothner | 7 Feb 17:35
Picon
Favicon

Re: javac lexer parser rewrite

On 02/07/2012 02:27 AM, Maurizio Cimadamore wrote:
> So, is it messy? Sure - is it fast? Yes, like hell. So, to summarise, I
> think that any effort to try to improve our parser/lexer architecture is
> definitively welcome - however, anyone embarking on such a project
> should keep the above numbers in mind - if you can achieve the same
> speed (well, even marginally slower would be acceptable) than it'd be an
> option well worth considering.

Another advantage of a hard-written parser/lexer, besides speed, is that
it is flexible (if you need to handle special cases).

Furthermore, it is easy to understand what is going on, and easier to debug.
Imagine trying to set breakpoints in a generated parser or otherwise try
to figure out why something is parsed the way it is.  A hard-written
parser/lexer is more verbose and shows all the details - but at least
what you see is plain debuggable Java code, and you don't need a special
tool or understanding.
--

-- 
	--Per Bothner
per.bothner@...  
per@...   http://per.bothner.com/
Permalink | Reply | 0 comments |
headers
Jesse Glick | 8 Feb 03:12
Picon
Favicon
Gravatar

Re: Getting langtools into Maven Central

On 02/03/2012 10:15 AM, Florian Weimer wrote:
>> [OpenJDK 6] may be missing some fixes made in 7, and
>> offers no _advantage_ over OpenJDK 7's javac that I know of, so it
>> would be simpler to just publish 7.x artifacts.
>
> it's an advantage if the compiler lacks bug fixes because it
> can compile older sources.

True, and this is why it would be desirable to build using a versioned compiler artifact - any change in the
compilability of your sources could be traced to 
modifications in versioned source files (*.java or pom.xml), excepting of course the boot classpath
which is another sticky issue JDK 8 should solve.

Still I do not think it is worth the effort of retroactively publishing an OpenJDK 6 artifact now; e.g. the
particular case you mention should probably just be corrected 
in sources.
Permalink | Reply | 0 comments |
headers
leszekp | 8 Feb 16:52

Re: javac lexer parser rewrite

Both hand-coded parser and generated one has some advantages and disadvantages.
Of course it is good to have plain java code and have the possiblitity to debug it.

But as level of complication rises, at some point hand-written parser becomes unamanageable anyway.
In example Pascal language was designed to be LL(1) and hand-written recursive descent
parser for this language is probably quite understandable. But java wasn't designed that way
and its hand-written parser has a lot of quirks which made it complicated to understand.

I am experimenting with jflex generated java lexer. It is very fast - comparable
to original javac Scanner, it is promising.

regards
Leszek

-------- Original Message --------
From: Per Bothner <per.bothner@...>
To: Maurizio Cimadamore <maurizio.cimadamore@...>
Cc: leszekp@..., compiler-dev@...
Subject: Re: javac lexer parser rewrite
Date: Tue, 07 Feb 2012 08:35:51 -0800

> On 02/07/2012 02:27 AM, Maurizio Cimadamore wrote:
> > So, is it messy? Sure - is it fast? Yes, like hell. So, to summarise, I
> > think that any effort to try to improve our parser/lexer architecture is
> > definitively welcome - however, anyone embarking on such a project
> > should keep the above numbers in mind - if you can achieve the same
> > speed (well, even marginally slower would be acceptable) than it'd be an
> > option well worth considering.
> 
> Another advantage of a hard-written parser/lexer, besides speed, is that
(Continue reading)

Permalink | Reply | 2 comments |

Gmane