important discovery about a probable refactoring in jvm or OS

Martijn Verburg martijnverburg at gmail.com
Sun Dec 24 21:02:37 UTC 2017


Hi Cristian,

See
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004390.html
which discusses Project Loom.  Project Loom is where you'll
want to be discussing this type of feature in OpenJDK.

Cheers,
Martijn

On 24 December 2017 at 17:13, Cristian Lorenzetto <
cristian.lorenzetto at gmail.com> wrote:

> - while fibres are an important feature I have never found a use for them
> in my space due to them being too expensive. I assume there are some very
> good use cases for them but the growing number of cpus in a server might
> make this less important.
> this is completely false , it is the opposite , fibers solve a actual
> problems . Big data acceletated to introduce it. About expensive... it is
> opposite . I think you have a bit to go deeply in this context.
> XML as exchange protocol is terrible  and now is completely replaced by
> more performant and binary solution . To have a complete list about data
> type it is important. Java is not inly used for making simple software but
> also in engineering and high performance systems.
> Interfaces are not multiherarchy, Interfaces are black boxes. Anyway there
> are also problem with performance (to explain require time).
> inline method are just when jvm decide it at runtime, but there are
> contexts in which the developers and the software have to be
> deterministic.In addition the inline process applied is very very trial.
> Who study lambdas know that is a mathematical theory. When there is
>  mathematical formula is possible to replace it with inline code. Java
> lambdas are just a different rappresentation of objects usage. But the tens
> of years are not spent for create a theory for rename the same things.
>
>
>
> ---------- Forwarded message ----------
> From: Peter Lawrey <peter.lawrey at gmail.com>
> Date: 2017-12-24 17:38 GMT+01:00
> Subject: Re: important discovery about a probable refactoring in jvm or OS
> To: Cristian Lorenzetto <cristian.lorenzetto at gmail.com>
> Cc: discuss <discuss at openjdk.java.net>
>
>
> Hello Christian,
>    Some quick thoughts.
> - while fibres are an important feature I have never found a use for them
> in my space due to them being too expensive. I assume there are some very
> good use cases for them but the growing number of cpus in a server might
> make this less important.
> - i agree on unsigned esp 128 bit. Unsigned char is not enough and why byte
> is unsigned i van only assume is historical. Unsigned operations are
> supported using the wrapper classes.
> Personally, i feel BigDecimal should have language support ala C#.
> - i think java will evolve to allowing multiple inheritance of classes but
> its not needed most of the time. Esp with enhancements to interfaces.
> - the JVM already inlines methods and there is an @ForceInline however it's
> not for public use afaik.
> - the byte code at compile time isn't as important as the code it compiles
> to at runtime. Lambdas do take a hit before they warm up and making
> capturing lambdas not create garbage is a pain.
>
> I would point out that of the top languages, Java is one of the newest.
> What it really needs is features older languages take for granted and are
> widely used and understood eg structs.
>
> https://www.tiobe.com/tiobe-index/
>
> Regards Peter.
>
>
> On 24 Dec. 2017 2:41 pm, "Cristian Lorenzetto" <
> cristian.lorenzetto at gmail.com> wrote:
>
> As i descrived in this place https://github.com/boostorg/fiber/issues/161
>
> It is impossible to use JNI interface when c++ code is executing  native
> fibers/courotines (calling a java callback). Pratically in future all new
> software will use fibers instead threads so java will get a prison.
> It is necessary to re design JVM with many changes
>
> c++ native fibers might be the java threads so JNI continue to works
>
> In addition i suggest
> - to add new data type for unsigned number
> - multyhierarchy (
> parent classes can't have a common ancestor(except trially Object class).
> This permits to evoid data inconsistency as explained also in Kotlin) This
> is the just limitation for evoiding inconsitency.
> - inline functions
> - redesign lambdas compiler engine to trasforming lambda classes in inline
> code (see stackoverflow ho many developers proved the bad bytecode
> generated by actual javac)
>
> Pay attention ! Java could die if it doesnt follow the modern software
> needs! you can see already now many jdk new languages trying to skip the
> java language , but if you talk with the languages teams you can see all
> tells JDK doesnt permits do do many things others VM permits(in primis
> class multi hierarchy). Java must change before developers change language!
>


More information about the discuss mailing list