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

Mysterious Android codebase commit

android.googlesource.com

Post reply on HN
Print view View original

31–40 of 170 posts

Re: Mysterious Android codebase commit

#31

Post by overgard »

grizzles wrote: post #26
ndesaulniers wrote: post #18

Earlier quoted context omitted.

And throw out the hard work __ALL__ browser vendors are doing TOGETHER on WebAssembly? In favor of a VM that clearly has restrictions and is owned by a litigious organization? Bloating browsers by adding another VM, which will hurt throughput by having multiple GC's to synchronize? The JVM ecosystem and Hotspot are certainly modern marvels, but there's hurdles greater than the potential benefit.

The JVM is already open source. If this matter has indeed been settled, then the litigious organization issue might have been too. WebAssembly doesn't have a GC, and probably won't for some time. It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does. Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the brows…

> WebAssembly doesn't have a GC, and probably won't for some time.

Yeah... because it's assembly. That's the whole point. You don't WANT a GC. It would be the wrong layer to place a GC in. Ask most professional game developers if they would consider using a platform with a GC. They won't, because you can't build a realtime system without stuttering if you're dealing with a GC.

Re: Mysterious Android codebase commit

#32

Post by exabrial »

ndesaulniers wrote: post #29
grizzles wrote: post #26

Earlier quoted context omitted.

The JVM is already open source. If this matter has indeed been settled, then the litigious organization issue might have been too. WebAssembly doesn't have a GC, and probably won't for some time. It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does. Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the brows…

> The JVM is already open source. I can picture Google's lawyers using that in court against Oracle. > then the litigious organization issue might have been too That might is a big MIGHT, the same kind that keeps browser vendors from shipping various media codecs and news companies from using various media streaming protocols. > WebAssembly doesn't have a GC The GC all browsers currently have and will not get rid of…

The startup performance of HotSpot is largely related to the SDK and class library. Remove it and you have a very expedient startup.

Re: Mysterious Android codebase commit

#33

Post by greggman »

overgard wrote: post #31
grizzles wrote: post #26

Earlier quoted context omitted.

The JVM is already open source. If this matter has indeed been settled, then the litigious organization issue might have been too. WebAssembly doesn't have a GC, and probably won't for some time. It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does. Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the brows…

> WebAssembly doesn't have a GC, and probably won't for some time. Yeah... because it's assembly. That's the whole point. You don't WANT a GC. It would be the wrong layer to place a GC in. Ask most professional game developers if they would consider using a platform with a GC. They won't, because you can't build a realtime system without stuttering if you're dealing with a GC.

1000s of games have shipped with gc. Every Unreal and Unity game uses gc. Every XNA game used gc. Many of the largest most popular AAA games use gc. So yes we can ask professional game devs if they want a gc. Most will say "yes". Like any tool you know when to use them and when not to

Re: Mysterious Android codebase commit

#34

Post by incepted »

grizzles wrote: post #9
grizzles wrote: post #6

To explain if you are just joining in: This pretty much means Oracle v Google, a case with major ramifications for the industry has been settled out of court. I don't see how this can be interpreted any other way.

If this inference is right, I hope this means that Google will enable the web community to use the JVM with or as an alternative to WebAssembly. Hotspot is absolutely incredible technology, and it's competitors are still many years away from coming close to matching it's capabilities.

This is a commit to the Android code base, what does this have to do with HotSpot, WebAssembly or even the JVM?

Re: Mysterious Android codebase commit

#35

Post by geofft »

devsquid wrote: post #11
grizzles wrote: post #9

Earlier quoted context omitted.

If this inference is right, I hope this means that Google will enable the web community to use the JVM with or as an alternative to WebAssembly. Hotspot is absolutely incredible technology, and it's competitors are still many years away from coming close to matching it's capabilities.

I'm all for the JVM but it's too powerful to run arbitrary code man. No JVM in my browser please.

The Java plugin's mistake was to embed a rich sandboxing mechanism right in the middle of the language layer. The Java runtime, in the middle of parsing bytecode and registering class hierarchies, is supposed to enforce who can access what things, not simply as an advisory mechanism or safety check (as public/private is just about everywhere else), but as a security mechanism under active assault, with only this single line of defense between untrusted code and full local privileges just like native code. And, like anything with a complicated security policy and a wide attack surface, it had no chance.

Stick a regular, unprivileged JVM, with no secure classloader magic, inside a straightforward non-Java low-level sandbox like NaCl or even just PPAPI + Chrome's renderer sandboxing (like Pepper Flash or PDFium) and it'll probably hold up just fine.

And honestly that's what Android does. Java isn't a security boundary on Android, and the NDK makes this explicit. Each app runs as its own UID, and the kernel is taught to isolate users a bit more than usual for UNIX, and that holds up pretty well -- not perfect, but far better than the Java plugin does.

(To be clear, I'm not advocating the JVM as a platform for web content. Just that, if somehow it turns out that the JVM is in fact the right platform, the sandboxing problem not a blocker.)

Re: Mysterious Android codebase commit

#36

Post by ndesaulniers »

exabrial wrote: post #32
ndesaulniers wrote: post #29

Earlier quoted context omitted.

> The JVM is already open source. I can picture Google's lawyers using that in court against Oracle. > then the litigious organization issue might have been too That might is a big MIGHT, the same kind that keeps browser vendors from shipping various media codecs and news companies from using various media streaming protocols. > WebAssembly doesn't have a GC The GC all browsers currently have and will not get rid of…

The startup performance of HotSpot is largely related to the SDK and class library. Remove it and you have a very expedient startup.

Pull an engine out of a car and it gets lighter, too.

Re: Mysterious Android codebase commit

#37

Post by gruez »

greggman wrote: post #33
overgard wrote: post #31

Earlier quoted context omitted.

> WebAssembly doesn't have a GC, and probably won't for some time. Yeah... because it's assembly. That's the whole point. You don't WANT a GC. It would be the wrong layer to place a GC in. Ask most professional game developers if they would consider using a platform with a GC. They won't, because you can't build a realtime system without stuttering if you're dealing with a GC.

1000s of games have shipped with gc. Every Unreal and Unity game uses gc. Every XNA game used gc. Many of the largest most popular AAA games use gc. So yes we can ask professional game devs if they want a gc. Most will say "yes". Like any tool you know when to use them and when not to

>Many of the largest most popular AAA games use gc

Like, actual GC and not smart pointers? I would like a list.

Re: Mysterious Android codebase commit

#38

Post by ndesaulniers »

greggman wrote: post #33
overgard wrote: post #31

Earlier quoted context omitted.

> WebAssembly doesn't have a GC, and probably won't for some time. Yeah... because it's assembly. That's the whole point. You don't WANT a GC. It would be the wrong layer to place a GC in. Ask most professional game developers if they would consider using a platform with a GC. They won't, because you can't build a realtime system without stuttering if you're dealing with a GC.

1000s of games have shipped with gc. Every Unreal and Unity game uses gc. Every XNA game used gc. Many of the largest most popular AAA games use gc. So yes we can ask professional game devs if they want a gc. Most will say "yes". Like any tool you know when to use them and when not to

Further, a lot of shared data structures in super high perf C++ end up with "Free Lists" to allow multiple threads to perform atomic delete operations on the data structure. Point being that memory is no longer freed deterministically.

"If there's other threads working here, atomic compare and swap this pointer to the free list, otherwise last one out clean up."

Take a look at some of the code from Chapter 7 from Anthony Williams "C++ Concurrency in Action" [0].

[0] https://manning-content.s3.amazonaws.com/download/0/78f6c43-...

Re: Mysterious Android codebase commit

#39

Post by pcwalton »

grizzles wrote: post #26
ndesaulniers wrote: post #18

Earlier quoted context omitted.

And throw out the hard work __ALL__ browser vendors are doing TOGETHER on WebAssembly? In favor of a VM that clearly has restrictions and is owned by a litigious organization? Bloating browsers by adding another VM, which will hurt throughput by having multiple GC's to synchronize? The JVM ecosystem and Hotspot are certainly modern marvels, but there's hurdles greater than the potential benefit.

The JVM is already open source. If this matter has indeed been settled, then the litigious organization issue might have been too. WebAssembly doesn't have a GC, and probably won't for some time. It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does. Benefits include getting scala, clojure, jython, jruby, and about 30 other languages working client side in the brows…

> WebAssembly probably won't [have a GC] for some time

Citation needed :)

> It also doesn't have ~20 years of performance tuning on different microarchitectures the way the JVM does.

JS engines have been tuned very well over the years. Remember that Web Assembly is designed to run in a JS engine.

Re: Mysterious Android codebase commit

#40

Post by grizzles »

ndesaulniers wrote: post #36
exabrial wrote: post #32

Earlier quoted context omitted.

The startup performance of HotSpot is largely related to the SDK and class library. Remove it and you have a very expedient startup.

Pull an engine out of a car and it gets lighter, too.

I don't think this is a significant issue because it's a one time cost. It could be done at browser startup. Even for a cold start, Hotspot and V8 are comparable.

$ time java com.Hello real 0m0.096s user 0m0.103s sys 0m0.013s

$ time node /tmp/hello.js real 0m0.073s user 0m0.067s sys 0m0.007s

Post reply on HN