Fwd: New features for java language and jdk compiler

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: New features for java language and jdk compiler

Cristian Lorenzetto


I write you for suggesting new features and improvements in new java version language and compiler after i worked for long time in projects where performance is important or in complex projects where modularity is very important.
In the language
1) introduce unsigned integer types in java language. The binary integration in the last years with gprc and other tecnologies based on binary interoperability requires to complete this missing part. Also language as c# and golang have unsigned integer types in the language.In addition there is also a reason with performance: actually for passing to signed to unsigned integer you have to douple the size of memory space (for as example a unsigned integer must be a long and a unsigned long must be a slow big integer).
2) introduce the multiple hierarchicy in classes. The use of interface (also with last addition with default keyword in interface) can not compesate for hierarchy classes. Also modern language as Golang use it. The missing feature has also effect in the performance because requires a massive use of classloder and gc (delegates are see in indipendent way and not like a single body probably)in a software because you have to instance all the parents classes (like delegates ) instead to instance a unique class(lesser memory usage). Also architectual design is better using hierarchy classes. Interfaces is usefull when you want espose a specific class schema to external ("out of box"exposition) but not when you want espose code "in of box"(in this case you need to use also static methods , protected methods and variables).The performance worse also for a lesser use of static methods because interface can t espose static methods. If you use many super parents you can reuse better also static methods. For evoiding conflict in parents classes there is a simple solution that has also a deep sense. You can't have two parent classes having a common parent class: the composition of logic is necessary when you have 2 indipendent abstractions. A abstraction is trially monolitic so it is obvious you can't affect a abstraction with another abstraction. If you do it you are creating a logic contraction because if a abstraction need to change the internal status of another abstraction , these abstractions are not abstractions and you have to reformulate your model.

3) final class. The final class surely was invented for prohibit to change internal status of native objects. The is a thin difference in the fact to prohibit to change status of parent class and to prohibit hierarchy. This is the cause of a problem for memory usage and allocation. If you change lightly the meaning of a final class in : the child class can not change protected variables and can not call protected functions you prohibit to change internal status but you permit to create a child class. The old projects continue to work as before but you have a advantage for the future projects. What is the advantage?.You remove a ton of not necessary dependencies in classes reducing memory used (a dependency required a additional addresss nested in the container class) and decrement the memory allocation ( for every dependency you need to call dynamic memory allocator one more time). It seams a light difference but if you see the result in a big java project using tons of basic variables ... you see a significant difference in memory and performance(above all in contect where you see milliseconds).
4) distinction from runtime class and code class. There are 2 way to see a class:at runtime and in the compiler ... many times you need to organize code in many classes for better modularity but in the RAM at runtime they can collapsed in few classes. This observation can create a lot of other optimizations reducing a lot the memory used , gc and dynamic allocations.
not always a class organized in the code it is corrisponding to a real need to see a class at runtime. This is particular true in the hierarchy  of classes.This could be defined by developer.

in the compilator:
1) the jit compilation might be improved a lot above all for lambda management . Lambda calculus is a mathematic theory : it means you can foresee in advance the structure of the class. Lambda functions might be replaced in the jit with inline functions based on parent clousure context. In the most of case you use just functional methods with no root lambda clousure context so it is equivalent to a inline replacement in the global context (like C inline methods). Benchmark instead tells lambda functions are slower anonimous classes... this is a grave conceptual error. Lambda calculus for compiler might be just smart inline replacment of predefined block codes placed in the parent clousure context. In addition there are other improvements based on a thin difference the class definition for loader and jit is not equivalent to the class memory definition: in other words there are a lot of infos might be precomputed at bytecode generation because immutable and permitting to improve the performance of jit generation time .This observations could improve the benchmarks in not trascurable way.




_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: New features for java language and jdk compiler

Daniel Megert
Hi Christian

Eclipse implements the Java language specs  it does not change the specs in any way. You will have to raise your suggestions at http://openjdk.java.net/.

Dani



From:        Cristian Lorenzetto <[hidden email]>
To:        [hidden email]
Date:        12.11.2017 15:42
Subject:        [jdt-core-dev] Fwd: New features for java language and jdk compiler
Sent by:        [hidden email]






I write you for suggesting new features and improvements in new java version language and compiler after i worked for long time in projects where performance is important or in complex projects where modularity is very important.
In the language

1) introduce unsigned integer types in java language. The binary integration in the last years with gprc and other tecnologies based on binary interoperability requires to complete this missing part. Also language as c# and golang have unsigned integer types in the language.In addition there is also a reason with performance: actually for passing to signed to unsigned integer you have to douple the size of memory space (for as example a unsigned integer must be a long and a unsigned long must be a slow big integer).
2) introduce the multiple hierarchicy in classes. The use of interface (also with last addition with default keyword in interface) can not compesate for hierarchy classes. Also modern language as Golang use it. The missing feature has also effect in the performance because requires a massive use of classloder and gc (delegates are see in indipendent way and not like a single body probably)in a software because you have to instance all the parents classes (like delegates ) instead to instance a unique class(lesser memory usage). Also architectual design is better using hierarchy classes. Interfaces is usefull when you want espose a specific class schema to external ("out of box"exposition) but not when you want espose code "in of box"(in this case you need to use also static methods , protected methods and variables).The performance worse also for a lesser use of static methods because interface can t espose static methods. If you use many super parents you can reuse better also static methods. For evoiding conflict in parents classes there is a simple solution that has also a deep sense. You can't have two parent classes having a common parent class: the composition of logic is necessary when you have 2 indipendent abstractions. A abstraction is trially monolitic so it is obvious you can't affect a abstraction with another abstraction. If you do it you are creating a logic contraction because if a abstraction need to change the internal status of another abstraction , these abstractions are not abstractions and you have to reformulate your model.

3) final class. The final class surely was invented for prohibit to change internal status of native objects. The is a thin difference in the fact to prohibit to change status of parent class and to prohibit hierarchy. This is the cause of a problem for memory usage and allocation. If you change lightly the meaning of a final class in : the child class can not change protected variables and can not call protected functions you prohibit to change internal status but you permit to create a child class. The old projects continue to work as before but you have a advantage for the future projects. What is the advantage?.You remove a ton of not necessary dependencies in classes reducing memory used (a dependency required a additional addresss nested in the container class) and decrement the memory allocation ( for every dependency you need to call dynamic memory allocator one more time). It seams a light difference but if you see the result in a big java project using tons of basic variables ... you see a significant difference in memory and performance(above all in contect where you see milliseconds).
4) distinction from runtime class and code class. There are 2 way to see a class:at runtime and in the compiler ... many times you need to organize code in many classes for better modularity but in the RAM at runtime they can collapsed in few classes. This observation can create a lot of other optimizations reducing a lot the memory used , gc and dynamic allocations.
not always a class organized in the code it is corrisponding to a real need to see a class at runtime. This is particular true in the hierarchy  of classes.This could be defined by developer.

in the compilator:
1) the jit compilation might be improved a lot above all for lambda management . Lambda calculus is a mathematic theory : it means you can foresee in advance the structure of the class. Lambda functions might be replaced in the jit with inline functions based on parent clousure context. In the most of case you use just functional methods with no root lambda clousure context so it is equivalent to a inline replacement in the global context (like C inline methods). Benchmark instead tells lambda functions are slower anonimous classes... this is a grave conceptual error. Lambda calculus for compiler might be just smart inline replacment of predefined block codes placed in the parent clousure context. In addition there are other improvements based on a thin difference the class definition for loader and jit is not equivalent to the class memory definition: in other words there are a lot of infos might be precomputed at bytecode generation because immutable and permitting to improve the performance of jit generation time .This observations could improve the benchmarks in not trascurable way.



_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jdt-2Dcore-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=AiO031XTXJyqwFhW9zR5QJruAhYmSEq3kq7KJJ-ePL8&s=1r_Y6xZOTq7Cz8d4nMdql6CHoIBfrypXouIkkZMQoI0&e=



_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: New features for java language and jdk compiler

Andrew Haley
In reply to this post by Cristian Lorenzetto
On 12/11/17 14:42, Cristian Lorenzetto wrote:

> 1) the jit compilation might be improved a lot above all for lambda
> management . Lambda calculus is a mathematic theory : it means you
> can foresee in advance the structure of the class. Lambda functions
> might be replaced in the jit with inline functions based on parent
> clousure context.  In the most of case you use just functional
> methods with no root lambda clousure context so it is equivalent to
> a inline replacement in the global context (like C inline
> methods). Benchmark instead tells lambda functions are slower
> anonimous classes... this is a grave conceptual error.

Generally speaking, lambdas are inlined and their superstructure is
optimized away where that is possible.  It takes some care to write
code which takes advantage of this: if your lambda captures variables
then almost inevitably it'll be necessary tp create an object to hold
the values of those variables.  If you're seeing a marked slowdown in
a simple example of a lambda there's probably a reason for for it.
Show your benchmark.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: New features for java language and jdk compiler

Jayaprakash Arthanareeswaran
In reply to this post by Cristian Lorenzetto
Hi Cristian,
 
I guess you meant to send this to [hidden email]  ?
This list is for JDT developers and JDT is only Eclipse's implementation of Java compiler
and we are not the authors of the Java language specification.
 
Regards,
Jay
 
----- Original message -----
From: Cristian Lorenzetto <[hidden email]>
Sent by: [hidden email]
To: [hidden email]
Cc:
Subject: [jdt-core-dev] Fwd: New features for java language and jdk compiler
Date: Sun, Nov 12, 2017 8:12 PM
 
 
I write you for suggesting new features and improvements in new java version language and compiler after i worked for long time in projects where performance is important or in complex projects where modularity is very important.
In the language
1) introduce unsigned integer types in java language. The binary integration in the last years with gprc and other tecnologies based on binary interoperability requires to complete this missing part. Also language as c# and golang have unsigned integer types in the language.In addition there is also a reason with performance: actually for passing to signed to unsigned integer you have to douple the size of memory space (for as example a unsigned integer must be a long and a unsigned long must be a slow big integer).
2) introduce the multiple hierarchicy in classes. The use of interface (also with last addition with default keyword in interface) can not compesate for hierarchy classes. Also modern language as Golang use it. The missing feature has also effect in the performance because requires a massive use of classloder and gc (delegates are see in indipendent way and not like a single body probably)in a software because you have to instance all the parents classes (like delegates ) instead to instance a unique class(lesser memory usage). Also architectual design is better using hierarchy classes. Interfaces is usefull when you want espose a specific class schema to external ("out of box"exposition) but not when you want espose code "in of box"(in this case you need to use also static methods , protected methods and variables).The performance worse also for a lesser use of static methods because interface can t espose static methods. If you use many super parents you can reuse better also static methods. For evoiding conflict in parents classes there is a simple solution that has also a deep sense. You can't have two parent classes having a common parent class: the composition of logic is necessary when you have 2 indipendent abstractions. A abstraction is trially monolitic so it is obvious you can't affect a abstraction with another abstraction. If you do it you are creating a logic contraction because if a abstraction need to change the internal status of another abstraction , these abstractions are not abstractions and you have to reformulate your model.
 
3) final class. The final class surely was invented for prohibit to change internal status of native objects. The is a thin difference in the fact to prohibit to change status of parent class and to prohibit hierarchy. This is the cause of a problem for memory usage and allocation. If you change lightly the meaning of a final class in : the child class can not change protected variables and can not call protected functions you prohibit to change internal status but you permit to create a child class. The old projects continue to work as before but you have a advantage for the future projects. What is the advantage?.You remove a ton of not necessary dependencies in classes reducing memory used (a dependency required a additional addresss nested in the container class) and decrement the memory allocation ( for every dependency you need to call dynamic memory allocator one more time). It seams a light difference but if you see the result in a big java project using tons of basic variables ... you see a significant difference in memory and performance(above all in contect where you see milliseconds).
4) distinction from runtime class and code class. There are 2 way to see a class:at runtime and in the compiler ... many times you need to organize code in many classes for better modularity but in the RAM at runtime they can collapsed in few classes. This observation can create a lot of other optimizations reducing a lot the memory used , gc and dynamic allocations.
not always a class organized in the code it is corrisponding to a real need to see a class at runtime. This is particular true in the hierarchy  of classes.This could be defined by developer.
in the compilator:
1) the jit compilation might be improved a lot above all for lambda management . Lambda calculus is a mathematic theory : it means you can foresee in advance the structure of the class. Lambda functions might be replaced in the jit with inline functions based on parent clousure context. In the most of case you use just functional methods with no root lambda clousure context so it is equivalent to a inline replacement in the global context (like C inline methods). Benchmark instead tells lambda functions are slower anonimous classes... this is a grave conceptual error. Lambda calculus for compiler might be just smart inline replacment of predefined block codes placed in the parent clousure context. In addition there are other improvements based on a thin difference the class definition for loader and jit is not equivalent to the class memory definition: in other words there are a lot of infos might be precomputed at bytecode generation because immutable and permitting to improve the performance of jit generation time .This observations could improve the benchmarks in not trascurable way.
 
 
 


_______________________________________________
jdt-core-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev