Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java at Alibaba [pdf]

jcp.org

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Java at Alibaba [pdf]

#21

Post by srean »

_old_dude_ wrote: post #15

There was a presentation with more info at last JVM Language Summit https://www.youtube.com/watch?v=X4tmr3nhZRg The scary things is that they have implemented coroutine (generalized async/await) by copying the stack back and forth instead of putting the stack in the heap like in stackless python or in scheme.

Could you please explain which stack you are talking about here. If I am not wrong, Java language semantics does not have stack allocated variables, hence my confusion. I sampled the video at random offsets but could not find the location where coroutine implementation was discussed.

Re: Java at Alibaba [pdf]

#22

Post by noelwelsh »

srean wrote: post #21
_old_dude_ wrote: post #15

There was a presentation with more info at last JVM Language Summit https://www.youtube.com/watch?v=X4tmr3nhZRg The scary things is that they have implemented coroutine (generalized async/await) by copying the stack back and forth instead of putting the stack in the heap like in stackless python or in scheme.

Could you please explain which stack you are talking about here. If I am not wrong, Java language semantics does not have stack allocated variables, hence my confusion. I sampled the video at random offsets but could not find the location where coroutine implementation was discussed.

It is the call stack that is being copied. It doesn't have to do so much with stack allocated variables (which may be created in Java according to the whim of the compiler) but with capturing the current state of a computation in a relatively light weight manner, so that light weight threads / coroutines can be saved and restored without the context switch and memory overhead of a full thread. This is basically the old "green threads" implementation used in the early JVMs.

The big idea behind this is the concept of a continuation, and a conversion between programs in "direct style" (the way you normally write them) and "continuation passing style" which makes control flow explicit. You could start reading here if interested: http://matt.might.net/articles/by-example-continuation-passi... Or read about how Scheme compilers work to support first class continuations, and the tricks you can play with them.

Re: Java at Alibaba [pdf]

#23

Post by aardvark179 »

srean wrote: post #21
_old_dude_ wrote: post #15

There was a presentation with more info at last JVM Language Summit https://www.youtube.com/watch?v=X4tmr3nhZRg The scary things is that they have implemented coroutine (generalized async/await) by copying the stack back and forth instead of putting the stack in the heap like in stackless python or in scheme.

Could you please explain which stack you are talking about here. If I am not wrong, Java language semantics does not have stack allocated variables, hence my confusion. I sampled the video at random offsets but could not find the location where coroutine implementation was discussed.

Java has a stack (it uses a stack based bytecode after all) which is used to hold arguments and so forth, and it has local variables whose values live on the stack. What it doesn't have is object allocation on the stack - so if a local variable is a reference type then the object it refers to will be created on the heap.

Note the above only refers to the logical view of the language. A VM and JIT will have an ABI for method calls which may use registers to pass arguments (it may have several for interpreted and JITed code), and it can allocate objects purely on the stack if it can do good enough escape analysis.

Re: Java at Alibaba [pdf]

#24

Post by disposable_123 »

baybal2 wrote: post #7
Cyph0n wrote: post #4

Impressive stuff. They have basically forked their entire backend stack, starting from the OS and moving upwards. I am particularly interested in how much AliOS deviates from mainline Linux.

>Alibaba Runs Millions of Custom JVMs >They have basically forked their entire backend stack, starting from the OS and moving upwards. I doubt this being a cool thing. Sure, they are the second biggest IT employer in the country, and have excess resources for everything, but... A thing about big dotcoms - architects there try to use off-the-shelf software for everything, even if the software is clearly unsuited for t…

Can you add a link to the article (Alibaba/mysql/etc ?!)

Re: Java at Alibaba [pdf]

#25

Post by srean »

noelwelsh wrote: post #22
srean wrote: post #21

Earlier quoted context omitted.

Could you please explain which stack you are talking about here. If I am not wrong, Java language semantics does not have stack allocated variables, hence my confusion. I sampled the video at random offsets but could not find the location where coroutine implementation was discussed.

It is the call stack that is being copied. It doesn't have to do so much with stack allocated variables (which may be created in Java according to the whim of the compiler) but with capturing the current state of a computation in a relatively light weight manner, so that light weight threads / coroutines can be saved and restored without the context switch and memory overhead of a full thread. This is basically the o…

That makes sense. I wasn't sure which stack parent was referring to, stack of java activation records, the underlying C call stack of a JVM implemented in C.

Re: Java at Alibaba [pdf]

#26

Post by vincnetas »

baybal2 wrote: post #7
Cyph0n wrote: post #4

Impressive stuff. They have basically forked their entire backend stack, starting from the OS and moving upwards. I am particularly interested in how much AliOS deviates from mainline Linux.

>Alibaba Runs Millions of Custom JVMs >They have basically forked their entire backend stack, starting from the OS and moving upwards. I doubt this being a cool thing. Sure, they are the second biggest IT employer in the country, and have excess resources for everything, but... A thing about big dotcoms - architects there try to use off-the-shelf software for everything, even if the software is clearly unsuited for t…

> "Read the article from a month ago how Alibaba got stuck with using MySQL for mission critical tasks, and how much efforts they put to "unhack" it"

Do you have a link for that?

Re: Java at Alibaba [pdf]

#27

Post by baybal2 »

disposable_123 wrote: post #24
baybal2 wrote: post #7

Earlier quoted context omitted.

>Alibaba Runs Millions of Custom JVMs >They have basically forked their entire backend stack, starting from the OS and moving upwards. I doubt this being a cool thing. Sure, they are the second biggest IT employer in the country, and have excess resources for everything, but... A thing about big dotcoms - architects there try to use off-the-shelf software for everything, even if the software is clearly unsuited for t…

Can you add a link to the article (Alibaba/mysql/etc ?!)

A video from Alibaba's mysql specialist, http://www.highload.ru/2015/abstracts/1915.html

Re: Java at Alibaba [pdf]

#28

Post by ninjakeyboard »

Java is well suited to very large projects only because developers are "commodity." With the modern language updates, the core java collections library is really broken for modern multi-paradigm programming. There are no true immutable collections in the core lib which makes Java really show its age with the newer language features compared to other more modern languages such as scala. Functions are bolted on as "Single Abstract Method" classes, which make functions essentially syntactic sugar instead of a first class language feature. Java9 makes some improvements but I wouldn't consider using Java for any new projects unless I was at a big enterprise that can only hire really cheap developer and needs to hire a whole lot of em really fast.

Re: Java at Alibaba [pdf]

#29

Post by knightofmars »

ninjakeyboard wrote: post #28

Java is well suited to very large projects only because developers are "commodity." With the modern language updates, the core java collections library is really broken for modern multi-paradigm programming. There are no true immutable collections in the core lib which makes Java really show its age with the newer language features compared to other more modern languages such as scala. Functions are bolted on as "Sin…

In a "not big enterprise" environment, what would you choose instead?

Re: Java at Alibaba [pdf]

#30

Post by koevet »

ninjakeyboard wrote: post #28

Java is well suited to very large projects only because developers are "commodity." With the modern language updates, the core java collections library is really broken for modern multi-paradigm programming. There are no true immutable collections in the core lib which makes Java really show its age with the newer language features compared to other more modern languages such as scala. Functions are bolted on as "Sin…

I fail to see the connection between cheap developers and Java not being a truly functional language (which it never claimed or tried to be).
Post reply on HN